Julien R Pierre - Sun Microsystems:
Eddy,
Eddy Nigg wrote:
That's entirely and implementation issue and design approach.
No. It is also an issue of PKIX standards as well. CAs should not
implement revocation mechanisms that are not standard, and expect them
to be supported by general-purpose software like NSS/Mozilla.
Yes correct! Perhaps I should have suggested, that it would be
interesting to have such an approach working in some form because the CA
could react the fastest for all applications which would implement that
approach. It could be a different key under the CA control or something
else as a first defense (but not on the application level like NSS).
My concern is, that reaching all applications, libraries and users which
don't upgrade/update regularly (if at all and very late) is very
difficult to accomplish. Instead, a revocation mechanism under the CAs
control (and perhaps out of reach, with special controls in place) would
be more efficient.
> If the root could "revoke itself", in the case of root cert key
> compromise, ie. the root cert's private key becoming public, anybody
> could then sign revocation information for that root CA - whether to
> mark it revoked or unrevoked.
Correct, however the CRLDP is included in the original certificate which
is embedded into the software. This information isn't going to change.
It would require at least a DNS compromise on the subject BEFORE the
root would be marked revoked. I guess there could be different
approaches for the application in having the root revoked at the first
possible opportunity.
In any case, the suggested best practice is to refrain from issuing
directly from the CA root and issue from intermediate CA certificates
instead. Everything remains under the CA control, including revocation.
Damage would be limited and controllable in such a case and that's
another reason why issuing directly from CA roots is under the
problematic practice charter:
https://wiki.mozilla.org/CA:Problematic_Practices#Issuing_end_entity_certificates_directly_from_roots
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: [EMAIL PROTECTED]
Blog: https://blog.startcom.org
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
