Subject: Re: SEIS: Certificates, Directories, and Distinguished Names

From: Stefan Santesson <[email-masked]>
Date: Mon, 22 Mar 1999 12:07:00 +0100

Bob,

The intension is that if any name form (in Qualified Certificates) serve as
locator of a directory entry, this is the DN hold in the subject field. The
concept of distinguished name (hold in the subject field) and unmistakable
identity (hold in either the subject field or the SubjectAltName ext.) are
explained in section 2.5

Section 2.5 says:

   Distinguished name is originally defined in X.501 [X.501] as a
   representation of a directory name, defined as a construct that iden-
   tifies a particular object from among the set of all objects. An
   object can be assigned a distinguished name without being represented
   by an entry in the Directory, but this name is then the name its
   object entry would have had if it were represented in the Directory.
   In the context of qualified certificates, a distinguished name
   denotes a set of attribute values [X.501] which forms a name that is
   unambiguous within a certain domain that forms either a real or a
   virtual DIT (Directory Information Tree)[X.501]. In the case of sub-
   ject names the domain is assumed to be at least the issuing domain of
   the CA.

And section 3.1.2 continues with:

   The subject field SHALL contain a distinguished name of the subject
   (see 2.5 for definition of distinguished name)

   An unmistakable identity (see 2.5) of the subject(based on registered
   name or a pseudonym name) SHALL be present in the certificate in the
   subject field and/or the PersonalData field in the subjectAltName
   extension (see 3.2.1.)

   If the PersonalData field is empty, the unmistakable identity of the
   subject is determined by just the subject field. If the PersonalData
   field is present, it SHALL contain a complete unmistakable identity
   of the subject. In this case the subject field SHALL still contain a
   complete distinguished name.

So this means that a DN shall ALWAYS be present in the subject field.

Hope this answer your question.

/Stefan

At 03:47 PM 3/19/99 -0700, Bob Jueneman wrote:
>--- Message on the SEIS mailing list ([email-masked])
>
>[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.
>
>
>----------------- SEIS mailing list ([email-masked])
>Info about this list: http://www.nc-forum.com/seis
>SEIS Contact: [email-masked]
>
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 24 Mar 1999 21:25:34 -0700

Stefan,

I think we are in pretty close agreement on this. It's just that 
after reading Petra's post it wasn't clear that we were all on the same 
page. But maybe I misinterpreted what she said -- I was (am) concerned 
that we had a diametrically opposite view of what a DN should be.

Section 2.5 as quoted seems quite clear, and particularly the notion 
that that the DN has to be unique within a particular domain, in particular
at least the domain of the CA.  That would suggest, as I think I also
proposed recently, that by qualifying the DN with the identity (in some form)
of the CA, it would be possible to merge otherwise ambiguous 
references to some entity within a common directory.

Of course, it would be nice if all of the names in the directory would be 
globally unambiguous without the necessity of qualifying them by the CA's
name, but the possibility that the directory is operated by an ISP (close to the
original conception of a directory operated by a monopoly carrier), while 
both the CA and the end-entity are unrelated to that directory provided makes
it unlike that this will always be possible.

With respect to the requirement for the PersonalData field contain an
"unmistakable identity", that may or may not be a requirement or even 
desirable depending on your point of view, but it may also not be sufficient.

I may know with almost perfect confidence the "unmistakable identity"
of Elvis, Jimmy Hoffa, Adolph Eichman, or the Unabomber.  But that
knowledge does me very little good unless I can FIND them, at least from
the perspective of arresting them or serving a summons on them.

So if I understand the purpose that the QC is intended to serve (and I 
confess that I haven't read the document, although I'm supportive of the
effort), I would suggest that you modify the requirement to more carefully 
state a requirement that the unmistakable identity provide a least a strong
hint as to where to start looking for that individual if necessary, e.g.,
though some physical location that he has a strong tie to, whether by
financial, residence, or other means.  If the individual is a itinerant laborer or 
vagrant with not fixed address, all of the identity details in the world may 
not help if he doesn't want to be found.

Bob

>>> Stefan Santesson <[email-masked]> 03/22/99 04:07AM >>>
Bob,

Section 2.5 says:

/Stefan

time
not in