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

From: koichi sugimoto <[email-masked]>
Date: Wed, 7 Jul 2010 15:34:48 +0900

"Security Administration Guide for Acrobat 9" specifies the building logic.

http://learn.adobe.com/wiki/download/attachments/52658564/acrobat_reader_security_9x.pdf?version=1
http://www.adobe.com/devnet/acrobat/

Please refer the page 144.

>I think the question is best asked to Adobe.
>The only thing I have really tested is that a chain with a mismatching
>SKI/AKI is not accepted. I don't know what happens if SKI/AKI is absent so I
>have never meant to claim that SKI must be present.
>
>/Stefan

Regards,
Koichi Sugimoto.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 08 Jul 2010 02:04:47 +1200

>Please refer the page 144.

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.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 7 Jul 2010 13:31:03 -0400

>backup to the DN for path construction (section 6.1.3 of RFC 5280)?

Absolutely right, Peter.

Steve

---

From: Tom Gindin <[email-masked]>
Date: Wed, 7 Jul 2010 20:49:24 -0400

Peter:

        While I don't think that RFC 5280 forbids checking the KID before 
the DN's, it does forbid not checking the DN's at all.  Section 6.1 
condition (a) says as explicitly as it can that the subject of each 
certificate in the path must be the issuer of the next, and in the sample 
algorithm 6.1.3-a4 checks the certificate's issuer name against 
working_issuer_name, and 6.1.4-c sets working_issuer_name from the last 
one's subject.  IMHO if somebody wants to do a lookup on KID before 
matching DN's they're welcome to, but they have to match the DN's 
sometime.  Saying "match the DN's only if the KID's are absent" does not 
follow the standard, which has included the DN match since RFC 2459.

                Tom Gindin
P.S. - The above opinions are mine personally, and not necessarily those 
of my employer.

From:
Peter Gutmann <[email-masked]>
To:
[email-masked], [email-masked]
Date:
07/07/2010 10:06 AM
Subject:
Re: [pkix] Possible new work item: additional methods for       generating 
key identifiers
Sent by:
[email-masked]

  * 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.
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix