Subject: [pkix] Suggested replacement text for RFC5280, section 4.2.1.1

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

I realized there may be a problem in 5280 during this recent discussion.   The formation of the AKI keyIdentifier value derivation is probably incorrect or at the best incomplete.

Replace paragraph beginning "The value of the keyIdentifier...." in its entirety with:

If the Issuer has a certificate of its own (e.g. an intermediate CA or a trust root expressed as a certificate) and that certificate contains a SubjectKeyIdentifier extension, then the keyIdentifier field of this extension MUST be present and MUST contain the same value as that in the Issuer's SubjectKeyIdentifier.   

If the Issuer does not have a SubjectKeyIdentifier extension (either because it is a root not expressed as a certificate or because its certificate does not contain the extension), then the keyIdentifier of this extension SHOULD be derived from the public key used to verify the certificate's signature using one of the two methods described in 4.2.1.2. 

The extension may OPTIONALLY include either both or neither of the authorityCertIssuer and authorityCertSerial number fields - they must be included or excluded together.  Since these are only useful in the third or greater certificate in a chain, it is expected that the presence of these fields will be rare.

_____________________________________
Rationale:  The current language mirrors that in the SKI  section 4.2.1.2 which doesn't actually make a lot of sense. You don't want the AKI to be independent of the SKI if you can avoid it.   I think this change is still backwards compatible since path validation doesn't require these match.

Mike

---

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

2015-04-06 18:49 GMT+02:00 Michael StJohns <[email-masked]>:

>  I realized there may be a problem in 5280 during this recent
> discussion.   The formation of the AKI keyIdentifier value derivation is
> probably incorrect or at the best incomplete.
>
> If the Issuer has a certificate of its own (e.g. an intermediate CA or a
> trust root expressed as a certificate) and that certificate contains a
> SubjectKeyIdentifier extension, then the keyIdentifier field of this
> extension MUST be present and MUST contain the same value as that in the
> Issuer's SubjectKeyIdentifier.
>
> If the Issuer does not have a SubjectKeyIdentifier extension (either
> because it is a root not expressed as a certificate or because its
> certificate does not contain the extension), then the keyIdentifier of this
> extension SHOULD be derived from the public key used to verify the
> certificate's signature using one of the two methods described in 4.2.1.2.
>
> The extension may OPTIONALLY include either both or neither of the
> authorityCertIssuer and authorityCertSerial number fields - they must be
> included or excluded together.  Since these are only useful in the third or
> greater certificate in a chain, it is expected that the presence of these
> fields will be rare.
>
> Rationale:  The current language mirrors that in the SKI  section 4.2.1.2
> which doesn't actually make a lot of sense. You don't want the AKI to be
> independent of the SKI if you can avoid it.   I think this change is still
> backwards compatible since path validation doesn't require these match.
>

What if the Issuer has 2 certificates, with 2 different keyIdentifier
values? (method 1 and method 2, for example).

-- 
Erwann.

---

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

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

>2015-04-06 18:49 GMT+02:00 Michael StJohns <<mailto:[email-masked]>[email-masked]>:
>I realized there may be a problem in 5280 during this recent discussion.Â Â  The formation of the AKI keyIdentifier value derivation is probably incorrect or at the best incomplete.
>
>If the Issuer has a certificate of its own (e.g. an intermediate CA or a trust root expressed as a certificate) and that certificate contains a SubjectKeyIdentifier extension, then the keyIdentifier field of this extension MUST be present and MUST contain the same value as that in the Issuer's SubjectKeyIdentifier.Â Â  
>
>The extension may OPTIONALLY include either both or neither of the authorityCertIssuer and authorityCertSerial number fields - they must be included or excluded together.Â  Since these are only useful in the third or greater certificate in a chain, it is expected that the presence of these fields will be rare.
>
>Rationale:Â  The current language mirrors that in the SKIÂ  section 4.2.1.2 which doesn't actually make a lot of sense. You don't want the AKI to be independent of the SKI if you can avoid it.Â Â  I think this change is still backwards compatible since path validation doesn't require these match.
>
>
>What if the Issuer has 2 certificates, with 2 different keyIdentifier values? (method 1 and method 2, for example).

Umm... if they both refer to the same public key, then pick one or the other - its a mostly don't care.  The functional matching is from the SKI to the AKI not the reverse.  If they don't refer to the same public key, then pick the one that can be used to verify the certificate.

---

From: Erwann Abalea <[email-masked]>
Date: Mon, 6 Apr 2015 19:26:15 +0200

Le 6 avr. 2015 19:04, "Michael StJohns" <[email-masked]> a écrit :
>> 2015-04-06 18:49 GMT+02:00 Michael StJohns <[email-masked] >:
discussion.Â Â  The formation of the AKI keyIdentifier value derivation is
probably incorrect or at the best incomplete.
trust root expressed as a certificate) and that certificate contains a
SubjectKeyIdentifier extension, then the keyIdentifier field of this
extension MUST be present and MUST contain the same value as that in the
Issuer's SubjectKeyIdentifier.Â Â
authorityCertIssuer and authorityCertSerial number fields - they must be
included or excluded together.Â  Since these are only useful in the third
or greater certificate in a chain, it is expected that the presence of
these fields will be rare.
>> Rationale:Â  The current language mirrors that in the SKIÂ  section
4.2.1.2 which doesn't actually make a lot of sense. You don't want the AKI
to be independent of the SKI if you can avoid it.Â Â  I think this change
is still backwards compatible since path validation doesn't require these
match.
>
>
> Umm... if they both refer to the same public key, then pick one or the
other - its a mostly don't care.  The functional matching is from the SKI
to the AKI not the reverse.  If they don't refer to the same public key,
then pick the one that can be used to verify the certificate.

My example was with the same public key.
Having a MUST that can potentially be wrong with valid use-cases isn't nice.
I was thinking about cross-certified CAs.

---

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

At 01:26 PM 4/6/2015, Erwann Abalea wrote:

>LeÂ 6 avr. 2015 19:04, "Michael StJohns" <<mailto:[email-masked]>[email-masked]> a Ã©critÂ :
>>
>>> 2015-04-06 18:49 GMT+02:00 Michael StJohns <<mailto:[email-masked]>[email-masked] >:
>>> I realized there may be a problem in 5280 during this recent discussion.Ã‚ Ã‚Â  The formation of the AKI keyIdentifier value derivation is probably incorrect or at the best incomplete.
>>>
>>> If the Issuer has a certificate of its own (e.g. an intermediate CA or a trust root expressed as a certificate) and that certificate contains a SubjectKeyIdentifier extension, then the keyIdentifier field of this extension MUST be present and MUST contain the same value as that in the Issuer's SubjectKeyIdentifier.Ã‚ Ã‚Â  
>>>
>>> The extension may OPTIONALLY include either both or neither of the authorityCertIssuer and authorityCertSerial number fields - they must be included or excluded together.Ã‚Â  Since these are only useful in the third or greater certificate in a chain, it is expected that the presence of these fields will be rare.
>>>
>>> Rationale:Ã‚Â  The current language mirrors that in the SKIÃ‚Â  section 4.2.1.2 which doesn't actually make a lot of sense. You don't want the AKI to be independent of the SKI if you can avoid it.Ã‚ Ã‚Â  I think this change is still backwards compatible since path validation doesn't require these match.
>>>
>>>
>> Umm... if they both refer to the same public key, then pick one or the other - its a mostly don't care.Â  The functional matching is from the SKI to the AKI not the reverse.Â  If they don't refer to the same public key, then pick the one that can be used to verify the certificate.Â  
>

I don't think you're thinking this through.   You have two issuer certificates A and B.  They have different  SubjectKeyIdentifier extensions  A.SKI and B.SKI.    The issuer, when it issues the subject certificate S picks either A or B as the issuing certificate and copies the SubjectName and SubjectKeyIdentifier from that certificate to the IssuerName and AKI of the subject certificate respectively.   

When validating the subject certificate, the acceptor grabs the AKI from the subject certificate along with the Issuer Name and goes looking for a matching CA certificate eventually finding the certificate that the ISSUER selected.  

I'm pretty sure all that works.

Or would you like to provide an example - comprehensive please - where this doesn't work?  Detail both the issuing side and the validation side please.

Later, Mike

---

From: Erwann Abalea <[email-masked]>
Date: Mon, 6 Apr 2015 21:29:24 +0200

2015-04-06 20:13 GMT+02:00 Michael StJohns <[email-masked]>:

> LeÂ 6 avr. 2015 19:04, "Michael StJohns" <[email-masked]> a Ã©critÂ
> :
> >
> discussion.Ã‚ Ã‚Â  The formation of the AKI keyIdentifier value derivation
> is probably incorrect or at the best incomplete.
> >>
> >> If the Issuer has a certificate of its own (e.g. an intermediate CA or
> a trust root expressed as a certificate) and that certificate contains a
> Issuer's SubjectKeyIdentifier.Ã‚ Ã‚Â
> >>
> included or excluded together.Ã‚Â  Since these are only useful in the third
> >> Rationale:Ã‚Â  The current language mirrors that in the SKIÃ‚Â  section
> to be independent of the SKI if you can avoid it.Ã‚ Ã‚Â  I think this
> change is still backwards compatible since path validation doesn't require
> these match.
> >>
> >>
> other - its a mostly don't care.Â  The functional matching is from the SKI
> to the AKI not the reverse.Â  If they don't refer to the same public key,
> then pick the one that can be used to verify the certificate.Â
>
> I don't think you're thinking this through.   You have two issuer
> certificates A and B.  They have different  SubjectKeyIdentifier
> extensions  A.SKI and B.SKI.    The issuer, when it issues the subject
> certificate S picks either A or B as the issuing certificate and copies the
> SubjectName and SubjectKeyIdentifier from that certificate to the
> IssuerName and AKI of the subject certificate respectively.
>

Ok for your 2 issuer certificates A and B for the same CA. So A.subjectName
== B.subjectName. Same public key in the example, but A.SKI != B.SKI (for
whatever reason). If this CA issues a certificate C, and the paragraph is
changed as described, then C.AKI.keyId will be either equal to A.SKI or
B.SKI (but not both). Does the fact that C.AKI.keyId cannot be equal to
both contradict the MUST? If not, what's the purpose of this change?

When validating the subject certificate, the acceptor grabs the AKI from
> the subject certificate along with the Issuer Name and goes looking for a
> matching CA certificate eventually finding the certificate that the ISSUER
> selected.
>

Let's say C.AKI.keyId = A.SKI.
If the validator follows your logic (consider only certificates with the
correct SKI in addition to the subjectName), then certificate B will never
be considered. If B links to a trust anchor while A doesn't (from the
validator point of view), validation fails.

> I'm pretty sure all that works.

It sometimes work (and sometimes fail) if the validator uses the AKI, it
will always work if the validator doesn't really care about the AKI.

So if the AKI doesn't provide super useful information for the validator
that MUST be checked, I don't see the point of being strict on what CAs set
it to.

The same reasoning can be used with
AKI.{authorityCertIssuer,authorityCertSerialNumber}, which will obviously
be different whatever the situation.

-- 
Erwann.

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 6 Apr 2015 15:49:08 -0400

On Mon, Apr 6, 2015 at 3:29 PM, Erwann Abalea <[email-masked]> wrote:
>> ...
>> certificates A and B.  They have different  SubjectKeyIdentifier extensions
>> A.SKI and B.SKI.    The issuer, when it issues the subject certificate S
>> picks either A or B as the issuing certificate and copies the SubjectName
>> and SubjectKeyIdentifier from that certificate to the IssuerName and AKI of
>> the subject certificate respectively.
>
> B.SKI (but not both). Does the fact that C.AKI.keyId cannot be equal to both
> contradict the MUST? If not, what's the purpose of this change?

Should this be:

    (A.subjectName == B.subjectName) && (A.sn == B.sn)

But I'd like to see a position paper on the subject of certificate
equality for circumstances such as these.

Jeff

---

From: Michael StJohns <[email-masked]>
Date: Mon, 06 Apr 2015 16:07:56 -0400

At 03:29 PM 4/6/2015, Erwann Abalea wrote:

>2015-04-06 20:13 GMT+02:00 Michael StJohns <<mailto:[email-masked]>[email-masked]>:
>I don't think you're thinking this through.Â Â  You have two issuer certificates A and B.Â  They have differentÂ  SubjectKeyIdentifier extensionsÂ  A.SKI and B.SKI.Â Â Â  The issuer, when it issues the subject certificate S picks either A or B as the issuing certificate and copies the SubjectName and SubjectKeyIdentifier from that certificate to the IssuerName and AKI of the subject certificate respectively.
>
>
>Ok for your 2 issuer certificates A and B for the same CA. So A.subjectName == B.subjectName. Same public key in the example, but A.SKI != B.SKI (for whatever reason). If this CA issues a certificate C, and the paragraph is changed as described, then C.AKI.keyId will be either equal to A.SKI or B.SKI (but not both). Does the fact that C.AKI.keyId cannot be equal to both contradict the MUST? If not, what's the purpose of this change?

I'm beginning to think you're trolling.  Just in case you're not.

The the issuer first selects the specific issuer certificate and THEN creates the subject certificate.  The MUST is with respect to that specific issuer certificate.  The subject certificate chains through that issuer certificate.   If you have a - insane case - where you have two identical issuer certificates except for the issuer's SKI, then there is no difference in certificate acceptance.  The actual worst case is where you have two issuer certificates with identical public keys, two identical SKI's, two identical SubjectNames but differing active extensions which could cause you to come to different conclusions with respect to validation (e.g. which policies are active, which subordinate names are permitted) depending on which one you find.

>If the validator follows your logic (consider only certificates with the correct SKI in addition to the subjectName), then certificate B will never be considered. If B links to a trust anchor while A doesn't (from the validator point of view), validation fails.

Yup - and your point is?    AFAICT this is a good thing.  If the owner of the key pair for A/B wanted C to chain through B, then they should have set the AKI to point to B's SKI.

In any event, this can happen even if both SKIs are identical.  That's why doing it this way is NOT RECOMMENDED.  If you do it the way you're suggesting, expect to go out of business as a CA shortly.

>Â 
>It sometimes work (and sometimes fail) if the validator uses the AKI, it will always work if the validator doesn't really care about the AKI.
>
>So if the AKI doesn't provide super useful information for the validator that MUST be checked, I don't see the point of being strict on what CAs set it to.

See Steve's note and my first note. Basically the AKI/SKI pairing allows you to easily select appropriate certificates from the database for path building.  The AKI/SKI pairing doesn't actually play in the path validation process though.  Without this pairing, you have to try ALL valid certificates with matching SubjectName/IssuerName pairings (discarding those whose public key couldn't possibly form your signature) and hoping for the best.  There are path building algorithms that will (mostly wrongly) do this.

Not setting it makes path building clumsy and path validation more expensive.  Setting it incorrectly can prevent the selection of the certificate for potential paths.   

To be fair, I wish the pairing was enforced as part of the path validation simply to deal with some esoteric corner case.  But for a reasonably competent CA and a reasonably competent root operator, this is mostly not going to be an issue.

There are a *lot* of ways to screw up certificate issuing.  Congrats on rediscovering at least two.

Mike

>The same reasoning can be used with AKI.{authorityCertIssuer,authorityCertSerialNumber}, which will obviously be different whatever the situation.
>
>-- 
>Erwann.

---

From: Michael StJohns <[email-masked]>
Date: Mon, 06 Apr 2015 16:15:33 -0400

>    (A.subjectName == B.subjectName) && (A.sn == B.sn)

The serial number has to be unique per issuer so this isn't actually a problem unless A.issuerName == B.issuerName as well.

>equality for circumstances such as these.

See RFC3647  sections 4.4.6 through 4.4.8 for some ideas about name/key/keyid/issuer/extension relationships and what a CA should do in various cases.  It's not comprehensive, but this is where a lot of CAs start.

Mike

>Jeff
>
>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 6 Apr 2015 20:17:10 +0000

> When validating the subject certificate, the acceptor grabs the AKI from the 
> subject certificate along with the Issuer Name and goes looking for a matching 
> CA certificate eventually finding the certificate that the ISSUER selected.

Since this is all a *path construction* discussion and explicitly not a path validation problem, I thought I'd point out that practically speaking it doesn't matter.  There is no obligation on the part of a Verifier to hunt for a valid path because, well, this can take forever (proof is left as an exercise for the reader :).  In real implementations the Supplicant provides a candidate chain, and the Verifier simply checks it.  I.e., there is no construction step [1].

To do otherwise invites a resource exhaustion attack.  Just so you know.  :) 

-- T

[1] I've worked on edge cases where communication of the chain is unacceptable overhead, but in such cases the community is invariably closed and the chain can be pre-positioned (or chains can be omitted entirely and the system moved to key continuity management--now known as pinning).

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 6 Apr 2015 16:27:15 -0400

On Mon, Apr 6, 2015 at 4:17 PM, Miller, Timothy J. <[email-masked]> wrote:
> Since this is all a *path construction* discussion and explicitly not a path validation problem, I thought I'd point out that practically speaking it doesn't matter.

Well, if you are using the standard and path construction to tease out
the validations, then it could be a real problem in practice.

(And I have not looked at RFC 6125 to see what it has to say about it).

> There is no obligation on the part of a Verifier to hunt for a valid path because, well, this can take forever

If you don't mind me asking, what is that problem called? It feels
like it should be called the "Which Certificate" problem in spirit of
the "Which Directory" problem. Or is this an instance of the "Which
Directory" problem (my gut tells me probably not).

Jeff

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 7 Apr 2015 10:35:30 +0200

2015-04-06 22:07 GMT+02:00 Michael StJohns <[email-masked]>:

> 2015-04-06 20:13 GMT+02:00 Michael StJohns <[email-masked] >:
> I don't think you're thinking this through.Â Â  You have two issuer
> certificates A and B.Â  They have differentÂ  SubjectKeyIdentifier
> extensionsÂ  A.SKI and B.SKI.Â Â Â  The issuer, when it issues the subject
> > Ok for your 2 issuer certificates A and B for the same CA. So
> A.subjectName == B.subjectName. Same public key in the example, but A.SKI
> != B.SKI (for whatever reason). If this CA issues a certificate C, and the
> paragraph is changed as described, then C.AKI.keyId will be either equal to
> A.SKI or B.SKI (but not both). Does the fact that C.AKI.keyId cannot be
> equal to both contradict the MUST? If not, what's the purpose of this
> change?
>
> The the issuer first selects the specific issuer certificate and THEN
> creates the subject certificate.  The MUST is with respect to that specific
> issuer certificate.  The subject certificate chains through that issuer
> certificate.   If you have a - insane case -
>

The subject certificate chains through every possible certificates of this
issuer, not the one arbitrarily chosen by the issuer.

----- [1]

> where you have two identical issuer certificates except for the issuer's
> SKI, then there is no difference in certificate acceptance.
>
-----

>   The actual worst case is where you have two issuer certificates with
> identical public keys, two identical SKI's, two identical SubjectNames but
> differing active extensions which could cause you to come to different
> conclusions with respect to validation (e.g. which policies are active,
> which subordinate names are permitted) depending on which one you find.
>
>
> Yup - and your point is?    AFAICT this is a good thing.  If the owner of
> the key pair for A/B wanted C to chain through B, then they should have set
> the AKI to point to B's SKI.
>

Now, you're trolling.
The chain A->C is as valid as the chain B->C (appart from other things).
The CA identified by B,C can potentially decide that one of the chains is
invalid, but NOT by setting C.AKI to a particular value, precisely *because
validation doesn't take this into account*. You just admitted it in [1].

Cross-certification exists in practice. Some RP can trust a root RA,
another can trust root RB, a CA wants to be recognized widely so it asks to
be cross-certified by RA and RB (to get certificates A and B). Both RA and
RB have complete freedom to choose what will be set in {A,B}.SKI (see
4.2.1.2, there's no MUST here, RA and RB are not required to cooperate,
they can be completely unrelated entities) as in any other extensions.

> See Steve's note and my first note. Basically the AKI/SKI pairing allows
> you to easily select appropriate certificates from the database for path
> building.  The AKI/SKI pairing doesn't actually play in the path validation
> process though.  Without this pairing, you have to try ALL valid
> certificates with matching SubjectName/IssuerName pairings (discarding
> those whose public key couldn't possibly form your signature) and hoping
> for the best.  There are path building algorithms that will (mostly
> wrongly) do this.
>

Why "wrongly"? Why avoiding an incomplete or wrong helper is a bad choice,
if it finds a valid chain?

Not setting it makes path building clumsy and path validation more
> expensive.  Setting it incorrectly can prevent the selection of the
> certificate for potential paths.
>

> To be fair, I wish the pairing was enforced as part of the path validation
> simply to deal with some esoteric corner case.  But for a reasonably
> competent CA and a reasonably competent root operator, this is mostly not
> going to be an issue.
>

Yet your proposed change is on certificate issuance and not on certificate
validation, and the proposed change has strictly zero effect in the
validation result of a certificate chain, and no security benefit.

SKI/AKI is only a helper, enforcing strict content on a helper is useless
if the RP has complete freedom to ignore them.
And honestly, checking "ALL valid certificates with matching
subjectName/issuerName pairings" isn't that expensive. Writing code that
builds chains with matching AKI/SKI and dealing with corner cases is much
more complicated.

-- 
Erwann.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 7 Apr 2015 13:19:11 +0000

>the validations, then it could be a real problem in practice.

First, as others have pointed out, there is no standard for path construction.  There is only a standard on path validation. Real world experience is that this isn't a problem--it's in the Supplicant's best interest to provide the Validator with everything necessary to build a valid path for the Subscriber, so they do so and everyone is happy.

If a Supplicant has multiple possible paths, then the protocol should be providing hints--this is how (most) implementations of TLS use the Certificate message--it usually includes a list of trust anchors the web server trusts for authentication [1].  If that path doesn't get accepted, the Supplicant can retry with a different path (though most implementations don't actually do this).

>(And I have not looked at RFC 6125 to see what it has to say about it).

See below.

>Directory" problem (my gut tells me probably not).

Call it whatever you like, but most people refer to this as path construction.  The generalized problem is path finding through a graph--consult your Comp Sci or Graph Theory textbooks for an extended treatment.  In a large pool of certs (absent all other context, which as I hope you see above is an artificial condition that doesn't appear in real events) finding whether or not a path exists between two arbitrary vertices will have varying levels of difficulty depening only how the different PKIs are interrelated.  

By having the Supplicant provide the cert pool, the Verifier is assured that there *is* a path, and the Verifier need only check it and then see whether or not the anchor is locally trusted.

Note that in TLS this goes both ways.  The server's Certificate message should provide all the certs necessary to build a path from the server cert to some anchor [2].  Which anchor is configured per server instance.  The client only has to decide whether the path is valid, the anchor is trusted, *and* if the anchor is correct for the server.  If RFC 6125 has anything to say it's probably about that last bit.

Likewise the client's Certificate message should have all the certs necessary to build a path to some anchor.  The server only has to decide whether the path is valid and the anchor is trusted.  Theoretically there's a similar problem about binding anchors to namespaces, but for validating user credentials this is usually not a problem--the server can very easily restrict the list of anchors, and the Subscriber enrollment process takes care of the rest.

-- T
[1] IIS does things differently, FWIW--it sends a list of trust anchors that are in the Trusted Root store *and* are marked with the "authentication" attribute, regardless of whether  or not the server would actually accept a Subscriber from that PKI.  The server may have a CTL configured, but this is separate.

[2] Note that this is not always true, depending on server, and I have seen it break (usually it's a missing subordinate CA certificate).  Clients may attempt to fill gaps by fetching from network services, but this is a failure-prone process.  The fix in these cases is usually to either fix the server or distribute the missing certs to the clients via some other mechanism.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 07 Apr 2015 10:46:18 -0400

Tim,

> Since this is all a *path construction* discussion and explicitly not a path validation problem, I thought I'd point out that practically speaking it doesn't matter.  There is no obligation on the…
Not _all_ real situations work this way. The RPKI, for example, does not.

Remember that X.509 assumed the existence of "The Directory" aka X.500, 
so searching
for certs to discover a cert path was reasonable in that context.

We don't have "The Directory" but we also don't always know what set of 
trust anchors
are acceptable to an RP. Thus some hybrid mechanism is appropriate to 
enable path
discovery/construction. In different contexts different sets of 
assumptions may be
appropriate to help deal with this dilemma.

Steve

---

From: Yuting Chen <[email-masked]>
Date: Tue, 7 Apr 2015 09:53:52 -0700

My concern is that if we do not have standard,
path construction is not very different from
path validation. Programmers would like to
follow RFC5280 to construct certificate paths
(it seems I am wrong).

Sorry for causing a lot of controversy. The
responsibility of a tester is to design as many
corner cases as possible. I made some test
certificates by simply appending some extensions
(including akid,skid) to one certificate, and
found that they can (or cannot) be verified against
another certificate. I submitted them to openssl/gnutls
forum, and the engineers also used RFC5280
to explain that they should or should not be verified.

OK, should we make it more clear in RFC5280?

---

From: Stephen Kent <[email-masked]>
Date: Tue, 07 Apr 2015 16:45:27 -0400

> follow RFC5280 to construct certificate paths
I am afraid you are wrong, in this case. 5280 does not
specify path construction (perhaps, more properly, path discovery).
It defines the path validation procedure and imposes requirements on 
cert issuance.

We have a separate (Informational) RFC that discusses ways to effect
path discovery: RFC 4158 (http://www.rfc-editor.org/rfc/rfc4158.txt)
> to explain that they should or should not be verified.
I note that you said "... should or should not be verified." That statement
is about path validation, not path discovery/construction.
> OK, should we make it more clear in RFC5280?
make what clear? that the RFC imposes requirements on cert generation
and validation but does not define a path discovery standard?

Steve

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 7 Apr 2015 16:52:22 -0400

Hi Steve,

> path discovery: RFC 4158 (http://www.rfc-editor.org/rfc/rfc4158.txt)

Related: Should RFC 6125 mention the existence of RFC 4158 or direct
folks to it for path discovery/validation?

I was aware of RFC 6125, and I use it for guidance. But I was not
aware of RFC 4158. And RFC 6125 does not mention AKIs, SKIs, or RFC
4158.

Adding references to RFC 4158 might be useful to others who turn to
RFC 6125 for guidance.

Jeff

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 7 Apr 2015 17:22:21 -0400

Hi Steve,

> path discovery: RFC 4158 (http://www.rfc-editor.org/rfc/rfc4158.txt)

My apologies for another related question. Can/should RFC 4158 be used
to determine certificate "equivalence"? I've been looking for a
canonical reference for the subject matter from the IETF.

Also, RFC 4158 refers to some antiquated RFCs that have been
obsoleted. For example:

    Many other documents (such as [RFC3280]) cover
    certification path ...

---

From: Yuting Chen <[email-masked]>
Date: Tue, 7 Apr 2015 14:59:58 -0700

Read RFC 4158 (sec. 3.5.12) and can understand KIDs now.
Sounds like that they are redundant in most cases.

"NOTE:  Although required to be present by [RFC3280], it is extremely
   important that KIDs be used only as sorting criteria or as hints
   during certification path building.  KIDs are not required to match
   during certification path validation and cannot be used to eliminate
   certificates. "

Yuting

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 7 Apr 2015 18:52:49 -0400

> canonical reference for the subject matter from the IETF.

So it appear to be no.

Sorting is discussed (section 3.2). To sort, I need the C++ equivalent
to operator< and operator==. But those details are not discussed.

So it appears the document only relies on name chaining (meaning the
subject name of the issuer certificate matches the issuer name of the
issued certificate), and not other methods of equivalence like like
public keys, {DN, public key} pairs, {DN, SN} pairs or {AKI, SKI}
pairs.

Jeff

---

From: Bruce Stephens <[email-masked]>
Date: Wed, 08 Apr 2015 11:49:17 +0100

> On Tue, Apr 7, 2015 at 5:22 PM, Jeffrey Walton <[email-masked]> wrote:

[...]

>> canonical reference for the subject matter from the IETF.

I suspect equivalence is context specific.

> to operator< and operator==. But those details are not discussed.

There are possible properties to use for ordering in 3.5. The ordering
is context dependent and heuristic.

> public keys, {DN, public key} pairs, {DN, SN} pairs or {AKI, SKI}

Several subsections of 3.5 give ways to say that certificates definitely
aren't candidates for continuing a path. The goal is to construct a
valid path (if one exists) as specified by RFC 3280 (now 5280), so the
algorithm can't (in general) use AKI and SKI to exclude paths. A
specific implementation might choose to exclude paths where AKI and SKI
do not match (OpenSSL's path verifier does that, IIUC).

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 8 Apr 2015 11:53:38 +0000

"Equivalence?"  

What are you trying to achieve?

-- T

-----Original Message-----
From: pkix [mailto:[email-masked]] On Behalf Of Jeffrey Walton
Sent: Tuesday, April 07, 2015 5:22 PM
To: Stephen Kent
Cc: PKIX
Subject: Re: [pkix] Suggested replacement text for RFC5280, section 4.2.1.1

Hi Steve,

> path discovery: RFC 4158 (http://www.rfc-editor.org/rfc/rfc4158.txt)

My apologies for another related question. Can/should RFC 4158 be used to determine certificate "equivalence"? I've been looking for a canonical reference for the subject matter from the IETF.

Also, RFC 4158 refers to some antiquated RFCs that have been obsoleted. For example:

---

From: Stephen Kent <[email-masked]>
Date: Wed, 08 Apr 2015 09:48:52 -0400

Jeff,

> folks to it for path discovery/validation?
First, 6125 is a TLS WG doc, not a PKIX doc. It was written to deal with
the messy situation in the Web PKI environment (the browser context) and
should not be viewed as generally applicable to PKI. Also, in the browser
context pat building is generally easier, so the very general discussion
in 4158 is overkill.

> aware of RFC 4158. And RFC 6125 does not mention AKIs, SKIs, or RFC
true, and probably OK for the reasons I cited above.
> Adding references to RFC 4158 might be useful to others who turn to
That's an issue for the TLS WG to consider, but I doubt that they will
see a need to do so.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 08 Apr 2015 09:49:57 -0400

Jeff,

> canonical reference for the subject matter from the IETF.
"equivalence" is not a concept that comes to mind in the PKI arena.
>      Many other documents (such as [RFC3280]) cover
As I noted, a decision to update 4158 is not a PKIX matter.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 08 Apr 2015 09:52:26 -0400

Jeff,

>> canonical reference for the subject matter from the IETF.
yep.
> public keys, {DN, public key} pairs, {DN, SN} pairs or {AKI, SKI}
Name chaining is the primary way to discover a cert path. AKI/SKI matching
is used to help speed up this process in certain circumstances, but it
is not a substitute for name chaining.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Wed, 08 Apr 2015 15:57:25 +0100

On 08/04/15 14:52, Stephen Kent wrote:
<snip>
> is not a substitute for name chaining.

It's worth noting that Microsoft's implementation does the opposite.

Key Identifier matching is compulsory...
   "Note: If a certificate’s AKI extension contains a KeyID, CryptoAPI
    requires the issuer certificate to contain a matching SKI. This
    differs from RFC 3280 where SKI and AKI matching is optional." [1]

...and Name matching is only performed if Key Identifiers are not used!
   "Name Match: If no information exists in the AKI or if the AKI
    extension is not in the certificate, name matching will occur." [1]

[1] 
http://social.technet.microsoft.com/wiki/contents/articles/4954.windows-xp-certificate-status-and-revocation-checking.aspx

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Stephen Kent <[email-masked]>
Date: Wed, 08 Apr 2015 12:00:28 -0400

Yes, Rob, their implementation is non-conforming, as noted on PKIX years 
ago.

Steve