Subject: RE: A web of directories

From: "Kurn, David" <[email-masked]>
Date: Mon, 22 Feb 1999 12:01:50 -0800

Bob et al

Nice generalization.  Of course, you have just re-invented a URI (or is it
URL), so why not in general allow the syntax:

<name-of-protocol>://<ip-address-and-maybe-portno>/<stuff-interpreted-by-the
-server

as the access to the certificate lookup service.  Obvious candidates are
ldap: http: https:

with "ldap:" probably being the default.

I have a problem with presuming any kind of default directory pointer (in
general) because you have no idea where or who will be using your
certificates.  As a metaphor, consider that I send you a snail-mail message,
and list on the top-left of the envelope a return address like:

  123 First Street
  Springfield

Now, as you may know, there are at least 26 instances of Springfield in the
US, but since you're in Utah, you should assume it means "Springfield Utah"?
Hmmm.... Bad idea.

I have no idea if there's any hope in our lifetime of affecting standards,
but at least the discussion is interesting.

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Monday, February 22, 1999 11:38 AM
To: Kurn, David; [email-masked]
Cc: [email-masked]
Subject: A web of directories

<snip>

---

From: "Kurn, David" <[email-masked]>
Date: Mon, 22 Feb 1999 13:28:36 -0800

Mike

Of course, if you *know* it's from the State of Utah.  But, let's consider
that I send you mail.  You have no idea who/what I am, so you look at my
signature certificate and try to deduce something from it.  Maybe if you're
a human being and bring to the table lots of context, you can guess where to
look for CRL,s or for the CA's web site, etc.  But, if you are a computer
program, it would be a lot easier if the certificate stated:

  To find the CRL and other stuff of the CA that issued me, please look in
this <URL or URI or something>.

David

-----Original Message-----
From: Mike Smith [mailto:[email-masked]]
Sent: Monday, February 22, 1999 12:48 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: A web of directories

Bob:

If you received a certificate from State of Utah for your drivers license,
fish and game or whatever, then shouldn't the CA that issued the cert
support the directory service for that function?

Attempting to put all of one's identities in a single certifcate is not
practical for any entity, whether corporate or human or animal (e.g.,
issuing a certificate of authenticity for a thoroughbred race horse with
it's DNA signed by the CA, or some such future application with biometric
filters as part of the biometric certificate authentication to activate the
information system that actually processes the "signature" of the entity
(say, for medical services)).

Anyway, one cert is never enough (and this is not just to drum up more
business for our CA service).

Michael

---

From: Mike Smith <[email-masked]>
Date: Mon, 22 Feb 1999 13:47:51 -0700

Bob:

If you received a certificate from State of Utah for your drivers license, fish and game or whatever, then shouldn't the CA that issued the cert support the directory service for that function?

Attempting to put all of one's identities in a single certifcate is not practical for any entity, whether corporate or human or animal (e.g., issuing a certificate of authenticity for a thoroughbred race horse with it's DNA signed by the CA, or some such future application with biometric filters as part of the biometric certificate authentication to activate the information system that actually processes the "signature" of the entity (say, for medical services)).

Anyway, one cert is never enough (and this is not just to drum up more business for our CA service).

Michael

>>> "Bob Jueneman" <[email-masked]> 02/22/99 12:37PM >>>
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: Mike Smith <[email-masked]>
Date: Mon, 22 Feb 1999 14:45:40 -0700

So, isn't the burden on the CA to include what they need for folks that need to rely on the certificates that they issue?  Private CAs may issue certificates with no linkage to them because they do not wish their certs used outside the domain of trust in which they were issued.

If a CA issues certs to be used in other domains, then the issuing CA needs to ascertain that the other domains or their CA can route requests from the relying parties in those domains back to themselves.

It just seems that this discussion may be trying to solve a problem that won't exist, or, if it does exist, raises competancy (and trust) questions about the CA issuing certs that are intended to be "global" without including the CRL distribution point in the certs they issue.  The alternative for bridging non-global (private) PKIs would most likely have the CAs that would accept the foreign certificates into their domain of trust building the interface or validation process into the system for their subscribers that act as relying parties.

I think that the main problems arising in this discussion come from the perception that the relying party is the source of trust, not the CAs (theirs or the correspondent's issuer or some trusted third party that one or both CAs subscribe to).

If, in Bob's analogy, one were to set up a global directory to whihc all could go, search, retrieve certs and CRLS, it still comes down to the relying party's CA and issuing CA subscribing to or authorizing use of such third party directory for relying on their certificates, thus CRL or OCSP distribution points in their issued certs.

Quite often, the relying party would go into theor own trust domain (i.e., their issuing CA) to let the CA sort out all of the problems with bridging domains of trust transparent to themselves.

The relying party should, in my opinion, always go to THEIR trusted source to see if they are including the received cert and indemnifying them from the pitfalls of a bad or revoked cert.

This trust issue is the crux of any PKI.  If any relying party gets to choose their own trust domains and can't find the source of trust on a received cert, then maybe that is a good thing and they are not supposed to be trusting that cert outside of its own domain of trust?

Michael

>>> "Kurn, David" <[email-masked]> 02/22/99 02:28PM >>>
Mike

David

-----Original Message-----
From: Mike Smith [mailto:[email-masked]] 
Sent: Monday, February 22, 1999 12:48 PM
To: [email-masked]; [email-masked]; [email-masked] 
Cc: [email-masked] 
Subject: Re: A web of directories

Bob:

Michael
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !

---

From: [email-masked]
Date: Mon, 22 Feb 1999 17:13:52 -0500

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

Tom and David,

If my DN is c=US, st=UT,

           [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 {

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

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

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:

Comments?

Bob

Robert R. Jueneman
Security Architect

>>> <[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

To:   [email-masked]

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.

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!

<---- 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

---

From: Andrew Probert <[email-masked]>
Date: Tue, 23 Feb 1999 09:45:44 +1100

Comments inline

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> From:	Kurn, David [SMTP:[email-masked]]
> Sent:	Tuesday, February 23, 1999 7:02 AM
> To:	'Bob Jueneman'; [email-masked]
> Cc:	[email-masked]
> Subject:	RE: A web of directories
> 
> Bob et al
> 
[Andrew Probert]  The syntax needs to be broader than URI if you go down
this path i.e. to also hold reference to X.500/IP server i.e. hostname (or
IP), portnumber, tsap, ssap, psap.  
> and list on the top-left of the envelope a return address like:
	[Andrew Probert]  That's why we need global namespaces for global
electronic commerce!

---

From: [email-masked]
Date: Mon, 22 Feb 1999 19:40:12 -0500

Andrew Probert <[email-masked]> on 02/22/99 05:45:44 PM

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

Comments inline

Andew Probert

> URL), so why not in general allow the syntax:
<name-of-protocol>://<ip-address-and-maybe-portno>/<stuff-interpreted-by-t
> he

[Tom Gindin]  The simplest syntax is probably
NetworkApplicationLocation    ::=  CHOICE
{    UniformResourceID        IA5String,
     presentationAddress PresentationAddress
}
hostname and IP are included in URI and all 3 SAP's in PresentationAddress.
The choices have distinct tags, so no context-specific stuff is necessary.
     [Andrew Probert]  That's why we need global namespaces for global
electronic commerce!
     [Tom Gindin]  Of course we need global namespaces for global
electronic commerce.  We have a number of candidates: X.500 with common
name based on organization, X.500 with personal name based on organization,
X.500 with physical delivery addresses, RFC-822, or URI's (including
RFC-822)?  All of these are global namespaces, and I haven't counted X.400
separately from X.500.

-- snip --

---

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

David, the URI/URL concept was exactly what I had in mind.

However, I wanted it to work across multiple protocols, so I didn't think that
specifying the URI in terms of the current string format was the way to
go, as it wouldn't work for DAP or DSP, for example.  

So I fudged it, by saying that the RDN component would be in ASN.1 
format, as would the rest of the DN, but that the client was responsible for
translating the DER encoded DN into whatever format that particular 
protocol required.

This provides the ability to have our cake and eat it too -- we can stay within 
the X.500 name structure, with all of the advantages of strong type 
encoding where required, while still being compatible with LDAP or 
whatever else is required.

I'm not quite sure I understood our point about having a "default" directory
pointer, especially as it pertains to the ambiguity of where Springfield is located.
Maybe you would like to elaborate.

What I had in mind was to provide at least one guaranteed-to-be-found
location where a particular DN is defined, along with the appropriate certificate
content or other payload.  If desired, the user could include in the SET of
directory providers each and every such directory, and let the client software
choose between them based on any criteria it chooses, such as location 
in the same country (based on the DNS suffix), access protocol supported, etc.

Bob

>>> "Kurn, David" <[email-masked]> 02/22/99 01:01PM >>>
Bob et al

  123 First Street
  Springfield

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]] 
Sent: Monday, February 22, 1999 11:38 AM
To: Kurn, David; [email-masked] 
Cc: [email-masked] 
Subject: A web of directories

<snip>

---

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

I think we are off the track here.

The issue isn't domains of trust, or open vs. closed PKI, it is an issue of how to find 
the directory where ANY information about that DN is listed, since the connection 
between the user's name and the name of his CA, as well as that CA's directory,
may be completely non-obvious.  But I don't want to assume that the name of the 
CA and the name of the directory into which the CA publishes certificates or anything 
else is closely tied together, necessarily.

My model is that if I receive a naked DN, I would first look it up on my own personal 
cache or mini-directory, one that I may have updated with a "Hit the road option" just 
before I left for the airport.

If I don't find it there, my next choice would be to look for it in my corporate directory,
since I have a 100 megabit local LAN connection to it.

If it isn't there, but my company subscribes to a CA/repository service, I might 
well want to check there next, but that assumes a business model that I don't
necessarily want to force on people, any more than I want to compel people 
to necessarily use a directory at all if they would rather use DNS or http.

But if all else fails -- maybe I am a sole practitioner in my bedroom/office, I would like
to know where to point my browser/e-mail/code verification software to next, in order 
to find the certificate corresponding to that DN, and then to proceed to climb the 
Subject/Issuer chain without being compelled to make assumptions about the 
length of that chain or the fact that all of the certificates in the chain after the 
end-user's were necessarily issued by the same organization or are 
necessarily contained in the same directory.

And this has little or nothing to do with how to find CRLs, since we already have 
an adequate mechanism for that (if not necessarily the most elegant or generalizable).

Bob

>>> Mike Smith <[email-masked]> 02/22/99 02:45PM >>>

Michael

Mike

David

-----Original Message-----
From: Mike Smith [mailto:[email-masked]] 
Sent: Monday, February 22, 1999 12:48 PM
To: [email-masked]; [email-masked]; [email-masked] 
Cc: [email-masked] 
Subject: Re: A web of directories

Bob:

Michael
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !

---

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

Yes, they should, as should any CA, except for the fabled Pasadena Ladies
garden Club, that operates their own CA once a year and wishes to outsource 
the directory functions to someone who is in the business of providing directory 
services.

But one of the other desiderata was that this should work for any old DN, and 
not necessarily one that was included in a certificate. So I may not have the
user's certificate, and hence don't know the Issuer's name, nor what directory
access protocol they might want to support.

('Course if we wanted to mandate Novell's variant of DAP, NDAP, that would 
be fine with me. :-)

I don't think there is an issue of trying to put all of one's identities in one certificate --
in fact I was citing multiple certificates for precisely that reason.

Bob

>>> Mike Smith <[email-masked]> 02/22/99 01:47PM >>>
Bob:

Michael

Tom and David,

If my DN is c=US, st=UT, 

PData  SEQUENCE {

Comments?

Bob

Robert R. Jueneman
Security Architect

          Tom Gindin

To:   [email-masked] 

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!

<---- snip ---->

Bob

Robert R. Jueneman
Security Architect

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
                                                                  
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
                                                                  
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
                                                                  
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
                                                                  
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !

---

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 23 Feb 1999 08:52:50 -0700

Rich, what I'm trying to do is to find a way to make directories work,
given the fact that at present there is no reliable, overarching
directory, yet there are hundreds of thousands if not millions 
of corporate directories installed and running.

The problem is that since those have been installed primarily for 
internal corporate use, there is no way of knowing where they are,
even if the directory owner has installed a partial replica on the outside
of the firewall where it would be accessible.

At present, of course, random DNs hardly show up at all, because
the existing protocols, recognizing that richly interconnected 
directories don't exist, send the entire certificate chain down the path
every time, whether they are needed or not. This is true of SET, it's 
true of SSL, and it's true of S/MIME.  This type of unnecessary 
"push" distribution is extraordinarily wasteful of bandwidth  -- you 
say "Hello, world" and get another 1 to 5K of unnecessary baggage.

But this is a chicken and egg problem -- we can't expect the protocols to
stop doing that until there is a workable alternative.

Bob

>>> Rich Salz <[email-masked]> 02/22/99 09:11PM >>>
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: [email-masked]
Date: Tue, 23 Feb 1999 11:09:23 -0500

>Rich, what I'm trying to do is to find a way to make
>directories work

Which (whose) directory? :)  Surely not all of them.

Hm. I think you're actually trying to find a way to avoid
sending a cert chain.  Seems to me that an AIA extension
and just sending the end entity cert probably cuts down the traffic
significantly (what's the average chain length in use
or expected to be in use?  Your guess is as good as mine) --
at least in half.

	/r$

---

From: "Kurn, David" <[email-masked]>
Date: Tue, 23 Feb 1999 08:32:07 -0800

Bob et al...

OK.... Not a URL or URI, but instead
  - Identifier of a protocol
  - Arguments relevant to that protocol
and being ASN.1 challenged, I leave it to others to make that more precise.
I think we are in agreement here.

In any (cryptographic) environment where trust is an issue, we make certain
assumptions about the kind of information available.  As far as I can tell,
it includes (but is not limited to):

- One or more root-certs (or trust points) from which all other trust is
derivied;
- One or more of your own certificates with your private keys;
- A way to get to the CA and Certificate store which houses your own
credentials;

I suppose that we could use the latter as the "default directory" value.

It's quite a jump from that to the ability to check the validity of an
arbitrary arriving certificate.  For example, if you sent me encrypted and
signed mail, using your Novell-issued credentials, I'd first want to check
to see if your issuer has revoked your cert.  I have absolutely no clue how
to find your issuer's CRLs in the current scheme.  It would be unwise to
assume that *my* issuer's directory is linked to yours (and such an
assumption seems to imply a n-squared problem if everyone has to know about
everyone else, which raises scalability issues).

So, I use our new attribute (which identifies the protocol and arguments
relevant to the protocol) to talk to your CA's certificate directory, and I
discover that your cert is not revoked (a very good thing).  

I continue my trust chain, and retrieve your CA's certificate, which lets me
continue the validation of your cert, and find that your CA's certificate is
not self-signed, but is signed by someone in my trust data-base.  Voila ...
I have the necessary cryptographic link.

Now, back to the default issue ....

If your mail was signed by a cert which had no "how-to-find" advice, I'd
really be in trouble.  If I chose the current method, I'd ask my own
directories, but in general, that would be a waste of time.  Furthermore,
asking my own directory where the normal case is "cannot find" puts
unnecessary load on that directory and has scalability problems.

David

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Monday, February 22, 1999 7:16 PM
To: Kurn, David; [email-masked]
Cc: [email-masked]
Subject: RE: A web of directories

However, I wanted it to work across multiple protocols, so I didn't
think that
specifying the URI in terms of the current string format was the way
to
go, as it wouldn't work for DAP or DSP, for example.  

So I fudged it, by saying that the RDN component would be in ASN.1 
format, as would the rest of the DN, but that the client was
responsible for
translating the DER encoded DN into whatever format that particular 
protocol required.

This provides the ability to have our cake and eat it too -- we can
stay within 
the X.500 name structure, with all of the advantages of strong type 
encoding where required, while still being compatible with LDAP or 
whatever else is required.

I'm not quite sure I understood our point about having a "default"
directory
pointer, especially as it pertains to the ambiguity of where
Springfield is located.
Maybe you would like to elaborate.

What I had in mind was to provide at least one guaranteed-to-be-found
location where a particular DN is defined, along with the appropriate
certificate
content or other payload.  If desired, the user could include in the
SET of
directory providers each and every such directory, and let the client
software
choose between them based on any criteria it chooses, such as location

in the same country (based on the DNS suffix), access protocol
supported, etc.

Bob

Bob et al

Nice generalization.  Of course, you have just re-invented a URI (or is
it
URL), so why not in general allow the syntax:

as the access to the certificate lookup service.  Obvious candidates
are
ldap: http: https:

I have a problem with presuming any kind of default directory pointer
(in
general) because you have no idea where or who will be using your
certificates.  As a metaphor, consider that I send you a snail-mail
message,
and list on the top-left of the envelope a return address like:

  123 First Street
  Springfield

Now, as you may know, there are at least 26 instances of Springfield in
the
US, but since you're in Utah, you should assume it means "Springfield
Utah"?
Hmmm.... Bad idea.

I have no idea if there's any hope in our lifetime of affecting
standards,
but at least the discussion is interesting.

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]] 
Sent: Monday, February 22, 1999 11:38 AM
To: Kurn, David; [email-masked] 
Cc: [email-masked] 
Subject: A web of directories

<snip>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Feb 1999 12:36:01 -0500

Bob,

I meant AIA, authority info access. It is in PKIX part 1 and defines a way
to include pointers to info associated with the CA that issued a cert,
e.g., where to find the CA cert, the CRL, and OCSP responder, etc.

Steve

---

From: Larry Layten <[email-masked]>
Date: Wed, 24 Feb 1999 12:39:24 -0600

Steve,

I thought that SRV records provided the means to advertise
a service to an address/port.

Larry

-----Original Message-----
From:	Stephen Kent [SMTP:[email-masked]]
Sent:	Wednesday, February 24, 1999 11:24 AM
To:	Larry Layten
Cc:	Bob Jueneman; [email-masked]
Subject:	RE: A web of directories

Larry,

>For e-mail certificates, can't you use the domain from
>the internet e-mail address to point you to a DNS server
>And can't that in turn point you to the correct LDAP directory.

One can certainly look up the user's DNS server based on e-mail address,
but we don't have a record format in the DNS that points to an LDAP
directory as a result.  One could define such a record type, though.

Steve

---

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 25 Feb 1999 15:21:59 -0700

Hannu,

I agree.  And just because you use one or more e-mail providers doesn't 
necessarily that they provide directory services.

Regardless of which e-mail (or sneaker-net mail) provider is used, you 
would like to be able to point to at least one directory, no matter where 
it resides or who it is affiliated with.

I agree with Steve that the Authority Information Access extension could 
be used for this purpose, although the wording at present suggests that it 
is associated with the Issuer, with no way to look up something associated 
with the Subject.  I assume that could be fixed, if necessary.

(So if I receive a signature-only certificate from someone via S/MIME, 
I still don't know and can't find an encryption key for that user in order to 
respond to him.  That is, unless I look up the Subject's certificate by 
Issuer and serial number and then prowl around in the CA's directory. But 
this implies that the CA is obligated to maintain a directory containing 
all of the Subject certificates, and the CA might not want to do that
or might charge too much.)

I'd still like to find a way of associating this information with the DN itself, so 
it would not require access to the certificate, which may be what we are 
trying to find.

It could easily be done for a single LDAP URL, but I don't want to necessarily 
restrict the directory reference to a single protocol, nor for that matter to a single 
directory supplier.

So I'm thinking about a "Generic Access Protocol" type of URL -- one that 
would identify the directory supplier by a DNS name. Then perhaps DNS could
 then advertise what protocols that directory supports, and what the port number 
is.

Because I don't want to force fit any particular protocol, this "GAP" URL would
consist of a header or prefix, followed by a string of DER-encoded RDNs, i.e.,
the "real" DN as God and X.500 intended. :-)  The client, e.g., a browser,
would be responsible for translating the "GAP" protocol into one that is supported
by that directory, and for example might translate from RDN into an LDAP 
string-type of URL.

I'm in the middle of several hot projects right now and don't have time to think 
about this much more at this time, so I would welcome anyone else trying to 
move the ball forward.

How real is the SRV capability of DNS, and how widely is it used?

Bob

>>> Hannu Nikkanen <[email-masked]> 02/24/99 11:05PM >>>
Larry, Steve, Bob

there may be more real life complications, I'm actually using four e-mail
accounts (wich have separate DNS servers):

- department level mainly in the office;
- corporation level (special services);
- local ISP from home,
- HotMail, when using somebody else's PC.

I have no strict role division between the addresses so my eMail address
may jump even from one continent to the other just depending the way, I get
connected. Correlating the eMail address with one or more (work, personal,
..) LDAP directories would be difficult.

Hannu