RE: A web of directories

["Kurn, David" <david.kurn@xxxxxxxxxx>]

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:BJUENEMAN@novell.com]
Sent: Monday, February 22, 1999 7:16 PM
To: Kurn, David; tgindin@us.ibm.com
Cc: ietf-pkix@imc.org
Subject: RE: A web of directories


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" <david.kurn@compaq.com> 02/22/99 01:01PM >>>
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:BJUENEMAN@novell.com] 
Sent: Monday, February 22, 1999 11:38 AM
To: Kurn, David; tgindin@us.ibm.com 
Cc: ietf-pkix@imc.org 
Subject: A web of directories

<snip>