[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