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

Questions on Authority/Subject Key Identifiers



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
thayes@xxxxxxxxxxxx