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

From: [email-masked]
Date: Fri, 22 Aug 2003 14:59:08 +0000

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: "Peter Hesse" <[email-masked]>
Date: Fri, 22 Aug 2003 11:35:00 -0400

Chris,

As was already mentioned on the list, there is no requirement that
SKID/AKID match.  While it would be nice if it can be counted on, I
think that it just flat out can't; so you can't create your path
development routine to require this to be in place.

Besides this pertinent fact, there is another I'd like you to consider.
SKID/AKID are only available once the certificate has been downloaded
and parsed.  If you are attempting to build a certification path based
upon a target certificate and a pointer to an LDAP directory, relying on
SKID/AKID only (and not name/public key chaining) could require the
download of many insignificant certificates.  

I suspect chaining of distinguished names will be the most important
part of path building for quite some time.  Once you retrieve
certificates for the appropriate entity, then it makes perfect sense to
check the certificates for which the SKID/AKID match appropriately first
when the path is being built; it is my assertion that you can't just
stop there.

--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 [email-masked]
Sent: Friday, August 22, 2003 10:59 AM
To: [email-masked]
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

---

From: Stephen Kent <[email-masked]>
Date: Fri, 22 Aug 2003 13:15:31 -0400

Chris,

I cannot interpret what you said, relative to what you indicated was 
the goal of this message. Are you saying that with a simple 
convention on how SKIDs are managed in CA certs, that one can use 
AKIDs to locate CA certs? if so, it is not at all clear from your 
message.

Steve