Subject: Re: [pkix] Possible new work item: additional methods for generating key identifiers

From: koichi sugimoto <[email-masked]>
Date: Thu, 8 Jul 2010 12:27:46 +0900

Hello Peter,

>Thanks for that.  Quoting "7.1  Path Discovery: Building the Chain":
>
> Acrobat matches a certificate based on the following criteria:
>
> * The Subject Key Identifier (SKI) in the found certificate matches the
>   Authority Key Identifier (AKI) in the child certificate
>
> * If the AKI is missing from the child's certificate, then the Subject
>       Distinguished Name in the found certificate matches the Issuer
>       Distinguished Name in the child certificate
>
>The RFC kinda waffles on the details, but isn't this more or less the opposite
>of how you're supposed to do it, with the sKID acting as a disambiguating
>backup to the DN for path construction (section 6.1.3 of RFC 5280)?
>
>Peter.

I think so but let me clarify the case when both SKI and AKI appear
and the SKI mismatches the child's AKI.
In this case, the path building may fail - I think this is correct
because SKI must be the same value to the corresponding AKI.

My understanding is as follows:

1) SKI-AKI maching must be used only for path construction, must not
be used for path validation.
2) If no path candidates found by SKI-AKI matching, DN maching must be
used for path construction.
     - these extension may not be interpleted because these are not critical
     - one of or both extensions may be absent

For another information, please see the Microsoft's:
http://technet.microsoft.com/ja-jp/library/bb457027%28en-us%29.aspx

Regards,
Koichi Sugimoto.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 8 Jul 2010 09:34:21 -0400

A
>...

not exactly. As Peter indicated, although 5280 does not define how to 
perform path construction, it does explain the intent behind use of 
AKI/SKI, and that is for disambiguation when one finds two or more CA 
certs, each of which contains the same subject name but which contain 
different public keys. So, no, there is not an assumption that one 
tries to build a path using SKI/AKI matching first.  Using SKI/AKI 
matching for path construction will work if the RP has access to all 
of the required certs (e.g., they are locally cached).  But, if this 
assumption does not hold, there is no reason to assume that, in 
general, one can locate an ancestor CA cert based on an AKI!

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 13 Jul 2010 00:18:15 +0200

The practical problem here is that the described SKI/AKI logic fails to
discover and validate a path if there is an SKI/AKI mismatch.

This is a problem since some certificate issuing code, such as Peter's
cryptlib, does not natively allow you to set an arbitrary SKI value when
cross certifying another CA, with may lead to mismatching AKI/SKI when
validating certificates form the cross certified CA.

/Stefan

On 10-07-08 3:34 PM, "Stephen Kent" <[email-masked]> wrote:

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

---

From: koichi sugimoto <[email-masked]>
Date: Tue, 13 Jul 2010 11:17:12 +0900

Thanks.
I understand the point.

/Sugi