Hi Patrick, Hodie pr. Kal. Feb. MMVIII est, Patrick Patterson scripsit: > Hi Erwann; > > On Thursday 31 January 2008 13:07:32 Erwann ABALEA wrote: > > > Renewal is when you issue a new certificate, but keep the same keys. In > > > this case, the CRL validation in OpenSSL works fine, since the keys are > > > the same, and the only difference in the cert is a new validity and > > > serial number. > > > > OK. Let's call it "rekey" if you want, that's not a problem. We're a PKI > > operator, and we don't "renew" CAs, we only "rekey" them, then. > > Such differenciation is found nowhere in the X.509 standard, or the > > RFC3280 document (or its successor, still in draft). > > No, since this is a policy decision, the relevant document is RFC3647, which > makes a clear distinction between renewal and rekey.
Ok. Again, an RFC, of type Informational. So my argument still stands, the standards (and I include RFC3280 here even if it's not a standard, but a common practice) don't differentiate the "rekey" vs "renew" of a CA. And this has nothing to do with CRL validation. > > > One has to be very carefull when dealing with another CA that has the > > > same name but different keys, or else it would be possible for an > > > attacker to impersonate a CA. > > > > That's not possible. If it has the same name, then it's the same exact > > CA. Period. > > We're dealing here with CA certificates, with off-band verification to > > perform trust, etc. So CA impersonification is not a problem here. > > Please see this thread: > > http://www.imc.org/ietf-pkix/old-archive-04/msg01204.html I've read the whole thread, thanks. > Essentially, my take on what Santosh is saying is that CRLs need to be signed > by both CAs during the transition, because either a CA is "active" (and can > be used to validate the signature on the certificate itself) or it isn't. If > it is "active" it should sign it's own CRLs (and he doesn't preclude someone > else signing a CRL as well for that certificate, but if you do do this, then > the algorithm that he proposes in the thread should be followed, which > Stephan had a problem with, since there is a possible disambiguation problem > that could be exploited by a malicious attacker.). > > The relevant quote is as follows: "Each of the two keys > should be used to sign the full CRL for the scope of all certificates issued > by that CA under all keys. Furthermore, the same revoked certificate list > (empty or not) should be signed with all active keys. Active keys are > defined as those CA private keys whose companion public keys can still be > used to verify signatures on the certificates" What Santosh proposes here is biased, he wants to propose a solution to allow even non-comformant relying parties to be able to handle this specific case (re-key), with the MSCAPI example in head. But on the same thread, he clearly describes what should be done in the absence of IDP extensions, and the fact that a new CA key can sign the whole CRL for the whole population (without requiring the old CA key to do the same), etc. I can only redirect you to annex B of the X.509 standard, which is normative. Anyway, right now, the solution proposed by Santosh doesn't work with OpenSSL. OpenSSL refuses to load 2 CRLs with the same issuername in the same store. Make your tests. And that's "normal", from my point of view, if we don't consider the CRLDP+reason extension. My proposed patch handles this case also (again, it doesn't check the reason flag of the optional CRLDP extension). > So you can't just stop using a particular CA's keys... until it either > expires > or is revoked, it should keep issuing CRL's for the keys it has issued. And > if it keeps issuing CRL's, the situation for which you have created the patch > should never happen :). That point of view should obviously be changed after reading the rest of Santosh's posts, and the X.509 standard. > This is a rather murky subject, and the merits of the two approaches are > probably best discussed on the PKIX list, rather than here, as the approach > has little to do with the technical implementation of what you propose :) I agree CRL validation *can* be really "chiant" (sorry, my english vocabulary doesn't allow me to express those things). But without cRLIssuer, or IDP, or any fancy extensions, it can be handled quite easily. Regards, -- Erwann ABALEA <[EMAIL PROTECTED]> ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
