Subject: Re: SEIS: Re: Regarding "Given names"

From: "Petra Gl�ckner" <[email-masked]>
Date: Thu, 18 Mar 1999 14:39:23 +0100

Hi Bob,

comments inline

Bob Jueneman wrote:
> 
> --- Message on the SEIS mailing list ([email-masked])
> 
> [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.)
 
No problem ;-)

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