[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
>>> "Bob Jueneman" <BJUENEMAN@novell.com> 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="newbie@aol.com"
Comments?
Bob
Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
bjueneman@novell.com
1-801-861-7387
>>> <tgindin@us.ibm.com> 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" <david.kurn@compaq.com> on 02/16/99 02:45:02 PM
To: ietf-pkix@imc.org
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:BJUENEMAN@novell.com]
Sent: Tuesday, February 16, 1999 10:56 AM
To: ietf-pkix@imc.org
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
bjueneman@novell.com
1-801-861-7387