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

From: Sharon Boeyen <[email-masked]>
Date: Thu, 11 Jan 2001 08:28:28 -0500

The naming scheme (at least the higher levels of it) that is being
referenced is 
originally outlined in an informative annex to X.521 and its also in some
LDAP specs.

In some countries this type of naming is being more readily adopted than in
others. It 
is my VERY strong belief that trying to impose a single naming structure or
a single naming
hierarchy for all applications and all environments simply is a recipe for
disaster. The US
has historically been the absolute most difficult place to do this in the
past (reference 
the North American Directory Forum effort that Bob references). Regulatory
differences and 
differing business models and operating environments lead to different
naming structures. 

Borrowing from Marshall Rose's writing style, let me step on my soapbox for
a minute: 

Rather than try to name the world and every object in it, I believe a more
constructive approach 
is to accept the fact that different parts of the world and different
environments will have 
use a variety of nameforms and work within that context to make the best use
of the tools we have
at our disposal to find the information that is needed. We should not be
trying to solve the "global 
directory problem", we are the PKIX WG. We should ensure that appropriate
PKIX information can be located and 
retrieved. We are not the global naming police either and should not try to
impose the rules that 
anyone uses to name entities to which they issue certificates. Finding a
particular certificate is 
one problem and determining whether or not to 'trust' and make use of it is
another. Repository 
locator discussions should be restricted to the former.

Step off soapbox.

I do agree that 2377 and the PKIX repository locator document are a nice fit
and will satisfy a 
lot of the requirement for many environments. Those that use the
geographical, DNS or other style 
of DNs for the certs and directories can all be supported for applications
where the domain name is 
known. There may however be some additional support tools that can defined
to ease the 'knowledge' 
gathering process as Skip suggests. One that was raised earlier on the list
and for which we don't yet
have an answer is the provision of search base data for LDAP SRV records for
PKI repositories. If there
is a way to add additional information to DNS that will help resolve these
types of issues then I'm 
all for it. Another option that might be worth exploring is piggybacking
repository locator information 
in certificate management protocols (e.g. when one CA sends a cert request
to another CA it could provide
the details of how to access its repository in that cert requests - it is
relying parties from the issuer's
domain that will need that access). Again that won't satisfy every case,
since strict hierarchies that 
don't cross-certify with other domains wouldn't be covered). Skip, I'm not
necessarily objecting to the 
mapping you are proposing, but am trying to understand within the context of
PKI requirements and I'm not
quite there yet :-)

However, I really would like to see us work from a focused 'requirements'
standpoint rather 
than from the abstract level that a lot of this thread seems to have.

Sharon 

> -----Original Message-----
> From: Oscar Jacobsson [mailto:[email-masked]]
> Sent: Thursday, January 11, 2001 4:47 AM
> To: Slone, Skip
> Cc: [email-masked]
> Subject: Re: Basic Cert-2-Directory mapping question
> 
> 
> "Slone, Skip" wrote:
> > 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.
> 
> Pardon my ignorance of these matters, but where exactly is this civil
> naming scheme outlined?
> 
> IMHO the DNS-based naming scheme for in RFC 2377 has been around for a
> couple years now, and when combined with the repository locator
> documents I'd say it provides the information necessary for an RP to
> locate the relevant repository.
> 
> //oscar
>

---

From: Michael Ströder <[email-masked]>
Date: Thu, 11 Jan 2001 15:15:11 +0100

Sharon Boeyen wrote:
> 
> Finding a particular certificate is
> one problem and determining whether or not to 'trust' and make use
> of it is another.

Agreed.

> I do agree that 2377 and the PKIX repository locator document are
> a nice fit and will satisfy a lot of the requirement for many
> environments.
> [..]
> we don't yet have an answer is the provision of search base
> data for LDAP SRV records for PKI repositories.

??? You simply don't have to provide the LDAP search base in DNS.

1. If you are using RFC2377 naming and RFC2782 SRV records you're
looking up the server's DNS entry/IP address by already knowing the
dc-style search base. If you want to locate the entry of a given
e-mail address I would suggest that one searches all the sub-domains
up to top-level domain if you can find a SRV record. After that you
do a search for the e-mail address with this matching search base.

2. If you contact a given LDAPv3 server you can retrieve his search
base(s) by looking at the namingContexts attribute in the RootDSE.
(A similar non-standard work-around exists for UMich-derived LDAPv2
servers.)

Example for 1.:

a) Assuming you want to locate an entry for
[email-masked] for retrieving the certificate and your
client implementation is capable of searching the SRV RR in the DNS.

1. You search for SRV record _ldap._tcp.www.stroeder.com. -> no
result

2. You search for SRV record _ldap._tcp.stroeder.com. -> RR points
to LDAP server directory.adm.stroeder.com.

3. You're doing the LDAP search
ldap://directory.adm.stroeder.com/dc=stroeder,dc=com??sub?(mail=[email-masked])

b) If your client implementation is not capable of searching the SRV
RRs itself but is able to follow LDAPv3 referrals (search
continuations) it uses a service like described on
http://www.openldap.org/faq/data/cache/393.html and gets redirected
to the right server when doing a search like
ldap://root.openldap.org/dc=www,dc=stroeder,dc=com??sub?(mail=[email-masked]).

Now what's the problem? This can all be done without writing a new
draft or modifying an existing one. Just a matter of implementing
it...

Ciao, Michael.

---

From: Oscar Jacobsson <[email-masked]>
Date: Thu, 11 Jan 2001 16:44:32 +0100

Sharon Boeyen wrote:
> originally outlined in an informative annex to X.521 and its also in
> some LDAP specs.

Ah, all right. I was of the mistaken impression that it was a more or
less arbitrary naming scheme. Should have done my homework better.

> Rather than try to name the world and every object in it, ...

I took the liberty of trimming your soapbox address, because we are
using rather different scopes as the bases for our arguments, so I'd
much rather begin by explaining mine:

What I am proposing is "simply" to name every directory server on the
Internet (which I think the DNS does a very good job of) and
subsequently to name every entry in all these directories (which I think
can safely be left up to local administrators).

The PKIX charter states the intent of the group as "developing Internet
standards needed to support an X.509-based PKI". To develop a new
standard, or to endorse those already existing, for how certificates
(and thus the directory entries they may certify) should be named in
order to be usable (please see the discussion on requirements/use cases
below) over the Internet seems like a worthwhile endeavour.

And while on the subject of naming, didn't Rosseau in his day propose
the abolition of common nouns all together? It would be interesting to
know what naming schemes he proposed. :-)

> However, I really would like to see us work from a focused
> 'requirements' standpoint rather

Definitely. I feel cases could be argued far better formally, backed by
specific use cases and requirements.

Just as an OTOH example, these are a few use cases I would want an
Internet-based naming scheme to address:

1. Allowing RPs to discover the location of the directory in which the
subject entry resides, from which additional attributes could be
retreived as required.

2. Allowing RPs to discover the location of the directory in which the
issuer entry resides, from which additional attributes -- specifically
revocation lists -- could be retreived as required.

3. Allowing RPs to discover the location of the directory in which the
cRLDistributionPoint entry resides, from which revocation lists could be
retreived as required.

Regards,

//oscar

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 11 Jan 2001 16:55:33 +0100

> ldap://directory.adm.stroeder.com/dc=stroeder,dc=com??sub?(mail=[email-masked])

Another approach might be to retrieve the certificate from the DNS in
the first step, such as:

1. You search for CERT record webmaster.www.stroeder.com -> gets
certificate.

For an application that already implement "advanced" DNS features such
as SRV, this is a simpler and faster solution.

I believe uses of SRV records to locate LDAP servers to lookup a
certificate for a hostname or email address may be replaced with simply
looking up a CERT record.  I also believe exactly this kind of operation
is quite common (mail clients).  This solution is also less complicated.

Of course, CERT records would not help locating a certificate with a
"cn=foo, o=bar, c=US" kind of certificate, but then, SRV wouldn't
either.  In most of these cases you'll probably have the LDAP server
pre-configured anyway.

(CERT records are documented in RFC 2538.)

/Simon