I disagree with Julien on two items in this thread. At 5:31 PM -0700 10/20/08, Julien R Pierre - Sun Microsystems wrote: >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. The revocation therefore always has to come from a higher level >than the root cert iteslf.
This is not true at all. Only someone who knows the private key can sign the suicide note. Obviously, it is not in an attacker's best interest to sign it. There is no "higher level" than a trust anchor. If you are using a trust anchor manager, they can pull a trust anchor out of your trust anchor pile, but that is quite different than revoking it. At 5:34 PM -0700 10/20/08, Julien R Pierre - Sun Microsystems wrote: >Roots cannot be revoked by OCSP/CRL channels. You only need to read PKIX >standards (RFC3280 for one) to figure that out. Trust anchors are outside the >scope of these revocation protocols. Correct. >You should take that up with the IETF if you want the CRL and OCSP protocols >changed to allow root revocation. Good lord, no. If you follow the IETF's PKIX WG, you will see that they take forever to finish something and it often comes out much worse than when it went in. Well, that was true in the past; now, most people are just burnt out and not saying anything. If you want to to be able to "revoke" roots, please consider instead getting active in the current work on TAMP (trust anchor management protocol) being discussed in the PKIX WG. It's a large protocol, but that's because the initial work was done before coming to the IETF. The authors are genuinely interested in getting feedback on the proposal, and they are getting too little in the WG. The main different between TAMP and revoking trust anchors is that TAMP is run by a trusted party who might or might not listen to a trust anchor owner who says "please revoke me". The advantage of TAMP is that trusted party might revoke *before* the trust anchor owner wants people to in an iffy situation. I can certainly see Mozilla running TAMP instead of relying on the update process to add and remove trust anchors. Pulling in another thread from this list, TAMP allows the trusted party to put limitations on a trust anchor, such as "only good for signing keys with names in *.com" and so on; that information doesn't need to reside in the trust anchor itself. My two cents.... --Paul Hoffman _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
