https://issues.apache.org/bugzilla/show_bug.cgi?id=45708
--- Comment #12 from sektor <[email protected]> 2011-10-10 10:26:31 UTC --- (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". > [...] > > 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. > > > 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). > > 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. For example, my patch solves the problem for scoped CRL based on the time, your patch solves the problem for "full scope" CRL, but a lot of cases remain uncovered. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
