Subject: Re: A web of directories

From: Rich Salz <[email-masked]>
Date: Mon, 22 Feb 1999 23:11:39 -0500 (EST)

Is it really that common to get a random, unknown DN and expect to
do something useful with it?  Is it so common that it's worth
defining an AIA-style name/attribute component?

How often do you expect to receive a random DN without the associated
cert?  And when you get them, what are you expecting to do with them?

Sure seems a lot easier to say "send the cert"
	/r$

---

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 22 Feb 1999 20:58:53 -0700

Tom, the last thing I want to get into is an ASN.1 fight, much less an 
X.520 fight.  If we agree about the basic concepts, we can finesse 
the ASN.1 details any way we would like -- we surely have people on this
list that are more expert in that than I am.

(But whether X.520 has a particular attribute is not of very great concern 
to me. Hoyt Kesterson has made it quite clear that these were only 
supposed to be examples, not a Procrustean bed of a standardized schema.
And the NADF and others concluded some time ago that "useful definitions"
was an oxymoron. They aren't. Very. Useful.)

My intent was to do as you suggest, and to provide the necessary information
that any client which understood the protocol could transform into whatever
form of URL, presentation address, or method yet to be determined might 
require.  (That is assuming the basic model of a DNS name and a port 
number for a protocol.)

In particular, I wanted to keep the definitions within the set of X.500/X.509 RDN
components, i.e., I did not want to depart from an ASN.1 structure and suddenly
start using string notation a la LDAP or SPKI. But I have no objection if some
protocol which uses that type of notation wants to convert the RDN sequence to
a standard URL format -- I am assuming that they would.

I do disagree with the concept of putting the information into an issuerAltName
or some similar construct, although I did think about it for several days.

The reason I rejected it is that we already have such alternate names, and 
they may be used for entirely different purposes that are not linked to the primary DN
(subject or issuer), and in addition may need their own form of directory locator function.

As I said in the original note, I wouldn't be opposed to putting the directory locator
function in a different attribute, but only if someone can dream up a way of supporting
both the primary DN and alternate subject names, _and_ keep track of the pairing of
the name and the directory location, especially given that different directories and/or
protocols may be required for different name types.  So far, I haven't thought of a 
way to be able to do that.

Bob

>>> <[email-masked]> 02/22/99 03:13PM >>>
     The construct you've come up with is very useful, but I don't think
it's a DN.  In fact, the LDAP variant is a legal RFC 2255 URL.
Unfortunately, X.520 doesn't have an attribute type for URL's even though
they have the ISO equivalent presentationAddress.  So if you really want to
put this into a DN, why not create a new attribute type syntax called
NetworkApplicationLocation whose syntax is a choice between a URL and a
PresentationAddress.  There's no extra ASN.1 tagging needed, because
PresentationAddress is an ASN.1 sequence, and URL is just an IA5String.
One would then define attributes with this syntax: a general one called
networkApplicationLocation and a more specific one called referenceLocation
or directoryLocation.  The value of directoryLocation in a DN would just be
the leading part (through port number) of the LDAP URL.
     In the case of a certificate, it's simpler and better just to put the
full URL, including underlying DN, into issuerAltName or subjectAltName.

          Tom Gindin

"Bob Jueneman" <[email-masked]> on 02/22/99 02:37:45 PM

To:   Tom Gindin/Watson/IBM, "Kurn, David" <[email-masked]>
cc:   [email-masked] 
Subject:  A web of directories

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