On 7/17/08 3:14 PM, "Damien Sorresso" <email@hidden> wrote:
> On Jul 17, 2008, at 1:41 PM, Nathan Herring wrote:
>> 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.
>
> This is not the problem code signing is meant to solve. Code signing
> will only answer the question "Have these bits been modified since
> being signed?" Or more conceptually, code signing assigns a
> verifiable, provable identity to a piece of code. That's it.
I concur. I had hoped that the underscores around "could" would have
indicated that I did not especially like that idea.
> Users should *never* correlate trust of a signature with known
> security vulnerabilities. And you, as a developer, should not
> encourage such an expectation, since it raises a bunch of problems
> (which you enumerate in your e-mail), has nothing to do with the
> identity of the code and imbues a false sense of security.
>
> You should not revoke a certificate for reasons unrelated to the
> security of the certificate itself or the identity of your
> organization. If the certificate has not been compromised or you're
> not changing CAs or something along those lines, there's no reason to
> revoke the certificate.
Fair enough, but you did not respond to the idea of using OCSP extensions to
report good certs with extra extension data that happens to contain
vulnerability-related information.
> Your issue is best addressed by a software update mechanism like
> Sparkle or a custom-rolled one (it's not that hard to do).
I disagree. Most applications don't force the user to run the software
update mechanism and report whether the update patches security flaws in the
currently running application, and really, by then it may be too late. If
you've had your machine off for six months, and ExampleApp runs as a startup
item, you can be p4ned before you even have a chance to update. If the
system were to validate your code signature and by-the-by gathered
information about your vulnerabilities, it could prohibit or ask the user to
opt-in or even ignore the vulnerability report by OS policy.
--
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
