You, as an employee of ExampleCorp, code sign v1 of ExampleApp with your code signing intermediate certificate authority that's in turn ultimately signed by a standard Apple-trusted root. You release ExampleApp into the wild.
Later, security experts show that ExampleApp v1 has a security flaw.
You fix the flaw in ExampleApp v1.0.1, code sign it, and release it into the wild.
Now, unless you have a fancy software update mechanism associated with ExampleApp and the fancy software update mechanism has not been turned off by the consumers of ExampleApp, or all of your consumers read their security bulletins from you quickly, [the consumers of your app, who may then take issue with] you have a problem. They may still be running v1 and thus be vulnerable.
You _could_ revoke the certificate associated with v1, so that unless the users also frustrated CRL/OSCP operation, Mac OS X would not trust the code signing certificate.
Is this a _good_ thing to do?
Is there an alternate mechanism related to code-signing that would be more appropriate? I can imagine that unless the user noticed that the certificate was specifically revoked (vs. untrusted because it or a cert on the chain expired, or untrusted because the root of the chain isn't in the anchors), they might blithely go on with their life and unwittingly "OK" the app, and remain vulnerable.
I could also imagine a case where ExampleApp v1 has a flaw that is published publicly before you have a (sufficient) chance to make the fix. In this event, you would love to make it obvious that there's a flaw so that, by default, people wouldn't run the app, and that only after acknowledgement that they're vulnerable to such-n-such an issue they can continue. Or, in the case of a site-wide installation, the site administrator can make that decision for the site (e.g., they know that they don't have the problem because of other security systems on their network).
Will code signing (or the related attributes & processes) be used to handle these cases across the OS? E.g., an extension to OCSP that, while the certificate still looks "good", the associated code has vulnerabilities. (This is to distinguish someone who hacked ExampleApp v1 vs. that the true ExampleApp v1 has a problem.)
-nh
--
Nathan Herring
com.microsoft.devdiv.clr.os/development
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Apple-cdsa mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/apple-cdsa/email@hidden
This email sent to email@hidden
