Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID m atching)

From: "Terwilliger, Ann" <[email-masked]>
Date: Wed, 27 Aug 2003 11:25:39 -0700

I agree that trust path construction should be done with DNs rather than Key Ids.  However, on occasion we have needed to have more than one CA certificate with the exact same DN in our private hierarchy.  In that case, trust path construction requires that there be a way to ensure that we have the correct certificates to validate the signatures in the chain.  In general we either use the key ids (AKID/SKID) or (gasp) the other parameters included in the AKI extension--authorityCertIssuer and authorityCertSerialNumber.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 22, 2003 7:59 AM
Cc: [email-masked]
Subject: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID
matching)

Donning flameproof underpants for this one.

Trust path construction should be done with Distinguished Names
rather than Key IDs but I feel that, with a bit of work, Key IDs could
be made into a reliable mechanism and one that would permit
local trust path construction in the continuing absence of a public global
directory. It requires that the Key IDs can only be generated at the same
time as, and by the same device as, the keys themselves. RFC3280 states
that a Key ID need only be generated if there is not one already present
and merely copied when present. Employing this method would mask out
local differences in the interpretations of Key ID algorithms. If the value
of the keys can be relied on then so can the trust paths that can be built
using them.

Toast ?

Chris

---

From: Stephen Kent <[email-masked]>
Date: Wed, 27 Aug 2003 15:04:11 -0400

At 11:25 -0700 8/27/03, Terwilliger, Ann wrote:
>I agree that trust path construction should be done with DNs rather 
>than Key Ids.  However, on occasion we have needed to have more than 
>one CA certificate with the exact same DN in our private hierarchy. 
>In that case, trust path construction requires that there be a way 
>to ensure that we have the correct certificates to validate the 
>signatures in the chain.  In general we either use the key ids 
>(AKID/SKID) or (gasp) the other parameters included in the AKI 
>extension--authorityCertIssuer and authorityCertSerialNumber.

Ann,

Nothing wrong with that. The whole purpose of the key ID construct is 
to allow one to locate the right cert, in an efficient manner, among 
a set of certs for the same CA, at least with regard to cert chain 
processing. So the notion is that one locates the right CA using the 
issuer name, then uses the key ID to find the right cert for that CA 
(e.g., in a directory). But, given that you selected the right CA 
cert as described here, you can check the path using just comparing 
issuer & subject names.

Steve

---

From: "Peter Hesse" <[email-masked]>
Date: Wed, 27 Aug 2003 15:44:54 -0400

Ann,

You bring up an interesting point that I'd like to note to implementers.
authorityCertIssuer and authorityCertSerialNumber cannot be used as a
matching rule for path building in a mesh environment.  What I mean by
"matching rule" is that it can't be used to truly exclude certificates
from consideration when building a path.  (It can be used as a sorting
criteria, but may not be a good one for the reasons below)

Assume that a CA, called CA1, has two certificates; one from its domain
issuer and one from another issuer (in a different domain).  When it
builds and signs certificates, it has to choose a serial number to put
into the AKIDs of these certificates, from one of the two certificates
it has been issued.  Just because the serial number points to one of
CA1's issuers does not mean that paths that go through the other
issuer(s) are not valid.

It may be easier to see a picture, so let me refer you to slide 26 of
this briefing:
http://csrc.ncsl.nist.gov/pki/twg/y2000/presentations/twg-00-13.pdf

--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 Terwilliger, Ann
Sent: Wednesday, August 27, 2003 2:26 PM
To: [email-masked]
Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID
matching)

I agree that trust path construction should be done with DNs rather than
Key Ids.  However, on occasion we have needed to have more than one CA
certificate with the exact same DN in our private hierarchy.  In that
case, trust path construction requires that there be a way to ensure
that we have the correct certificates to validate the signatures in the
chain.  In general we either use the key ids (AKID/SKID) or (gasp) the
other parameters included in the AKI extension--authorityCertIssuer and
authorityCertSerialNumber.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 22, 2003 7:59 AM
Cc: [email-masked]
Subject: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID
matching)

Trust path construction should be done with Distinguished Names rather
than Key IDs but I feel that, with a bit of work, Key IDs could be made
into a reliable mechanism and one that would permit local trust path
construction in the continuing absence of a public global directory. It
requires that the Key IDs can only be generated at the same time as, and
by the same device as, the keys themselves. RFC3280 states that a Key ID
need only be generated if there is not one already present and merely
copied when present. Employing this method would mask out local
differences in the interpretations of Key ID algorithms. If the value of
the keys can be relied on then so can the trust paths that can be built
using them.

Toast ?

Chris