On 3/17/06, Erwann ABALEA <[EMAIL PROTECTED]> wrote: > Hodie post. Id. Mar. MMVI est, Kyle Hamilton scripsit: > > There's no problem with the X.509 model. > > You're right that a certificate signed by a CA can be revoked by > another CA which has the same exact DN (not CN). The reason is simple: > the X.509 standard states that a CA is designated by its name, not by > its certificate (or public key). That has 2 advantages: > - a CA can have different keys for certificate signing and CRL > signing,
I believe X.509v3 created an explicit extension for a second certificate with the same DN that the actual root certificate signed, for CRL signing. X.509 itself (X.509v1) didn't have 'extensions', as can be seen with the original Verisign v1 root certificates. > - a CA can be renewed without invalidating all the previous > certificates, and still take them under its "control". A CA can be renewed with rekey, specifically. But as you point out, there's no automatic way to get this to work -- though the "identification by name" concept has a problem, as shown below... > But what you're trying to say (that Mr Bad could create a certificate > with the same DN as a valid CA, and revoke certs emitted by this CA > without other intervention) is simply false. You *must* tell the > software to trust this certificate, there's no way for this to be > automatic (except in the SET scheme, but that's not the point here). Actually, Thunderbird/NSS (which used the same cert store as Firefox -- it may still, but this was back in the pre-1.0 days) got hit with a DOS related to this, as I mentioned in a prior mail on this list a month or so ago. A new CA certificate with the same DN was sent out in the certificate chain for an email, and it didn't match the current one, so the user gets prompted, and (obviously) chooses not to accept it. This caused the 'new' CA certificate to be placed in the "untrusted" store. After that, anything presented to NSS that was signed by the real CA in question (since it was identified by DN, not by DN,pubkeyhash tuple) was then rejected, because the DN was first checked against the untrusted store (explicit distrust) and then against the trusted store (in this case, implicit trust from the builtin object token) before any cryptographic operations took place. Which is, again, a problem with the X.509 model. X.509v3 is an attempt to work around some of these functional issues, without fixing all of them. -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
