Subject: Re: SEIS: Regarding "Given names"

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 17 Mar 1999 10:32:08 -0700

[Resent to correct the correct address of the pkix list.]

Hi Petra,

(Someone corrected me for referring to you as "he". 
I guess I assumed that Petra was the equivalent 
of the English "Peter," but I should have caught the 
feminine ending.  I apologize.)

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.

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

A certificate is supposed to be a certificate, not a dossier.

I'm glad we are finally having this discussion.  I just wish we had concluded
it, rather than leaving it up in the air, when it began six or seven years ago.

Bob

>>> "Petra Gl÷ckner" <[email-masked]> 03/16/99 09:59AM >>>
Hi Bob,

if you look at existing PKIs you will see that it's quite common to
use Subject DNames which are no entries in a X.500 Directory. These
names are simply used to select certificates or CRLs which are stored 
locally. In former times(PEM) DNames have been additionally used for 
realizing name subordination. So a DName can serve for more than one 
technical purpose. Nowadays with X.509v3 you don't need the DName 
anymore for certificate chaining etc, but that's the way how still 
a lot of software works.
Writing application software you cannot assume that the DName points 
to an X.500 entry, but if there is an AltName extension containg a 
directoryName than you can be sure that you will find a certificate 
there.

We don't require a person's name to be his birth certificate, passport, 
library card, fingerprint card or DNA record. What a person's name is 
has to be defined by national law or policy, and this of course will 
differ. But whatever the definition will be, the required information 
should be put in the PersonalData structure of the subjectAltName 
extension - that's what we propose.

Best regards - Petra (she)

Bob Jueneman wrote:
> 
> Petra said "We recommend to use the respective AltName extension(directoryName) to point to the X.500 Directory entry instead of using the Subject DName." I'm not quite sure what he meant, but I don't think I would agree with him. The Subject DN's one and only purpose, I believe , should be to define the subject's name, i.e., entry reference, in a directory. I would tend to disagree with including an e-mail address or other  superfluous "technical" information in the certificate at all, and especially in a name field.
> 
> I agree that the Subject's "real" name should be contained in the subjectAlternateName field. However, I am not nearly as certain as to the extent to which this represents the "unmistakable identity of the certificate subject" if by that is meant that the name must be globally unambiguous, and in particular if it has to carry all of the other baggage that has been proposed.  A person's name should not be required to be his birth certificate, passport, library card, fingerprint card and DNA record all rolled up into one.
> 
> Regards,
> 
> Bob
> 
> Robert R. Jueneman
> Security Architect
> Network Security Development
> Novell, Inc.
> 122 East 1700 South
> Provo, UT 84606
> [email-masked] 
> 1-801-861-7387
> 

> Subject: SEIS: Re: Given names
> Resent-Date: Mon, 15 Mar 1999 10:02:35 +0100 (MET)
> Resent-From: [email-masked] 
> Date: Mon, 15 Mar 1999 10:03:40 +0100
> From: "Petra Glöckner" <[email-masked]>
> To: [email-masked] 
> References: <[email-masked]>
> 
> --- Message on the SEIS mailing list ([email-masked])
> 
> Writing the Qualified Certficate and the German certificate
> specification we had a long discussion on this naming issue.
> We finally came to the conclusion that the best way to solve
> this problem is to have TWO KINDS of names in a certificate:
> 
> TECHNICAL NAME(S):
> The Subject DName and the SubjectAltName extension will contain
> one or more technical names, to be used for certificate chaining,
> to identify the respective X.500 directory entry or to carry the
> email address or any other technical information.
> We recommend to use the respective AltName extension(directoryName)
> to point to the X.500 Directory entry instead of using the Subject
> DName.
> 
> OFFICIAL/LEGAL NAME:
> We defined a new data structure to be used in the SubjectAltName
> extension(otherName). This new data structure PersonalData has
> to contain the unmistakable identity of the certificate subject
> according to the respective law or policy.
> Please note: the Qualified Certficate and the German certificate
> specification still differ in the PersonalData definition. Once
> the Qualified Certficate draft is settled we will adjust the German
> specification.
> 
> Regards - Petra
> 

> >
> > 2. Please note that the Distinguished Name in the certificate has nothing to
> > do with how/where the certificate is stored in the directory. They just
> > happen to use the same RDN syntax :-)
> > I may for example have a National EID-card with C=SE, CN=Hans Nilsson
> > SN=123456. This is then stored at C=SE, O=iD2, CN=...
> > It took me some time before I understood this, and I have now seen that this
> > difference is explicitly pointed out in the German certificate
> > specification.
> >
> > Regards
> > Hans
> >