Re: Questions on Authority/Subject Key Identifiers

["Tom Gindin" <tgindin@xxxxxxxxxx>]

      Terry:

      The interpretation in #2 looks very dangerous.  You should not IMO
accept any certificate as a candidate to be the issuer of a given
certificate unless its subject matches the issuer field.  Outside the PKIX
profile, you might allow a case with issuer null and issuerAltName
non-null, and then match the candidate issuing certificate's subjectAltName
against issuerAltName.  I don't think that serialNumber even gets involved
in this matching.  Even the public key, let alone the key id, is a
necessary but not sufficient element of a chaining match.
      I hope somebody else will comment on #1 and #3, where I have nothing
useful to say.

            Tom Gindin

thayes@xxxxxxxxxxxx (Terry Hayes)@mail.imc.org on 09/23/2002 12:52:07 AM

Sent by:    owner-ietf-pkix@xxxxxxxxxxxx


To:    ietf-pkix@xxxxxxx
cc:
Subject:    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