Re: Qualified Certificates draft - Country name

["Zahid Ahmed" <zahmed@xxxxxxxxxxxxxx>]

I agree that is should be retrievable via ID that is not a name.
But I don't understand what this is ID to fetch the cert 
should be? and how we will include this in exisiting
X.509 certificates? what extensions will work with
exisiting X.509 certs?

-----Original Message----- 
From: David P. Kemp <dpkemp@missi.ncsc.mil>
To: ietf-pkix@imc.org <ietf-pkix@imc.org>
Date: Friday, March 05, 1999 1:29 PM
Subject: Re: Qualified Certificates draft - Country name


>> From: "Bob Jueneman" <BJUENEMAN@novell.com>
>> 
>> David,
>> 
>> Flat is not necessarily bad, although the performance of 
>> typical directory implementations may be a concern.
>> 
>> But hashing the certificate or public key a la SPKI is 
>> in my opinion NOT the way to go, for reasons that were 
>> argued extensively on that list (even if Carl Ellison 
>> remains unconvinced).
>> 
>> I wouldn't mind such a technique as an alias, if aliases 
>> weren't such a headache, but I don't think it would be 
>> acceptable as the primary DN, because people want to be
>> able to look up lots of other things about someone than
>> their certificate, and they want to be able to do so for a 
>> very long period of time.
>
>
>I see two different scenarios for looking up certificates:
>
>1) I receive an S/MIME message (or an IPSEC/IKE connection request)
>containing only an EE cert or (preferably) no cert at all, just a
>certID.  I look for the issuer cert path (and perhaps also the EE cert)
>in my local ram cache and my local disk cache. If they aren't cached, I
>do a repository fetch, which chains as required from my company's or
>ISP's directory cache on up to the Internet Root.  For this purpose, a
>certID should be an "address" (i.e. something meaningless and
>politically non-controversial like a hash) with the sole purpose of
>enabling the fetching to occur.
>
>2) I have a "name" of someone I want to communicate with and don't
>already have any information about him (such as a certID, DN, or cert)
>in my address book.  For that, I need a white pages directory.
>
>The first "repository" scenario is the one I'm addressing.
>It is easy to solve, and the IETF should solve it by defining
>the protocols and standing up the infrastructure root, because
>it is purely a technical engineering exercise.
>
>The second "directory" scenario is too hard.  People were
>arguing about directories and naming schemes before I was born
>and will be doing so after I'm gone. More importantly, directories
>should IMHO be regarded as layered *on top of* repositories,
>providing metadata about the repository's contents, but not
>being necessesary for the repository to operate.  Just as if
>DNS fails I can make a TCP connection to a dotted-quad IP address,
>if "The Directory" fails or is never established or information owners
>filter what it is allowed to reveal, I should still be able to
>fetch a cert by ID.
>
>I'm not signing up to the SPKI philosophy that the cert itself
>needs no name.  I'm just saying that the cert should be retrievable
>by an ID that is not necessarily a name.
>