Subject: A web of directories

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 22 Feb 1999 12:37:45 -0700

Was: Re: Finding PKIX Servers!

Tom and David,

Sometimes the simplest ideas solve very difficult problems, 
and then you kick yourself for not having thought of it earlier.

For years I have been troubled by the fact that I couldn't 
find a way of dealing with a residential person's DN, when 
there wasn't a monopoly directory service provider or even
a de facto name registration authority.

If my DN is c=US, st=UT, 
cn="Robert R. Jueneman"+driversLicense=159975481,
how can anyone find that entry in a directory if the state of 
Utah doesn't provide a centralized directory service?  Lots 
of directory service providers might actually include or list
that DN in their directory, including the US Post Office, 
the electric company, the gas company, several telephone 
companies, my ISP, etc., etc., not to mention the Utah 
Department of Wildlife Management that issued me a 
fishing license, my health insurance company, and probably 
the FBI, the Social Security Administration and sundry 
other agencies who maintain some kind dossier, not to
mention VeriSign who issued me a certificate, but how can 
anyone find them if they don't know that fact in advance?  

The solution to this problem which now seems increasingly 
obvious and desirable is that the DN itself should include an
optional reference to the directory service provider which 
does contain that DN, i.e., a URL to the 
directory itself.

Because the allowable PKIX name forms allow the use of a URL,
my first thought was to simply list the DN in the form of an LDAP URL:
LDAP://ldap.verisign.com/c=US,st=UT,
cn="Robert R. Jueneman"+driversLicense=159975481.

But to paraphrase Richard Nixon, we could do that, but it 
would be wrong.

We shouldn't force all directory queries into one particular
format and protocol, especially one as restrictive as LDAP.

Instead, I propose creating a new optional attribute, called 
directoryProvider, that would normally be the first RDN in the 
DN, at least when the DN is expressed within a certificate or 
in some other context that is external to the directory itself, 
e.g., as a reference to the originator's name and certificate 
in an S/MIME message.

The tricky part of the definition is that the directoryProvider
attribute could conceivably be IMPLICIT within the directory 
that actually contains the rest of the RDN sequence, but 
could be used as an explicit reference for chaining and/or 
referral within or by a directory that did not contain the rest 
of the RDN sequence.

I'll let someone more expert in directories and ASN.1 suggest
how to best encode that thought, and also explore the 
implications, but roughly what I have in mind is something 
like the following, recognizing that there may be improvements 
possible in these constructs or the way they are encoded:

<  forgiveUsOurASN.1Transgressions ::= ON   >

DirectoryProvider ::= SEQUENCE {
          directoryAccessProtocol  DirectoryAccessProtocol,
          } OPTIONAL

DirectoryAccessProtocol  CHOICE {
           [0]  ldap        PData ("LDAP://", dnsD, ldapPort#   )             
           [1]  dap         PData  ("DAP://", dnsD, dapPort#)        OPTIONAL,     
           [2]  dsp          PData  ("DSP://" dnsD, dspPort#)          OPTIONAL,     
           [3]  http          PData  ("HTTP://", dnsD, httpPort#)      OPTIONAL,    
           [4]  https        PData  ("HTTPS://", dnsD, httpsPort#)  OPTIONAL,   
           [5]  otherAP   Pdata  OPTIONAL }     -- reserved for expansion and/or proprietary protocols

PData  SEQUENCE {
     protocolName    PrintableString,
     dnsD                  DnsD,
     separator            PrintableString ":"
     portNumber        INTEGER}

DnsD ::= DNSName                -- DNS name of the directory service provider's server 
                                                             --    for the named protocol.

By providing support for multiple directory access protocols, the 
directory service provider can offer a choice of methods to someone
who needs to find something in that directory.

Presumably most browsers would either use LDAP or HTTP, assuming 
the directory provider offers those services.

But the directory client would not be forced to go directly to the named 
directory.

Instead, the more reasonable and encouraged behavior would be for 
the client to first try to find the information in the client's own personal 
directory or cache, ignoring the directory provider information, and then 
in the user's own organization's directory, again ignoring the directory provider
information, and only if unsuccessful would it be necessary to go to 
(one or more of) the listed directory service(s).

Assuming that the user's organization directory supports X.500,
that directory should be able to chain directly to the other Directory
Service Agent using the DSP protocol, even though the original query 
might have come in via LDAP or HTTP to a directory front-end.
But if for some reason the user's DSA does not support chaining, it can
bounce the request back to the client, which can then do referral to 
the next directory service provider protocol in the set that it supports.

If we only had to deal with a single name in a certificate, for example
the Issuer, there would be a considerable advantage in making this
attribute completely separate, rather than including the attribute
within the DN itself.  But including a set or sequence of directory
provider names clearly points to a directory which can be assumed 
to have implemented the appropriate schema for the RDN attributes 
that make up the DN, and it will work for alternateSubjectNames 
that are in the form of a DN as well.  

Perhaps more importantly, by extending the DN in this manner, the 
scheme works for references to DNs that are outside of either a 
certificate or a directory construct.  For example, I would hope that
I could receive a signed S/MIME message that only identified the 
originator by his DN, and then go look up that DN without having 
to have the certificates sent down the line to me every time.

Finally, it is assumed that the client understands the various protocols, 
and is responsible for converting the standard DN attribute syntax into 
whatever form the protocol requires. Ideally, the client should also
be capable of doing referral, so that if the first directory provider that is
tried is unavailable or uses a directory access protocol which the 
client doesn't support, the client can move on to the next in the set
or sequence.

Some examples might make this clearer. I'll use a business card type of
output of the protocol string translation for simplicity:

LDAP://directory.verisign.com/c=US,o="XYZ Corp.", cn="John Smith"

DAP://voter.ut.us/c=US, st=UT, l=Provo, cn="Robert R. Jueneman"

http://adblitz.yahoo.com/c=US, rfc822="[email-masked]" 

Comments?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

>>> <[email-masked]> 02/22/99 09:51AM >>>
     I don't think the location of an LDAP server should be mandatory, but
an LDAP URL would be a reasonable option within issuerAltName.  While the
DNS name could be used instead, it might be ambiguous in that existing
extension, so it would probably need a new extension.

          Tom Gindin

"Kurn, David" <[email-masked]> on 02/16/99 02:45:02 PM

To:   [email-masked] 
cc:    (bcc: Tom Gindin/Watson/IBM)
Subject:  RE: Finding PKIX Servers!

Bob Jueneman's comments do raise some nice "wouldn't it have been nicer if"
points, but I think he has identified a real need in our efforts to deploy
PKI.

Ignoring, for the moment, how I obtained Bob's key-encryption cert in the
first place, there are two other places I must go to before I can evaluate
trust.

1)  I must find the certificate of the issuer (signer) of the certificate
2)  I must find the CRL which covers this cert.

Of course, this is a recursive problem.

Maybe Bob's suggestion should be augmented so that the LDAP service address
(DNS name) for each is specified in all PKI certs.  Call it optional (to
satisfy the purists), but make it painful to omit.

David Kurn
Compaq Computers Corp
Tandem Division

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]] 
Sent: Tuesday, February 16, 1999 10:56 AM
To: [email-masked] 
Subject: RE: Finding PKIX Servers!

On the heat vs. light scale, a lot of the commentary on this thread
has been well down in the infrared, but with a few flashes of insight.

Let me try to readdress the points I was trying to make.

<---- snip ---->

So I'll say again, wouldn't it be a Good Thing if we could have an optional
attribute
in a certificate that is associated with the Issuer's name somehow, one
that
would
provide the DNS name of an LDAP server that contains the Issuer's
certificate?

At this point in time, I don't care particularly what form the attribute
takes -- it could be
an agreed-upon semantics for DNS name as a form of alternateSubjectName, or
it
could be some other alternateSubjectName attribute, or some other attribute
entirely.

But is there at least some agreement about the potential utility of this
concept?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked] 
1-801-861-7387

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Feb 1999 12:04:16 -0500

Bob,

Aw, come on now, Bob.  DN's are NOT intended to include pointers to
directory servers.  They are names within the DIT.  Don't try to shoehorn
other info into a DN just because the GeneralName form allows other forms
of IDs.  I agree with the suggestion that one could use the AAI extension
with an appropriate sub-type.  (Actually, a previous version of PKIX Part
1, which allowed for end-entity info rather than CA info makes more sense
here, but we seemd to have lost that distinction along the way.)

Steve

---

From: Andreas Berger <[email-masked]>
Date: Thu, 04 Mar 1999 12:47:46 +0100

Hello all,

I wrote a similar message about a year ago but it was mostly ignored...

Anyway, it seems that wa all have a problem here.

The problem, in my opinion, is that we simply do not have a global X.500
service deployed (for whatever reason) but we use X.500 identifiers
(DNs) in our systems. So whenever I need the entry for a particular DN,
I have no method to find the server serving this information. X.500
would do this.

The basic lookup processes we have are:

- resolve an eMail address into a certificate for encryption.
- resolve a DN into a certificate (looking up a CA certificate)
- resolve a DN into a CRL (looking up a CA´s CRL)
- find other services (OCSP) based on a DN

I suggest the following:

In order allow independet deployment of PKIX "directoy servers" we
should follow the Mail Model: A company puts a service on the net,
announcing the availiability using DNS. I find it perfectly reasonable
to have my company, GMD in Germany, to offer an external LDAP service
for their employees, under (e.g.) ldap.gmd.de.

The problem now is how to resolve the X.500 DN (O=GMD Forschungszentrum
Informationstechnik GmbH, c=DE) into the DNS domain (gmd.de).

The first method for a user would be to contact any official LDAP
gateway to X.500 and look up the entry for GMD. This may work if GMD has
set up a proper X.500 server. Then two cases exist: GMD has set up only
one entry for its name or it has set up a complete X.500 system. The
second case is easy, it the X.500 model. In the first case, we could
hope that the domain name is contained as an attribute in the X.500
entry.

Now I have a DNS domain name, gmd.de, which could then be queries via
DNS and optionally SRV records (e.g. I can first ask for an SRV record
for a specific protocol that the user´s client understands like LDAP).
If that does not work, the client could try ldap.gmd.de and get the
server´s name.

Now let´s suppose a case where the organization does not have an X.500
entry. One idea would be to use the IssuerAlternativeName to supply the
"root" DNS name inside the certificate. A good solution in my opinion.

Another idea would be to have a special DNS tree assocatiated and look
up the Distinguished name:

e.g. In the case of a non-existent X.500 entry or unavailibility of an
X.500 server AND no DNS name in the alternative name, try to hash the
DER encoded distinguished name, encode it in HEX or BASE64 and look up:

  abcd1234fdea8765abcd1234fdea8765.x500.org

or split the x500 DNS even more, x500.de or de.x500.org to allow a
distributed management. It *IS* a hack, but it may work until we have
X.500 deployed at least for CAs.

The problem of resolving an eMail address can be solved similarily via
SRV records, deriving the domain name from the host address part of the
eMail, a similar technique for the MX records (and also proposed during
LDAP development with the DX record).

Andreas
-- 
Fifty-three percent of Fortune 1000 executives think the
Arch Deluxe is something that helps to run a computer.
-- Jericho Communications

---

From: Marc Jadoul <[email-masked]>
Date: Thu, 04 Mar 1999 19:05:16 +0100

Hi,

I really find acceptable to send an email to the person i want to
contact and wait for his signed reply. Don't you ?

I do not know how s/mime work, but it seems also the only way to know if
the program he use is able to do strong crypto or even negotiate other
need parameter to initiate a secure communication. Isn't it ?

Marc Jadoul