On 15/10/2009 15:21, Gervase Markham wrote:
On 13/10/09 16:18, Anders Rundgren wrote:
IMO putting OCSP or CRLs in public SSL certificates was never a
particularly good idea because the only likely case for a revocation
is when a CA fails to validate a customer. That has happened
but not often enough to motivate the building of new infrastructure.
That's just not true. Debian weak keys and the recent \0 certs are both
cases where customer validation was done to the appropriate level but
the certs still had to be revoked.
Note the careful insertion of the word "likely". I think what Anders is
saying is that revocation is purposed to a failure in validation. That
is, in security modelling, revocation is the mitigation technique that
is put in place for that threat.
Revocation is not thought of as being purposed to mitigate software
bugs. That's probably because a software bug is too hard to predict,
and the real fix there is to fix the darn software.
However, I'm not comfortable with Ander's complete claim. I would think
that stolen keys is a good case where revocation is a mitigating
technique. (But maybe he will point out that this hasn't happened much
either, and doesn't justify the building of the new infra.)
In the absence of any particular losses, it is certainly complicated to
predict what is the threat we are best putting our resources against.
And in another related thread, have a look at this:
http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html
What this says to me (and I really haven't researched it ...) is that
Verisign / DNSSEC / etc have dumped the concept of revocation
altogether, and are instead relying on fast key switching.
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
