[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Authority Key Identifier values



Thanks to everyone who replied!

"David A. Cooper" <david.cooper@xxxxxxxx> writes:

...
> Note that section 4.2.1.2 states:
>
>      In conforming CA certificates, the value of the
>      subject key identifier MUST be the value placed in the key identifier
>      field of the Authority Key Identifier extension (section 4.2.1.1) of
>      certificates issued by the subject of this certificate.

Aha, that was the text I wanted to find.  My mistake was to look for
it in the section describing AKI.  The text above implicitly specify
what to put in AKI fields; it might make sense to move it to (or say
something similar in) section 4.2.1.1 (on AKI's).  Section 4.2.1.1
currently says:

   The value of the keyIdentifier field SHOULD be derived from the
   public key used to verify the certificate's signature or a method
   that generates unique values.

That is correct for CA certificates, but flawed for EE certificates.
We _did_ derive the AKI from the CA's public key, but everyone agrees
that this is the wrong thing to do.  That sentence, and the absence of
the quoted text above, in section 4.2.1.1, was likely the cause for
our bug.

For those who are interested in more details, the software that
(according to our bug report) rejected the non-matching AKI/SKI was
OpenSSL version 0.9.8c.  I found a reference to why that behaviour is
sub-optimal; RFC 4158 section 3.5.12 says:

   NOTE:  Although required to be present by [RFC3280], it is extremely
   important that KIDs be used only as sorting criteria or as hints
   during certification path building.  KIDs are not required to match
   during certification path validation and cannot be used to eliminate
   certificates.  This is of critical importance for interoperating
   across domains and multi-vendor implementations where the KIDs may
   not be calculated in the same fashion.

/Simon