Subject: Authority Key Identifier values

From: Simon Josefsson <[email-masked]>
Date: Wed, 31 Jan 2007 11:52:19 +0100

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 31 Jan 2007 04:24:46 -0800

Approach B should be used so that AKID and SKID chain.  It is less
critical how the AKID and SKID are calculated (that is why 3280 say
"SHOULD" for the algorithm and not MUST or SHALL).

As to path validation, AKID SKID must not be matched.  Again, see 3280
Section 6.  There is no rule for it.

But, AKID/SKID should be used in path development to prefer paths that
are likely to succeed.  The most likely benefit of this preference in
path development is to filter our CA certificates (e.g., due to re-key)
that are not likely to lead to success.   (If you use HTTP AIA and give
a new name to  each HTTP resource when the CA re-keys, you will always
have only one certificate to check in the Enterprise PKI architecture
where a CA has only one parent).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Simon Josefsson
Sent: Wednesday, January 31, 2007 5:52 AM
To: [email-masked]
Subject: Authority Key Identifier values

/Simon

---

From: Stephen Kent <[email-masked]>
Date: Wed, 31 Jan 2007 08:07:54 -0500

At 11:52 AM +0100 1/31/07, Simon Josefsson wrote:
>certificate.

Then you have a bug :-).

The text in 3280 that allows for choices in how to generate an 
AKI/SKI is not meant to override the path discovery logic that 
motivates the existence of these extensions. The choices offered re 
how to compute these values are there to accommodate different 
AKI/SKI determination options, but one must still maintain 
consistency between the option used for both values, when acting as a 
CA (vs. as a subject). If you don't, then RPs cannot make use of the 
AKI/SKI pair to disambiguate among multiple CA certs with the same 
Subject name.

>...

The SKI/AKI extensions are used for path discovery, not path 
validation, so one ought not consider a cert invalid if these fields 
do not match.

Steve

---

From: Russ Housley <[email-masked]>
Date: Wed, 31 Jan 2007 09:27:11 -0500

The point is to aid in cert path construction, so the values need to match.

Russ

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 31 Jan 2007 10:45:54 -0500

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