httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 45708] CRL verification fails if CA have distinct AKID for CRL and client certificates
Date Mon, 10 Oct 2011 12:59:22 GMT

--- Comment #13 from Erwann Abalea <> 2011-10-10 12:59:22
UTC ---
(In reply to comment #12)
> (In reply to comment #11)
> > [...]
> > 
> > This is not conformant to X.509. The fact that this is the only possible
> > behaviour from the Microsoft PKI doesn't make it valid.
> > In the absence of any critical extension in a CRL stating that this CRL is a
> > partitioned one (the wording used in X.509 is "full scope" CRL), then this CRL
> > provides a revocation status for *all the certificates signed by the issuer*.
> > The AKI extension in the CRL is only a helper to find the correct key to
> > validate the CRL' signature, it's *not* a CRL differenciator.
> Ok, let's say the scope of the old CRL is "all the certificates issued before
> xxx" and the scope of the new CRL is "all the certificates issued after xxx".

I understand what you want. But you need to express it with a critical
extension. Please read X.509 recommendation, chapter (CRL scope
extension). The need here is to avoid a CRL substitution attack.

> > [...]
> > > For that I described before, the usage of authority key identifier and
> > > subject key identifier, during the CRL verification process, can be
> > > helpful.
> > > 
> > > So, the idea behind the patch is this:
> > > 1. Get authority key identifier (akid) from the current certificate
> > > 2. Get subject key identifier (skid) from the current certificate
> > 
> > So SKID is the key identifier of the end-user certificate, right?
> No, SKID is the key identifier of the current certificate during the loop of
> the chain verification, so it can be a CA or a subCA or an end-user
> certificate.

Ok. I worked on it some time ago, and forgot about the 2 steps method.

> > > 3. For the CRL verification (first step), look for the CRL with the
> > >    CRL issuer equal to certificate subject and CRL akid equal to
> > >    certificate skid
> > 
> > So you're trying to find a CRL emitted by the issuer, but signed by the
> > end-user key? That's wrong.
> No, the CRL verification process in mod_ssl is described in the
> ssl_callback_SSLVerify_CRL function.
> We try to check the signature of a CRL in each step when we find a CRL
> through the _subject_ name of the current certificate and the skid (we use also
> the skid because we can have more than one CRL).

The original process is already flawed, as it permits a CA to revoke itself.
This is not permitted as per X.509.
Your modification requires the CA to use the same key to sign the CRL as the
one used to sign the certificate, which is not the case with roles separation:
1 certificate to sign certificates, 1 certificate to sign CRLs.

> > > 4. For the revocation check (second step), look for the CRL with the
> > >    CRL issuer equal to certificate issuer and CRL akid equal to
> > >    certificate akid
> > 
> > This algorithm won't validate X.509 compliant PKIs, with renewed CAs (read 
> > rekeyed if you want).
> I think the specification regarding CRL is too generic: to implement a general
> CRL verification system is rather difficult.

The algorithm is well described in the X.509 recommendation, and is normative.
mod_ssl already deviates from this algorithm. Your modification enhances this

If your Microsoft PKI really does it like you described, then file a bug to
them, they're clearly doing it wrong.

In the meantime, mod_ssl CRL verification needs to be radically changed, it
doesn't check critical extensions, it doesn't follow the normative algorithm,
it can't pass the NIST's PKITS. What should be done is to use internal OpenSSL
CRL validation mechanism, which is correct.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message