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

Re: Authority Key Identifier values
In general, each CA should determine the key identifier value for its own key pair. If the CA generates a self-signed certificate, it should place that key identifier value in the subjectKeyIdentifier extension of the self-signed certificate. It should also place that key identifier value in the authorityKeyIdentifier extension of all non-self-signed certificates that it signs with the corresponding private key. When selecting a key identifier, the CA should follow the guidance in section 4.2.1.2 for deriving key identifiers.
When issuing cross-certificate (i.e., a CA certificate in which the issuer and subject are different CAs), the issuer should use the key identifier value provided by the subject in the subjectKeyIdentifer extension rather than computing a value for inclusion in the extension.
In a hierarchical PKI, it may be acceptable for a superior CA to select the key identifier for a subordinate CA's key pair, include that key identifier in the subjectKeyIdentifier extension of a certificate issued to the subordinate CA, and then expect the subordinate CA to use that key identifier in the authorityKeyIdentifier extension of all certificates that the subordinate CA issues. But, in a non-hierarchical environment, in which a CA may be issued cross-certificates by several other CAs, the only option is for the CA to select the key identifier for its key pair and then request that any CA that issues it a certificate include that key identifier in the subjectKeyIdentifer extension. 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.  Applications
     are not required to verify that key identifiers match when performing
     certification path validation.

Dave

Simon Josefsson wrote:

Hi!  I'm not certain how to populate the Authority Key Identifiers
field, and draft-ietf-pkix-rfc3280bis-07.txt appear to give me two
different solutions to my problem.  I'd appreciate some advice here.

Our problem is when signing new certificates, the Authority Key
Identifier fields we generate for the new certificate doesn't
necessarily match the Subject Key Identifier field in the CA
certificate.  Our current logic is to set the AKI in the new cert to
what we compute for the public key used for signing.  Presumably, this
was based on the following requirement in the AKI-section 4.2.1.1:

   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.

Let's call that Approach A.

This leads to problems when someone uses software that uses another
algorithm to compute the Key Identifier values.  The CA certificate
for a public key P will contain a SKI of H(P)=X, which is all fine,
but the EEC we generate will contain an AKI of H'(P)=Y.  The algorithm
H and H' are those discussed in section 4.2.1.2 or, as the text
permits, any other method.  Essentially, H appears to be
non-standardized.

My common sense, and section 4.2.1.1, suggests that another approach
can be used:

   The authority key identifier extension provides a means of
   identifying the public key corresponding to the private key used to
   sign a certificate.  ... The identification MAY be based on either
   the key identifier (the subject key identifier in the issuer's
   certificate) or ...

This suggests to me that implementations should copy the SKI from the
CA cert used when signing into the AKI in the new certificate.
(Approach B.)

Which approach is correct?  Am I reading the standard incorrectly
here, or is there room for improvement?  There seems to be no real
strong language on what the AKI value MUST be set to when generating
certificates, at least no text that I've found.

A related question is whether non-matching AKI/SKI's should trigger
certificate chain validation failures.  I cannot find where such a
check is required in draft-ietf-pkix-rfc3280bis-07.txt.  We know there
are software out there that performs this test, since that is what
prompted me to debug this problem.  Would such behaviour be incorrect?

/Simon