Subject: Certificates, Directories, and Distinguished Names

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 19 Mar 1999 15:47:50 -0700

[Apologies if this is a duplicate. I sent it yesterday, but
it doesn't seem to have shown up on either list yet.]

The message from Petra Gloeckner illustrates that there is an
obvious lack of agreement about the semantics of a DN vs.
the semantics of an alternateSubjectName.

Because of the potential impact on evolving software, I'd like
to escalate this issue to the PKIX co-chairs, Steve Kent and 
Warwick Ford, and to the chair of X.509, Hoyt Kesterson, 
in order to force a expeditious resolution to this issue.

One of these name forms, at least, ought to be usable to 
retrieve a certificate from a directory, whereas the others,
although potentially candidates for inclusion in a directory,
may not represent a real directory entry but may be for
display purposes to RP software, or for other application 
purposes.

I believe that it is extremely important that at least one of the 
multiple name forms that may be carried in a directory reflect
the primary directory name used to store and retrieve such 
certificates.  If I start searching a directory, I don't want to
have to try every name in a certificate looking for other, related 
certificates.

(For example, I may have received a digital signature
certificate from someone, and now I want to look up his 
encryption certificate.  Or maybe my correspondent sent me 
his encryption certificate, but the key length is too long for
my US-exportable software to handle.)

As a practical matter, I don't care much one way or the other
which name form is picked as the primary one, but I very 
much need to have it nailed down, and quickly.  I would 
argue, however, that both historical precedent and the
wording in the standards would argue that the DN should be the
primary directory index name, and that other names, e.g., for display
purposes, should be subjectAltNames.

Bob

>>> "Petra Gl÷ckner" <[email-masked]> 03/18/99 06:39AM >>>

> I certainly understand that there are lots of certificates
> containing DNs which don't correspond to entries in ANY
> directory, much less some well-structured, as-God-intended
> x.500 directory with X.520 DIT structure and schema.
> 
> My point is, and I am agreeing with you to at least a certain
> extent, that if we continue to throw completely arbitrary
> name constructs in the DN, we will make it increasingly difficult
> to ever store or retrieve those certificates in or from a directory.
> 
> So my goal was to get people to recognize that the primary
> purpose of the DN was to facilitate interoperation with a directory.
> And since there may very well be a proliferation of directories with
> incompatible DIT structures and schemas, it is necessary to
> recognize that it is the _subscriber's_ directory that must dictate the
> DIT structure and schema -- not the CA's, and not the recipient's.

I don't think that the primary purpose of the DName is to facilitate 
interoperation with a directory. That was the motivation when they 
defined the X.509v3 certificates, but I think this is not valid anymore.

> Other technical functions such as name subordination may or may
> not have a role to play with respect to the DN.  They could, but
> I suspect that it may not be terribly useful in most cases, just
> because directory names are (unfortunately) not often organized
> along the lines of organizational boundaries that name subordination
> assumes.
> 
> I agree that when writing application software you cannot always
> assume that the DN points to an X.500 entry, as one may never have
> been created.  I would say that it OUGHT to, but it might not.
> 
> On the other hand, I believe that it would be WRONG to believe
> that an alternateSubjectName, in particular, would always point to
> a certificate, or even to a directory entry of any kind.  Again, perhaps
> it ought to, but I may have chosen to express my name and organizational
> structure in a more conventional fashion, perhaps for ease of display and
> recognition, but without a corresponding entry in any existing directory --
> not even an alias.
> 
> For example, my directory name in Novell's corporate directory in business
> card format (top to bottom) is o=novell, ou=prv, ou=nsrd, cn=bjueneman.
> 
> But what I would like to have displayed in someone's certificate viewing
> software would be c=US, o="Novell, Inc.", ou="Network Products Division",
> ou="Network Security Department", cn="Robert R. Jueneman"
>
> Since the purpose of the DN is to convey an entry in the directory, the
> first name form clearly has to be the DN, and the second name form the
> alternateSubjectName.  But that second name form is not an entry in the
> Novell corporate directory,  not even an alias, and not likely to be any time
> soon, even if it has the form directoryName.

I disagree, the directoryName of the SubjectAltName has to convey an
entry 
in the directory, not necessarily the subject DName. So, IMO you should
put 
the first name "o=novell, ou=prv, ou=nsrd, cn=bjueneman" in the
directoryName 
of the SubjectAltName and the second name "c=US, o=Novell, Inc.,
ou=Network 
ProductsDivision, ou=Network Security Department, cn=Robert R. Jueneman" 
in the subject DName.
 
> I agree that it would be quite reasonable to create an alias for such a
> name in a directory somewhere, and I would encourage such a practice.
> I also believe that it may be desirable to include other directory style
> names as additional alternateSubjectNames, perhaps to support other DIT
> structures and/or schemas, but I don't believe that the ietf-pkix group
> is in a position to mandate that a particular alternateSubjectName reflect
> a real entry in any particular directory.  And whether they mandate it or
> not, it isn't likely to happen world-wide any time soon.
> 
> As for the additional information you may require that go beyond "name"
> information per se, I would suggest that you make your PersonalData
> structure a subjectDirectoryAttributes attribute extension (if someone can
> ever figure out what the semantics of _that_ attribute are supposed to be),
> or else simply define a new attribute extension.
> 
> But in general I would be rather opposed to listing much of the type of
> information you have suggested in a certificate at all, and certainly not in
> a name field.

The PersonalData structure shall contain as much information of a person
as 
necessary in order to identify him. You don't have to use all
attributes!

We have chosen the SubjectAltName instead of the
subjectDirectoryAttributes 
extension because the PersonalData structure contains the name of the
person
plus any other required identity information to make the name unique.
But you can easily use any of the attributes defined in the QC-draft,
which 
are not necessary to unmistakably identify the person, within the 
subjectDirectoryAttributes extension since the
subjectDirectoryAttributes 
and the PersonalData structure are both a sequence of attribute.
 
Petra

PS.: I will be on vacation next week. I'll answer as soon I'm back at
work.

---

From: Alan Lloyd <[email-masked]>
Date: Tue, 23 Mar 1999 17:28:44 +1000

A couple of points.

No standard or the theory of directories or PKIs can enforce a naming
model that  will be tied to a commercial business. 

Ther is no universal system design agreed by any one in which the Alt
names are used in a cert - for doing something in terms of additive
process that is coupled to the basic certificate issueance, validation,
revocation or archive processes.

That nothing much will be right with PKIs unless they are tied to a
directory service in which the naming policy reflects a business
organisation, its products and services and that the PKI/CA functions
that serve that have a defined DIT structure representing the CA
management model and;

that directories ( ldap servers) and certificate clients implement
certificate component matching so that certs can be found more
effectively.

As said a PKI is a function tied to a business model which is
represented in directory services. The operational policy reflects the
naming model, the efficiency of using certificates (and managing them)
is governed by the "search" facilities specific to these data structures
- ie certficate and CRL component matching.

As for alt names etc,... why are they there?

I agree with hoyt - can we have clarification

regards alan

----------
From: Bob Jueneman
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Sent: 3/20/99 8:47:50 AM
Subject: Certificates, Directories, and Distinguished Names

Bob

>>> "Petra Gl÷ckner" <[email-masked]> 03/18/99 06:39AM
>>>

in the subject DName.

 
Petra

---

From: Stephen Kent <[email-masked]>
Date: Sun, 21 Mar 1999 20:43:07 -0500

Bob,

>in order to force a expeditious resolution to this issue.

We live but to serve as arbiters in such disputes :-).

>have to try every name in a certificate looking for other, related

I tend to agree that it would be good if at least one subject name could be
used for directory lookup.  But, we have multiple directory options in the
Internet.  If the subject name is present, it's a DN and might be
appropriate for lookup in an X.500 directory.  But, if that DN is made up
DC attribuites, maybe it's really destined to be looked up in the DNS.
Also, if the subject name is NULL and an altName is present, that name
might be a DNS name, an RFC822 name, or an IP address, all of which are
suitable for lookup in the DNS.  So, if you are willing to allow for both
X.500 and DNS directory lookups, it would seem that we have lots of options
here.  I'll leave it to Hoyt to tell me where to lookup EDI party names :-).

Steve