RE: Basic Cert-2-Directory mapping question

["Slone, Skip" <skip.slone@xxxxxxxx>]

Title: RE: Basic Cert-2-Directory mapping question

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:sharon.boeyen@xxxxxxxxxxx]
Sent: Wednesday, January 10, 2001 4:13 PM
To: 'Slone, Skip'; 'David P. Kemp'; ietf-pkix@xxxxxxx
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:skip.slone@xxxxxxxx]
> Sent: Wednesday, January 10, 2001 3:27 PM
> To: 'David P. Kemp'; ietf-pkix@xxxxxxx
> 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:dpkemp@xxxxxxxxxxxxxxxxxxxxxxx]
> Sent: Wednesday, January 10, 2001 2:51 PM
> To: ietf-pkix@xxxxxxx
> 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" <skip.slone@xxxxxxxx>
> > Subject: RE: Basic Cert-2-Directory mapping question
> > To: ietf-pkix@xxxxxxx
> >
> > 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
>