Kyle Hamilton wrote: > 2008/10/22 Ian G <[EMAIL PROTECTED]>: >>>> Quite right. The flip side of this is that if *anyone* other than the >>>> person who generated the key pair has they public key, they *should* >>>> sign the suicide note and distribute it because if they have it, a bad >>>> actor could have it as well. >> >> I think we all understand that the basic concept of a root-signed >> self-revocation is workable, in principle, at the information level. >> >> There may be substantial implementation questions... > > There are those who don't think so,
At the level of information and in principle, and leaving standards aside, I do not see any difficulties. Then, drifting back from information principles to implementation and standards issues, there will be substantial implementation questions, such as the ones raised. However, it is important to recognise that the difficulties are found inside PKIX and x.509, not in the capabilities of computer science, crypto or networks. > since the operations defined at > the Root level include "revoking certificates" as well as "derevoking > certificates", via CRL. So, a need to add a new operation, being "revoke self" for example. > There is no such thing as a "suicide note" in X.509 or PKIX. Adding one would be non-standard, yes. > (I was actually just thinking of this when I was trying to get a root > -- not in my control -- to mark a couple of certificates as revoked > due to key compromise. If there were such a thing as a "suicide > note", I could mark my own certificate as revoked and then submit it > to the CA for additional processing [such as adding it to CRLs and > OCSP responses].) Indeed. But, that might be left for a later sanity check. >>> Yes, they should ... But the big question is how do they actually do >>> that and get software to take notice of that suicide note ? >> >> Is there any reason why the message cannot be delivered by the >> current channels? CRL, OCSP? Leaving aside the standards question, >> that is... > > CRLs are signed by the root itself. The CRL can be reissued by anyone > who has the key. The part means that the new CRL could de-include the root, thus un-revoking it. So we would need: * a root revocation is to be cached and not replaced. Also, as CRLs should only be acquired from stated places that are listed in the certificate, there shouldn't be a danger for existing certs. > OCSP is usually handled by a delegated responder with its own identity > binding (and its own key). OCSP should be able to handle the case of > "the root is compromised" by responding to all certificates with > serial numbers in that root's space as being "invalid, key > compromise". However, this relies on the ability of the OCSP > responder to operate with a known-revoked certificate. OK. It would seem to require two things: * an extra flag that says "compromised because root compromised" (I don't know whether OCSP has flags or not...) * a semantic leap of "all certs except my own compromised" (to join the other semantic leaps inherent in the root) These three things don't sound so much, but I'd like to hear what the coders say as to how worthwhile this is. It could just be more trouble than it is worth? >> Is a self-reference in a CRL or OCSP: >> >> defined? Banned? Undefined? Going to cause chaos? > > Self-reference in CRL isn't a singular thing. Anyone with the root > key can reissue a CRL. GoodGuy issues one with the self-reference > saying "revoked, key compromised". BadGuy issues one with the > self-reference missing, since BadGuy wants people to still trust the > root. Thus, it's chaotic. I don't quite see that. CRLs and OCSP checks are acquired from places listed inside the certs. So the bad guy would have to compromise the delivery of certs as well as the root itself. (If that happens, it might be fairer to say that the business is taken over rather than the root compromised :) Now, one can imagine weird cyclical loops, so it would make sense of engineering to add "stickiness" to the CRL as suicide note. This would probably indicate a special CRL that included only one identified cert, the root, and became "sticky". > OCSP I've mentioned above. > >> (Where, Chaos is defined as making matters worse for the software >> that otherwise has to deal with a rogue root out in the wild serving >> up the devil's contract every 3rd packet to grandma...) >> >> It would seem that, if the root list is delivered by party A, and >> the software is written by party A, and the revocation is >> distributed to software of party A, then it should all tie together. >> >> (Yes there will be some issues with party B. Refer to definition of >> chaos.) > > I'd like to see Mozilla run its own CA and cross-certify its root > list. That way, Mozilla would be the "higher authority" and could > issue non-chaotic root revocations... by revoking the > cross-certifications. A possibility. Some thoughts: How do we revoke Mozilla's root? How does the CRL / OCSP get delivered / run? Are we now asking each certificate check to also chain up and check two or more OCSPs? Can we eliminate the whole CA notion by just using a single sig over the list from a "root" ... and just deliver signed updates? I suppose another thing that could be done is: Each CA can run its own cross-CA. That is, each CA runs two roots. It then treats both root as independent business units, to the extent that it desires. Each may revoke the other. Each CA can then submit the two roots, to Mozo's root list, and the software sorts out how the cross linking goes. Downside of this is complexity, and costs for the smaller players (certain large players finding it trivial). Also are we back to chaining the OCSP checking up another layer? It's good to have this debate and thrash out some ideas. I would like to conclude it one way or another; it would be nice to see just how far and how reliable revocation is. There is another niggling contradiction with revocation: The less reliable it is, the less useful is reliance. If reliance isn't useful, then the cert isn't valuable. So, for example, if we can make CRLs/OCSP optional, that also means we can lower the cost of practically everything. OTOH, if we want to make it more reliable, such that it is plausible to rely on it, then it needs to be online and real time. Hence let's make OCSP obligatory. But if that is the case, then you don't need the cert, just the key, because you can get all the content info in the online revocation checkup. So, if we implement OCSP fully, we are now ready to re-engineer the system (because once all the clients are engineered to deal with those flows, changing the messages is a snap). So right now, it is Mozo's wish that certificates be reliable and that revocation be strong and OCSP be online and solid.... However there are limits to that, it may be that the last thing we want is to make all the processes super-strong; and include things like root revocation. iang PS: This is mirrored at the business level, but another day...
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
