On Saturday 21 May 2005 00:41, Julien Pierre wrote: > Ian, > > Ian G wrote: > >>But OCSP/CRL can not help in case of *root* cert compromission. > >>There's nothing above it to sign the validity information. > > > > Can't it revoke itself? > > This is priceless and one for the books. This statement shows that you > really don't understand PKI !
Of course! Why didn't I think of that :-) > Revocation checks cannot be done at the root level, by definition. The > standards don't allow support for revocation checking of self-signed certs. Oh... so it's written in the standard. Are you saying that the standard defines no way to revoke a lost CA root? Or that it is impossible to revoke a CA root? They are two entirely different things. OpenPGP does it, the keys can revoke themselves, and indeed the early docs used to exhort you to create a revocation certificate for emergency use. I don't know what SPKI does - do roots in that system revoke themselves? In my own designs, we would just go the manual route and alert everyone. No financial system permits such trust to be placed in a single point of failure; Most of the finance systems I have seen have defence in depth and layered "meltdown" plans. For example, there was Mondex's famous plan to distro new code into the cards if the crypto got cracked, and all of the cards schemes operated secret shadow accounting systems for meltdown motives (originally). > Please explain how you would make it work. If the root's private key has > been compromised (which is one of the common reasons for cert > revocations), then anybody could make a fake CRL, or run a fake OCSP > server with that key that would all say that the root cert OK, even > though clearly, it's not. Yes, of course anyone can make a fake product once they have the root, which is why the revocation (signed by the same key) needs to be distributed. Presumably once a revocation is sent around the place, it is sticky, it itself cannot be revoked? > If a self-signed cert is compromised, there is nothing automatic that > can be done to recover in X509. Do you now understand how crucial it is > to trust the right roots, and why the use of self-signed certs is so > dangerous ? Once you trust a self-signed cert, it's forever ! Please explain why a self-signed certificate cannot sign a revocation of itself? It's not as if you care if a thief does it to you... > > So in that case, any browser that has the root cert in > > its root list then is encouraged to issue a new root list, > > in an emergency patch. > > The problem is not to issue an emergency patch with a new root list, but > how to notify the users of the root that they need the update in the > first place . Yes, there is that problem too. Both the relying parties and the owners of the certs need to fix the problem. So yes, I guess this means that new certs need to be issued and installed for all merchants, and a new root needs to be distro'd for that CA. Hmmm, so this is a bit bigger of a deal than I'd thought. OK, so maybe a more likely path is to simply roll out a new root, patch the browsers as I described, and watch and wait for the phishers to use the root. > Obviously, a mozilla patch notice doesn't happen as part of every > regular certificate chain verification . And there is no way it could > happen specifically when some roots are used . If you already know which > roots are revoked, then you don't need any update ! Do you mean to say that you could issue instructions to users such that they remove certain roots from their root lists? Sure, that's another path, might be easier than patching, yes, and you could issue the new root at the same time. But as you point out, that doesn't cover the merchants who are still using the old certs. I guess the CA simply has to mail them out and hope for a faster half life. > One could make the root checking work in a standards-compliant way by > having a single trusted root in the browser - mozilla.org's. All the CA > certs that are currently roots could be replaced by certs issued by the > mozilla.org CA, which could distribute its own very little (hopefully > zero-size!) CRL . But the cost of hosting the CRL or OCSP server in that > case would be prohibitive - every client in the world would need to > access either one . Ultimately though, the size of the that's what you > need if you want to do revocation checking on "roots" Well, either CRL/OCSP works, or it won't work for Verisign who have about half the market. If these things don't scale, then there is a need to think up other ways to deal with it. > Also, the current roots would probably object to their demotion to mere > mozilla.org intermediate certs . They would probably sue for copyright > infringment on their public key or something ;) . > > And of course, in this scenario, the risk would remain that > mozilla.org's root would be compromised . But the risk is much lower > when you only trust 1 root rather than 75 ! It only takes 1 compromised > root for the whole system to fall apart. That of course is one way to look at it. I'm sure Netscape had some good reasons not to become the meta-CA when they got into the PKI biz. iang -- Advances in Financial Cryptography: https://www.financialcryptography.com/mt/archives/000458.html _______________________________________________ Mozilla-security mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-security
