Paul,
Paul Hoffman wrote:
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.
If the root CA private key has been compromised, potentially anybody
could sign "suicide notes", provided an actual format existed for them.
That's the definition of a private key compromise - the private key fell
into the wrong hands. For example, the private key might have been
extracted, or cracked and posted on a public website, in an extreme case.
If you use a format such as a CRL for the "suicide note", then you have
to potentially deal with other problems such as "resurrection notes".
This is a fairly theoritical discussion anyway since suicide notes don't
exist in PKIX.
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.
Myself included, I haven't been on the IETF list for a while. However,
this is really the process that we are stuck with. There is little point
in trying to come up with some generic root revocation scheme if you are
going to be the only one using it in the end. I don't really see how
that's better than a proprietary mechanism like the mozilla update process.
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.
Thanks for the pointer. I will take a look.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
