RE: Basic Cert-2-Directory mapping question

["Slone, Skip" <[e-mail]>]

Thanks to all who have responded so quickly! Rather than try to maintain
multiple, divergent conversations on one topic, I'll provide a general
response to Sharon's note below, in hopes that this response clarifies what
I am (and what I'm not) trying to acheive.
 
Generally speaking, the concept I've been looking at provides a level of
abstraction that can be logically layered on top of the PKI Repository
Locator Service.  (In previous posts, I sloppily used the term "directory
service" or "LDAP" when the more general term "repository" would have been
better.  Mea culpa.) The pkixrep I-D says what to do to find a PKI
repository serving the domain "example.com."  What it stops short of saying
is how one determines that "example.com" is the domain to query in the first
place.  Since civil-to-DNS name mapping typically fails to yield to a
character string transliteration algorithm (e.g., "o=Joe's Bar and Grill"
does not readily translate to are-you-hungry.com), this leaves us with a
choice of either registering the translations or complaining that it can't
be done. Rather than complain that it can't be done, I've been exploring
what it would take to support a registration process.  And, since I'm not
holding my breath waiting for X.500-based registration, the only globally
recognized registration service I'm aware of is DNS.  Thus, my thoughts have
led me in that direction...
 
What I'm proposing is the development of a new DNS RR type that allows the
registration of arbitrary attribute value assertions (such as "o=Something"
or "ou=Something Else"). These new RRs (let's call them AVA RRs) would
resolve to a domain name that could subsequently be used to construct the
right hand portion of a PKIXREP query (or some other SRV-seeking query).  A
remaining critical piece is the specification of c=XX as equivalent to a
corresponding ccTLD. As an example, when resolving a DN ending in o=Entrust,
c=CA, one would first query .ca for an AVA record matching "o=Entrust", and
would get a response such as "entrust.com" which would then be used to
generate a query along the line of _PKIXREP._LDAP.entrust.com.  Similarly,
by registering "o=Lockheed Martin"-->lmco.com under .us, one could query .us
for the AVA record "o=Lockheed Martin" to generate a query for me.
 
With respect to the multiple-repository question, this process could still
lead someone to a company-operated repository, which then has the
appropriate knowledge references to the TTP-based repository.  The trick is
getting from "I have no clue about where to go" to "I have a place to
start." Granted, if you have an email address, you have a place to start.  I
guess the question is -- is that sufficient?
 
To address other questions, no, this doesn't solve all the problems (most
notably the problems with TTP certs issued to individuals), but when it
comes to mapping things like GTE to verizon.com, it is as flexible (or
inflexible, as the case may be) as the supporting registration processes.
 
Hope this helps...
 
 -- Skip

 -----Original Message-----
From: Sharon Boeyen [mailto:[e-mail]]
Sent: Wednesday, January 10, 2001 4:13 PM
To: 'Slone, Skip'; 'David P. Kemp'; [e-mail]
Subject: RE: Basic Cert-2-Directory mapping question



I'm not convinced that name mapping would actually satisfy the requirement
because 
the issuer and the subject of a certificate may have DNs that are not 
linked in the manner you are expecting (e.g. a service provider (lets call 
it c=us; o=certpump) might issue certificates to users who have DNs such 
as cn=Skip Slone, o=Lockheed Martin, c=US. It might very well be the public 
provider that maintains the repository for the certificates it issues and 
the fact that Lockheed Martin also maintains a directory with entries for 
those users doesn't necessarily mean you'll get to the right place. 

That is one of the reasons the PKI repository locator service draft is
different 
from the SRV draft the LDAP group defined. Specific to PKI, a domain places 
SRV records for the different protocols that can be used to reach their PKI 
repository. At present it can provide LDAP records, and others but is
queried on domain name 
and perhaps what would help would be a way to get you to a domain domain
name so 
that you could then query for the SRV records for that domain's PKI
repository? 

One more point, that I think Steve already mentioned is that there are hints
available 
already in the SIA and AIA. If we take this back to a "what are we 
trying to achieve" level it would sure help me. 

If you are verifying a signature, you already have the EE cert and are
either 
retrieving revocation information or an intermediate cert. These extensions
should be 
useful for that. If you need to encrypt for another user (e.g. an email),
that is where 
the PKI repository locator issue seems to be the biggest. For email, you
have the email 
address so you know the domain name and can use PKI repository locator
service to obtain 
SRV records that give you the necessary information to connect to the
repository that holds 
the PKI data for that domain. 

If you can outline the type of environment where none of the above provides
what is needed 
that will at least help focus the discussion better. I've skimmed very
quickly through the 
messages in this thread and apologize in advance if this is already stated
but I missed it. 
I do tend to pay more attention to the shorter messages than the longer ones
:-( 

Thanks 
Sharon 


  

> -----Original Message----- 
> From: Slone, Skip [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Wednesday, January 10, 2001 3:27 PM 
> To: 'David P. Kemp'; [e-mail] 
> Subject: RE: Basic Cert-2-Directory mapping question 
> 
> 
> David, 
> 
> Only somewhat tongue-in-cheek, I'll say the answer to your 
> question is "only 
> if you want the right answer" ;-) 
> 
> As I see it, we're dealing with the fact that we have extant 
> DNs all over 
> the map with no semblance of a registration authority. 
> Consequently, we have 
> no reasonable way of getting from an arbitrary DN to a 
> directory service. 
> The closest thing to a global registration authority that 
> exists is DNS 
> (including, of course, its whole supporting cast). As such, 
> it made sense 
> for the Internet community to tackle those names found within 
> the current 
> DNS struture.  What I would like to propose is that we build 
> on that success 
> and extend the authority of DNS into other parts of the DN 
> namespace.  To do 
> so requires the definition of some mappings (namely c=XX to 
> <ccTLD>) and the 
> creation of a way (i.e., a new DNS RR type) to use DNS to 
> register names 
> traditionally associated with X.500/LDAP. 
> 
> By way of example, what I'm talking about is the ability to 
> take a DN of the 
> form "cn=Skip Slone, o=Lockheed Martin, c=US" and determine 
> that the LDAP 
> server to check is found at (for example) ldap1.external.lmco.com. 
> 
> That said, such registration in DNS, combined with a 
> deterministic algorithm 
> will return a result of the following form: 
>  a) the DN maps to an LDAP server found at foo.com, OR 
>  b) the DN does not map to a registered LDAP server 
> 
> If you get answer "a" you then send an LDAP query to 
> foo.com:389 to find the 
> entry itself. 
> 
> To answer your question properly, I would contend that if 
> "o=Foo, Inc." is 
> not registered under these rules, you would get answer "b".  
> Even though you 
> don't find the entry, you still get a deterministic response. 
> 
>  -- Skip 
> 
> -----Original Message----- 
> From: David P. Kemp [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Wednesday, January 10, 2001 2:51 PM 
> To: [e-mail] 
> Subject: RE: Basic Cert-2-Directory mapping question 
> 
> 
> Skip, 
> 
> Doesn't the existence of a deterministic algorithm depend on users 
> of civil (Country-based) names following the rules? 
> 
> As Michael Ströder pointed out, everyone wants a short name in a 
> flat namespace.  But not every Joe's Bar & Grill in the US can 
> have certificates with the name "C=US, O=Joe's Bar & Grill".  If 
> TTP CAs are willing to issue such certificates without evidence 
> that the name has been registered with the US national authority, 
> what algorithm can possibly find all the directory entries for 
> that DN? 
> 
> Dave 
> 
> 
> 
> 
> > From: "Slone, Skip" <[e-mail]> 
> > Subject: RE: Basic Cert-2-Directory mapping question 
> > To: [e-mail] 
> > 
> > As the traffic on this topic points out, there are a lot of 
> people who see 
> > this as an issue.  Whether we can agree on exactly what the 
> issue is and 
> how 
> > to proceed may be another matter ... :-) 
> > 
> > As have many others on this list, I've been giving this 
> issue some thought 
> > lately, focusing on the problems as seen from the 
> perspective of a large 
> > user like my company. Although I've come to a different set 
> of conclusions 
> > from those discussed so far in this thread, my energy has 
> been focused on 
> > the same problem that Bob Jueneman pointed out: knowing the 
> location of a 
> > directory service provider that is supposed to contain the DN. 
> > 
> > My basic premise is that if we can come up with a 
> deterministic algorithm 
> > that takes an arbitrary (but reasonably well structured) DN 
> and resolves 
> it 
> > to a set of FQDNs where one can find LDAP services, we can 
> deterministically 
> > get from the DN to the associated directory entry.  As 
> Steve Kent pointed 
> > out, there exists a body of work to do this in the limited 
> case of DNs 
> based 
> > on (DNS) domainComponent naming.  My thoughts are along 
> that line, but 
> > expand to cover the so-called "civil" naming constructs in 
> DNs, such as 
> > country, organization, and so on.  I think that's the goal Anders 
> originally 
> > stated, starting this whole thread. 
> > 
> > If people are interested, I'll summarize the algorithm I've 
> come up with 
> so 
> > far and distribute it for review.  If need be, we could 
> consider whether 
> > this is worthy of an I-D, or a BOF at Minneapolis, or whatever... 
> > 
> > Regards, 
> > 
> >  -- Skip Slone 
> >     Lockheed Martin 
>