Subject: Certificate mapping (was: Re: Qualified Certificates draft - Country name)

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 04 Mar 1999 11:21:31 -0700

Steve,

>I think one really wants partitioning along organizational lines, not the
arbitrary lines that the CIDR-like approach would imply.  Organizational
responsibility for maintenance of directories has worked well for the DNS,
and if one were to create a PKI tied to the DNS, e.g., based on DNs that
employ only DC attributes, then I think we would want to make use of the
record types already defined for storage of X.509 certs.

>Steve

I don't agree, at least if you are suggesting that PKI names MUST be
tied to a DNS structure.

The problem is that lots of servers do not have DNS name, 
but only IP addresses, and that doesn't include servers that use 
other forms of addressing such as Novell's IPX,  older Mac systems, 
etc.  They are not necessarily mapped to an IP address at all, and 
may not even be connected to the IP-Internet.

When it comes to end-users, I believe that the IETF mantra is that
we are still assuming only limited connectivity to the Internet.  Granted,
as the Internet becomes increasingly ubiquitous it may be appropriate
for the IETF to formally revisit that basic assumption, but at least as of this
moment, I do NOT believe that we should assume that every user even
HAS a DNS name, in his e-mail address or elsewhere, or even that 
he has an e-mail address, much less that he is connected,
or that his e-mail provider necessarily has anything to do with his 
organization or his personal life, etc.  

A few years ago, when telecommuting from home, I used Frontier 
Technologies' e-mail package, which included both an 
SMTP client and server on my workstation, in order to avoid 
some of the problems with POP mail and sometimes unreliable 
servers and occasionally interrupted connectivity. When I did 
have connectivity, which I wanted to be restored without my 
intervention, I wanted to have all of my mail downloaded and 
processed without my having to go out and tell the server that 
I was now ready to read my mail, and then have to sit there and 
wait. That system met my needs, but my "ISP" was my company, 
and neither they nor I would  have been prepared to host a 
directory service at that time. Instead, had I really needed one, 
I might have contracted out that function, but probably to 
someone with a completely unrelated DNS name.

There are lots of other ways that I can exchange digitally signed
information, including sneaker-net and Federal Express, and 
tying something as fundamental as a certificate lookup
process to a particular network connectivity and/or e-mail 
processing model would be simply wrong.  An RFC 822 mail address
is an interesting and perhaps useful factoid, as is an X.400 name, as is
my organizational person X.520 style name, as is my geopolitical 
residential person name, but NONE of these may happen to correspond
to the way that my chosen (or company-dictated) directory provider wants
to organize their directory to optimize their particular value proposition.

If they choose to use a flat name space that doesn't even include 
a country code, such as o=XYZ, employeeID=1234567, then so 
be it -- they may have perfectly valid reasons for that, including 
tracking employee benefits across marriage and other name 
changes, rank changes (in the military), periodic organizational 
realignments, operations in multiple countries with employees 
who routinely transfer between countries, etc., for a 40 year 
career plus retirement.

The fact that a PKI certificate is issued with a one to three year 
validity is certainly NOT sufficient reason to force a directory provider 
to change the way they organize their business.  It's a variant of the 
Golden Rule -- "he who has the gold, rules," and in this case the "gold" 
is the directory in which certificates are to be placed so others can
find them.

This leads me to what I now believe is a fundamental 
principle, and one that has taken me a long time to arrive at.

I believe that we must recognize that the DN in the certificate was 
originally intended to directly reflect the primary name of the entity 
in the directory, in this case the directory  in which the subscriber 
chooses to publish his certificates, and the DN in the 
certificate should continue to be used for that 
purpose exclusively. If your CA won't support your directory's
choice of DIT and schema, at least with respect to the DN, 
then find another CA.  And don't assume that all directories are 
ever going to be globally interconnected or have a common
DIT structure or schema -- they won't, ever.

Other names and/or forms of identification that can be used to 
LOCATE someone should be relegated to alternateSubjectNames, 
and browsers and other forms of relying party software MUST be 
required to be able to display and/or otherwise process such 
information, regardless of multiple language support issues, etc.

On the other hand, information that cannot be used to locate 
someone but instead is merely used confirm their identity once 
they have been found, including the infamous MPEG movie of me 
playing with my cat, or my fingerprint template, retinal scan,
voice print, photograph, or DNS profile, etc., should be 
carried in other certificate attributes, as they are not "names."

Likewise, attributes which convey rights, privileges, restrictions, 
etc., should not be contained in either the DN or alternate
names either, as they are not names either.  (I might relent a 
little in the case of a role, which might be considered a form
of name, but only if the directory supports it.)

Bob

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