Subject: Questions on Authority/Subject Key Identifiers

From: [email-masked] (Terry Hayes)
Date: Sun, 22 Sep 2002 21:52:07 -0700

I have some questions about the use of the authority key identifier and subject
key identifier fields during the construction of certificate paths. The PKIX
RFC is clear that these extensions do not have a role during the path validation
phase, however there seem to be ambiguities in how they should be used to
build the path.  These gray areas may lead to interoperability problems when
application software fails to build (or rejects) a certain certificate path.

Let me say that some of these questions assume certificates may not follow
the PKIX profile as written.  In particular, these situations assume that
key identifier extensions may be missing, where they are required by the
profile. These questions apply when software is allowing a broader range
of certificates than described by the PKIX profile.

1)  Assume an authority key identifier extension with a populated keyIdentifier
is present in a certificate. Should a corresponding subject key identifier
field be REQUIRED in the issuer's certificate?  That is, should candidate
certificates for the issuer be rejected because the subject key identifier
is missing?

2) Assume that both the keyIdentifier and issuer name/serial number fields
of the authority key identifier are present in a certificate.  Should both
values match the issuer's certificate?  Would it make sense to use a certificate
for the issuer that matches keyIdentifier fields, even though it doesn't
match the issuer name/serial number values?

3) Assume that a self-issued certificate (matching subject and issuer names)
contains only a subject key identifier extension (the authority key identifier
is omitted as suggested in the RFC). Is it reasonable to assume this certificate
is self signed, and terminate the construction of the path?

I would appreciate your thoughts on these situations.

Terry Hayes

[email-masked]

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 23 Sep 2002 16:36:05 -0400

Terry:

As you said in the introduction to your questions, these questions are 
really beyond the scope of the PKIX RFCs, but I will share my opinion.

>I have some questions about the use of the authority key identifier and 
>subject key identifier fields during the construction of certificate 
>paths. The PKIX RFC is clear that these extensions do not have a role 
>during the path validation phase, however there seem to be ambiguities in 
>how they should be used to build the path.  These gray areas may lead to 
>interoperability problems when application software fails to build (or 
>rejects) a certain certificate path.
>
>1)  Assume an authority key identifier extension with a populated 
>keyIdentifier is present in a certificate. Should a corresponding subject 
>key identifier field be REQUIRED in the issuer's certificate?  That is, 
>should candidate certificates for the issuer be rejected because the 
>subject key identifier is missing?

No.  These are not needed for the certificate path validation algorithm to 
be successful.

>values match the issuer's certificate?  Would it make sense to use a 
>certificate for the issuer that matches keyIdentifier fields, even though 
>it doesn't match the issuer name/serial number values?

Yes.  These are not needed for the certificate path validation algorithm to 
be successful.

>3) Assume that a self-issued certificate (matching subject and issuer 
>names) contains only a subject key identifier extension (the authority key 
>identifier is omitted as suggested in the RFC). Is it reasonable to assume 
>this certificate is self signed, and terminate the construction of the path?

I do not understand this one.  Self-issued certificates can appear in the 
middle of valid paths.  I expect them to occur during key rollover for an 
intermediate CA.

Russ

---

From: [email-masked] (Terry Hayes)
Date: Mon, 23 Sep 2002 15:22:19 -0700

Housley, Russ wrote:

Terry:

Agreed, and thanks for responding.

intermediate CA.

Yes, I agree that these certificates may appear in the middle of paths.  I'm
looking for a rule to tell when the certificate is actually self-signed,
and therefore a "root".

I'm suggesting that roots may omit the authority key identifier extension,
or may have one with data that matches the subject key identifier in the
same certificate.  Other self-issued certificates would need to contain both
key identifier extensions, with different values.

Terry

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 24 Sep 2002 09:48:39 -0400

Terry:

>Yes, I agree that these certificates may appear in the middle of 
>paths.  I'm looking for a rule to tell when the certificate is actually 
>self-signed, and therefore a "root".
>
>same certificate.  Other self-issued certificates would need to contain 
>both key identifier extensions, with different values.

I do not think that self-issued is the appropriate "flag" for a trust 
anchor.  An implementation needs to know all of its trust anchors.  So, 
when self-issued certificates are the way that trust anchors are 
ingratiated, you could search the list of trust anchors when a self-issued 
certificate is encountered.  But, do not stop path construction if the 
self-issued certificate does not represent a trust anchor.

Russ