Subject: Re: Questions on Authority/Subject Key Identifiers

From: "Tom Gindin" <[email-masked]>
Date: Mon, 23 Sep 2002 15:03:02 -0400

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

[email-masked] (Terry Hayes)@mail.imc.org on 09/23/2002 12:52:07 AM

Sent by:    [email-masked]

To:    [email-masked]
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
[email-masked]

---

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

Tom:

I believe that Terry is asking about the issuer/serial form of identifying 
the issuer certificate in the authority key identifier extension.  So, 
within the extension, the issuer field identifies the issuer of the 
issuer's certificate, and the serial identifies the issuer's certificate.

Russ

---

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

Russ,

Yes, this is the case that I am talking about.  All validation algorithms
(include the RFC 3280) require the matching that Tom describes.  The issue
I'm raising is the correct handling during path construction (discovery)
when a certificate seems to have contradictory information about the certificate
for the issuer.

So far I have one response in favor of  continuing to build a path as long
a one of the values in the authority key identifier extension matches the
data in the potential issuer's certificate. (Russ, please correct if I'm
misinterpreting).

Terry

Housley, Russ wrote:

Tom:

Russ

---

From: Karol Górski <[email-masked]>
Date: Tue, 24 Sep 2002 10:33:22 +0200

Quoting from X.509:2000 (section 8.2.2.1 Authority key identifier extension):

"The key may be identified by an explicit key identifier in the keyIdentifier component, by identification of a certificate for the key (giving certificate issuer in the authorityCertIssuer component and certificate serial number in the authorityCertSerialNumber component) or by both explicit key identifier and identification of a certificate for the key. If both forms of identification are used then the certificate or CRL issuer shall ensure they are consistent."

and:

"The keyIdentifier form can be used to select CA certificates during path construction. The authorityCertIssuer, authorityCertSerialNumber pair can only be used to provide preference to one certificate over others during path construction."

I interpret the last sentence in the following way: during path construction I can look for certificates which match the identifier in the keyIdentifier component. If among them I find a certificate which matches the given issuer/serial number pair I treat it as the preferred certificate to use. If not (ie. my certificate search failed to find the certificate which the CA indicated as the preferred certificate to use) then I can use any certificate among them and in this case there will be a mismatch between the issuer/serial number fields in the subject certificate and issuer certificate. However, the names must still match for validation to be succesful so I would expect that the only mismatch may be in the serial number.

Karol Gorski

----- Original Message ----- 
  From: Terry Hayes 
  To: [email-masked] ; Russ 
  Cc: Tom Gindin ; [email-masked] 
  Sent: Tuesday, September 24, 2002 12:15 AM
  Subject: Re: Questions on Authority/Subject Key Identifiers

  Russ,

  Yes, this is the case that I am talking about. Â All validation algorithms (include the RFC 3280) require the matching that Tom describes. Â The issue I'm raising is the correct handling during path construction (discovery) when a certificate seems to have contradictory information about the certificate for the issuer.

  So far I have one response in favor of Â continuing to build a path as long a one of the values in the authority key identifier extension matches the data in the potential issuer's certificate. (Russ, please correct if I'm misinterpreting).

  Terry

  Housley, Russ wrote: 

    Tom: 

    I believe that Terry is asking about the issuer/serial form of identifying 
    the issuer certificate in the authority key identifier extension.Â  So, 
    within the extension, the issuer field identifies the issuer of the 
    issuer's certificate, and the serial identifies the issuer's certificate. 

    Russ 

    At 03:03 PM 9/23/2002 -0400, Tom Gindin wrote: 

    >Â Â Â Â Â Â  Terry: 
    > 
    >Â Â Â Â Â Â  The interpretation in #2 looks very dangerous.Â  You should not IMO 
    >certificate unless its subject matches the issuer field.Â  Outside the PKIX 
    >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 
    >Â Â Â Â Â Â  I hope somebody else will comment on #1 and #3, where I have nothing 
    >useful to say. 
    > 
    >Â Â Â Â Â Â Â Â Â Â Â Â  Tom Gindin 
    > 
  My original question:

    >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

---

From: "Peter Hesse" <[email-masked]>
Date: Fri, 27 Sep 2002 15:18:51 -0400

Karol,

I am not sure that I agree with your interpretation.  It is not clear to me
that AKID/SKID must match for a path to be considered valid.  In fact, I
think that it would be best for path development operations to be written
flexible enough to deal with cases in which AKID/SKID do not match, no
matter which form of AKID is being used.

Here's where I'm coming from: most CA products currently available do not
allow the specification of the subject key identifier of a CA that they are
to cross-certify with.  For example, if A is to cross-certify B, A must
ensure that the certificate A issues to B contains a subject key identifier
that matches the authority key identifier in all certificates B issues.

Currently, when most CA products perform cross-certification, they calculate
the SKID based upon the public key.  Hopefully, if the CAs are the same
brand, or due to luck or configuration, they will calculate the SKID in the
same fashion.  However, since there are no guarantees on how the SKID is
calculated (the methods provided in RFC 2459/3280 are just common methods,
not requirements) it is quite possible that this will result in a mismatch.

If your path development algorithm cannot handle this mismatch, you will be
unable to build a path when a valid one exists.  Certainly matching
AKID/SKID should take priority over those that do not, but last I checked
there is nothing in the certificate path validation process for X.509, RFC
2459, or RFC 3280 that fails a path based upon a mismatched AKID/SKID.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been
a statue set up in honor of a critic." --Jean Sibelius

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Karol Górski
  Sent: Tuesday, September 24, 2002 4:33 AM
  To: Terry Hayes; [email-masked]; Russ
  Cc: Tom Gindin; [email-masked]
  Subject: Re: Questions on Authority/Subject Key Identifiers

  Quoting from X.509:2000 (section 8.2.2.1 Authority key identifier
extension):

  "The key may be identified by an explicit key identifier in the
keyIdentifier component, by identification of a certificate for the key
(giving certificate issuer in the authorityCertIssuer component and
certificate serial number in the authorityCertSerialNumber component) or by
both explicit key identifier and identification of a certificate for the
key. If both forms of identification are used then the certificate or CRL
issuer shall ensure they are consistent."

  and:

  "The keyIdentifier form can be used to select CA certificates during path
construction. The authorityCertIssuer, authorityCertSerialNumber pair can
only be used to provide preference to one certificate over others during
path construction."

  I interpret the last sentence in the following way: during path
construction I can look for certificates which match the identifier in the
keyIdentifier component. If among them I find a certificate which matches
the given issuer/serial number pair I treat it as the preferred certificate
to use. If not (ie. my certificate search failed to find the certificate
which the CA indicated as the preferred certificate to use) then I can use
any certificate among them and in this case there will be a mismatch between
the issuer/serial number fields in the subject certificate and issuer
certificate. However, the names must still match for validation to be
succesful so I would expect that the only mismatch may be in the serial
number.

  Karol Gorski

  ----- Original Message -----
    From: Terry Hayes
    To: [email-masked] ; Russ
    Cc: Tom Gindin ; [email-masked]
    Sent: Tuesday, September 24, 2002 12:15 AM
    Subject: Re: Questions on Authority/Subject Key Identifiers

    Russ,

    Yes, this is the case that I am talking about. Â All validation
algorithms (include the RFC 3280) require the matching that Tom describes. Â
The issue I'm raising is the correct handling during path construction
(discovery) when a certificate seems to have contradictory information about
the certificate for the issuer.

    So far I have one response in favor of Â continuing to build a path as
long a one of the values in the authority key identifier extension matches
the data in the potential issuer's certificate. (Russ, please correct if I'm
misinterpreting).

    Terry

    Housley, Russ wrote:

      Tom:

      I believe that Terry is asking about the issuer/serial form of
identifying
      the issuer certificate in the authority key identifier extension.Â
So,
      within the extension, the issuer field identifies the issuer of the
      issuer's certificate, and the serial identifies the issuer's
certificate.

      Russ