Subject: [pkix] Is it required that subject AKI actually match issuer SKI?

From: Jeffrey Walton <[email-masked]>
Date: Sat, 4 Apr 2015 19:13:42 -0400

I'm reading through RFC 5280, 4.2.1.1 Authority Key Identifier and
4.2.1.2 Subject Key Identifier.

I might be missing it, but I don't see where the subject's AKI is
required to match the issuer's SKI when the extension is present. The
closest I can find is from Authority Key Identifier (p. 26):

   The value of the keyIdentifier field SHOULD be derived from the
   public key used to verify the certificate's signature or a method
   that generates unique values.

I think the SHOULD is weak, and allows me to generate a random value
for the AKI that does not match anything.

Is it required that subject actually AKI match issuer SKI? Put another
way, should I fail path validation if the path is otherwise valid (but
AKI does not match SKI)?

---

From: Brian Smith <[email-masked]>
Date: Sat, 4 Apr 2015 14:19:56 -1000

"Applications are not required to verify that key identifiers match
when performing certification path validation." -
http://tools.ietf.org/html/rfc5280#section-4.2.1.2

On Sat, Apr 4, 2015 at 1:13 PM, Jeffrey Walton <[email-masked]> wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Michael StJohns <[email-masked]>
Date: Mon, 06 Apr 2015 12:31:12 -0400

This turns out to be one of those things that makes you want to hit your head against the wall.  Brian has the correct cite for path validation, however "path formation" generally depends on matching AKI SKI pairs to select the right set of certificates for path validation and you do path formation before you do path validation.  

Alternately, you can try all possible matching SubjectName/IssuerName parent certificates to try and find a path through. (or if the AKI uses components [1] and [2] but not [0] do it that way).

Lastly, when you ISSUE such certificates, the AKI (if it uses component [0]) and SKI of the issuer (if present) should match... (and reading 5280, I see the language is actually wrong... *sigh*).  And how did we miss this for so long?   

Time for an errata.  

Mike

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 6 Apr 2015 12:41:10 -0400

> Lastly, when you ISSUE such certificates, the AKI (if it uses component [0]) and SKI of the issuer (if present) should match... (and reading 5280, I see the language is actually wrong... *sigh*).…

Oh, OK. If text is going to be changed, please consider adding some
verbiage so continuity is present between AKI and SKI.

As it stands, the intent or requirement does not seem to flow from one
to the other. That is, the subject's AKI must be present, but it does
not actually have to match a signer's SKI. I think there's an implicit
assumption that it will match, but its not really stated (unless I am
misreading it).

I think we are talking about the same thing, but I wanted to say it
just in case.

Jeff

---

From: Erwann Abalea <[email-masked]>
Date: Mon, 6 Apr 2015 18:55:09 +0200

2015-04-06 18:41 GMT+02:00 Jeffrey Walton <[email-masked]>:

> > This turns out to be one of those things that makes you want to hit your
> head against the wall.  Brian has the correct cite for path validation,
> however "path formation" generally depends on matching AKI SKI pairs to
> select the right set of certificates for path validation and you do path
> formation before you do path validation.
> >
> > Alternately, you can try all possible matching SubjectName/IssuerName
> parent certificates to try and find a path through. (or if the AKI uses
> components [1] and [2] but not [0] do it that way).
> >
> > Lastly, when you ISSUE such certificates, the AKI (if it uses component
> [0]) and SKI of the issuer (if present) should match... (and reading 5280,
> I see the language is actually wrong... *sigh*).  And how did we miss this
> for so long?
> >
> > Time for an errata.
>

AKI/SKI matching is not mandatory in the normative X.509 validation
algorithm either. Is it necessary to introduce another difference in
behaviour between X.509 and RFC5280 validation algorithms?

-- 
Erwann.

---

From: Michael StJohns <[email-masked]>
Date: Mon, 06 Apr 2015 13:06:18 -0400

At 12:55 PM 4/6/2015, Erwann Abalea wrote:

>2015-04-06 18:41 GMT+02:00 Jeffrey Walton <<mailto:[email-masked]>[email-masked]>:
>On Mon, Apr 6, 2015 at 12:31 PM, Michael StJohns <<mailto:[email-masked]>[email-masked]> wrote:
>> This turns out to be one of those things that makes you want to hit your head against the wall.Â  Brian has the correct cite for path validation, however "path formation" generally depends on matching AKI SKI pairs to select the right set of certificates for path validation and you do path formation before you do path validation.
>>
>> Lastly, when you ISSUE such certificates, the AKI (if it uses component [0]) and SKI of the issuer (if present) should match... (and reading 5280, I see the language is actually wrong... *sigh*).Â  And how did we miss this for so long?
>>
>> Time for an errata.
>
>AKI/SKI matching is not mandatory in the normative X.509 validation algorithm either. Is it necessary to introduce another difference in behaviour between X.509 and RFC5280 validation algorithms?

Please see the text I just sent.  I'm not proposing changing the validation algorithm, just cleaning up the issuing guidance.

Later, Mike

---

From: Stephen Kent <[email-masked]>
Date: Mon, 06 Apr 2015 15:06:58 -0400

Jeff,

The motivation for SKI/AKI matching arises in path construction of path 
finding, not path validation.

It is an optimization, an alternative way to quickly find the right 
parent CA cert when there may be more than one with the same Subject 
name, e.g., during key rollover or in te case of cross certification.

Also recall that there is no standard for path construction. In path 
validation, the signature and issuer/subject checks are enough, so 
AKI/SKI matching is redundant.

Steve
>> ...

---

From: [email-masked] (Martin Rex)
Date: Wed, 8 Apr 2015 18:36:35 +0200 (CEST)

I'm missing the really important issue in this discussion, and that is:

  It will be perfectly OK for an RP to REJECT a certificate chain based
  on the fact that AKI->SKI chaining in provided certificate chain does
  not match.

Therefore the creation of a certification path that uses AKI in a
non-self-signed certificate that does not match the SKI of the next
level CA certificate would indicate a seriously defective CA.

To avoid such problems (in cross-CA scenarios), Certificate Signing
Requests (CSRs) from CAs ought to ALWAYS include the SKI of the
first CA certificate that was created with that Subject+public key,
in order to ensure that all future cross-CA certificates will contain
the very same SKI as the original CA certificate, matching the AKI in
certificates issued by that CA.

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Fri, 10 Apr 2015 11:14:41 -0400

Martin,

>    on the fact that AKI->SKI chaining in provided certificate chain does
definitely not true, other than the "right" of any RP to reject any cert 
for
any (locally defined) reason.
> level CA certificate would indicate a seriously defective CA.
mostly not true.

Steve

---

From: [email-masked] (Martin Rex)
Date: Fri, 10 Apr 2015 20:44:55 +0200 (CEST)

Stephen Kent wrote:
> for any (locally defined) reason.
>

I am aware that a number of implementors do not realize such problems.

Maybe the issue becomes clearer when I explain how this affects
implementations.

When a digital signature verification fails, there are the following
common causes of the verification failure:

 (1)  the signed data was changed/corrupted (or wrong data, e.g. XMLdsig)
 (2)  the verifier used the wrong public key for verification
 (3)  the signature blob was changed/corrupted

and a relatively rare reason for failure:
 (4)  the public key used for the verification is corrupted

(3) is a little difficult to handle unless the corruption is obvious
    (incorrect size or incorrect encoding)

(2) is unfortunately common problem, but when RSA PKCS#1 v1.5 signatures
    are used, then this failure can be nicely distinguished from (1)

When analyzing/troubleshooting failing interop scenarios, being able to
distinguish failure reason (1) from (2) is pretty important, in particular
for stuff like WSSec/XMLdsig.

A similar problem exists for X.509 because of a silly concept called
"self-issued certificate", which ought to have been prohibited, but wasn't.

With signature schemes such as DSA, ECDSA and RSA-PSS, failure cases
(1) and (2) are indistinguishable within the signature verify operation,
so it is perfectly sensible of PKI implementations to use AKI->SKI
chaining when building a certificate path or when verifying a
certificate path.

There is no _requirement_ for RPs to perform AKI->SKI matching when
composing certificate chains or when verifying certificate chains,
but it will be extremely reasonable for RPs to perform such matching
*whenever* an AKI is present in the subordinate certificate *PLUS* an SKI
is present in the CA certificate -- and fail with an error upfront,
skipping the magnitudes more costly public key crypto operation when
these two do not match.

It would be irresponsible for CAs to create cross-CA certificates without
ensuring that they use the EXACT SAME SKI that is used in the original
CA cert and which appears as AKI in all certificates signed by that CA.

-Martin

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 13 Apr 2015 07:18:25 -0400

This document was just posted at the ongoing
ITU-T SG17 meeting for adoption this week.
It was prepared by the two authors.

It would be very useful for those participating
in the meeting to know the PKIX views on these
proposed changes.   A number of them involve
IETF RFCs.

--tony

---

From: "Erik Andersen" <[email-masked]>
Date: Mon, 13 Apr 2015 14:20:21 +0200

Just to clear some (intentional?) misunderstanding.

This document was not prepared by two authors. It has for a long time been
on our web-page (see
http://www.x500standard.com/index.php?n=Ig.DraftTechnicalCorrigenda). It was
discussed on the Directory list and there was input for such distinguished
PKI experts as David Chadwick, Denis Pinkas and Santosh Chokhani.  Many
others had the change to contribute. I feel quite comfortable that the
referenced document is the result of a consensus process.

We, of course, welcome any constructive comments.

Erik

-----Oprindelig meddelelse-----
Fra: pkix [mailto:[email-masked]] På vegne af Tony Rutkowski
Sendt: 13. april 2015 13:18
Til: [email-masked]
Emne: [pkix] Draft technical corrigendum to Rec. ITU-T X.509

This document was just posted at the ongoing ITU-T SG17 meeting for adoption
this week.
It was prepared by the two authors.

It would be very useful for those participating in the meeting to know the
PKIX views on these
proposed changes.   A number of them involve
IETF RFCs.

--tony