Subject: Regarding "Given names"

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 15 Mar 1999 14:57:57 -0700

(Because I believe the subject is important, I am cross-posting this to the ietf-pkix list as well. Apologies for any duplicates.)

Gunnar,

You have introduced yet another degree of freedom into to this complex equation.  I had been sufficiently puzzled how to manage the mapping between a certificate and one or more directories, i.e., the Subscriber or Subject's directory (presumably one operated by his employer, or possibly his Internet Service Provider, or maybe some government agency or third party); the CA's directory (or maybe some third party repository), and the various Relying parties directories. But now you have introduced another level of complexity in wanting to map directly to customer databases, access control lists, patient records, etc.

I think this may be way too much to deal with.  Instead, those application should refer to the directories to look up that additional information as required for their purposes.

I am increasingly inclined to try to reduce these very complex naming problems down to two different forms of names, and in this regard I believe that I am in fairly close agreement with Petra Gloeckner's position reflected by his attached message.

The first, which is the single Distinguished Name, is the name by which the Subject is known to the Subject's own, primary directory, with a prefix if necessary to specify which directory that is and where it can be found. In addition to defining how to access that directory, the prefix name/location of the directory itself may be necessary to define the scope of names issue in order to make the DN globally unambiguous.  In this directory-oriented name structure, it is perfectly acceptable if the name is not particularly human readable or relevant, or tied to physical location, geopolitical boundaries, or organizational structures.  In those countries where a universal serial number is defined and considered acceptable for use (which the US Social Security Number is not, despite its widespread use and abuse), such an ID number could be used.  Otherwise, a unique number within the scope of that directory can be used.

The second name should be the subject's own current chosen name form.  The extent to which that name must conform to "official" registered names may be controlled by law or custom, but should not be presumed.  The name in this case is not necessarily globally unambiguous. The inclusion of additional information in the name, such as current residence or organizational information may be helpful in making it globally unambiguous, but should not be required or presumed.  Instead, additional attributes that are not part of the name per se may supply that information if that is desired, but there may be complex privacy issues that would arise in that case.

Those of us in the US are frequently guilty of assuming that our own legal and cultural customs are universal, and of course they are not.  But I would also caution my European colleagues that the reverse may be true, and this applies in particular to the issue of "official" names.  There is a wide gap between the practices in many of the civil law countries regarding the acceptable composition of names, and how they are officially registered, vs. the common law countries such as the US, the UK, and others.  And I'm not even going to speculate about some of the African and Asian countries.  That's why I suggest that the Subject's own name be considered to be up to the Subject, with few if any presumptions being made as to how "official" that name is (with the exclusion of deliberate fraud.).

Of course it would be presumptuous of me to tell the German government or any other government how to write their laws or regulations, but the Internet essentially knows no boundaries, and codifying particular assumptions into law when they aren't universally warranted is likely to result in the law being ignored as unhelpful. 

A case in point regarding Gunnar's description of alias names would be my father, who in his 87 years has gone through several names that are technically.  Born in 1911 of second generation Germanic heritage, his birth certificate lists his name as Frederick Reade Juenemann, and as a boy he was sometimes called Fritz. But his father was a US Army medical doctor and officer, and when my father started school in a succession of schools on Army posts, World War I had started in Europe, and shortly afterwards the US entered the war against Germany.  Having an obviously Germanic surname and nickname probably didn't make his life any easier, and so without any formal or official process, he dropped the final 'n' and nickname, and registered his name in that form all the way through college.

Sometime during World War II, while serving in the Philippines, he decided that "Frederick" was too much, since everyone called him Fred.  So again,. without going through any formal change of name process, he simply dropped the Frederick Reade and became Fred R. Jueneman, and was registered to vote, etc., under that name from then on.  But in his will, which he signs as Fred R., he is careful to list as "A.K.A." (also known as) aliases the other two name forms.

Now, I suppose if he were so inclined he might request a certificate that contained those alternate names, but I can't imagine why he would want to, or what legitimate purpose might be served by requiring them.

By and large, then, the governing principle for a subject's name should be whatever the Subject prefers.  In my case, that would be "Robert R. Jueneman", not Bob Jueneman (although that's the name I use in spoken conversation or casual written correspondence), and certainly not "Jueneman, Robert R." or "ROBERT Jueneman."  However, if I were to use my middle name as my familiar name, either R. Reade Jueneman or Robert READE Jueneman might be convenient. but it ought to be my choice.

Now that's what my NAME is, and given the existing definitions and what the various software programs are likely to support, that should almost certainly be encoded in the alternateSubjectName, and what should be displayed to any human user or relying party.

My name is NOT [email-masked], although that happens to be one or my e-mail addresses, and I would be rather irritated if I were required to have that as an alternate subject name.  I don't change my identity just because I change e-mail service providers.

However, since the directory that would be most likely to publish my certificate is owned by Novell, I would have no objection to o=Novell, ou=PRV, ou=NSRD, cN=bjueneman or a context name in NDS terms of bjueneman.nsrd.prv.novell, even though "novell" isn't qualified by c=US and isn't as legally correct as "Novell, Inc." would be.  (And prv is really Provo, which isn't an organizational unit in the technical sense at all, and nsrd was an abbreviation for an organizational unit name that disappeared several reorganizations ago, but still lives on in the directory space.)

But for anyone else to use that directory, a better DN might be ldap://directory.novell.com/o=Novell,ou=prv,ou=nsrd,cn=bjueneman.  

Alternatively, although I would prefer to include the directory location within the DN itself as some sort of prefix, it would be acceptable for the DN to be simply o=novell,ou=prv,ou=nsrd,cn=bjueneman, with the directory location, protocol type(s), and port number(s) being provided using the Authority Information Attribute.

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

>>> "Gunnar Klein" <[email-masked]> 03/14/99 10:46PM >>>
--- Message on the SEIS mailing list ([email-masked])

Dear all,

The discussion on given names must continue. It is not an easy task. 

I think it is important what Hans says that we must distinguish between RDNs of Directories and those of certificates. Only had the world been simpler could they have been identical. However, also in directories do we have the problem of finding people using given names and should then not use caps with a meaning, I understand from Magnus.

But my main concern is how we match certificate DNs with those names/identifiers used in all sorts of other systems, customer databases, access control lists, patient records etc. For these purposes it may be an advantage if the certificate can contain more than one "common name". 

Let me make it clear that the structure from the CEN work was not specifically made for certificates and has not been used for it. YET. But it was designed for all sorts of messages where persons identified in one system should be matched with persons identified in another system. The difference of identifying specific attributes for "maiden name", "married name", "name at birth" etc compared to just saying alternative name is that you get an identification of what type of name this "alternative" is. These are all officially registered names at some point in time. Names denoted as aliases can be defined only very privately.

Gunnar
--------------------------
Reply from Magnus

>Gunnar,
>
>There are several things I agree with you on. In particular, as you
>say, names are made unique in SS 614331 by the 'serialNumber'
>attribute, not the name itself. It would also probably have been
>better to allow for several attribute types in each relative
>distinguished name; by doing so one could have combined surnames and
>given names into one RDN and perhaps gotten a more natural directory
>structure. I also agree with you that in general it is not a good idea
>to put a long string consisting of several logical parts in one ASN.1
>string value, and then expect matching to work.
>
>Furthermore, another thing which perhaps deserves some attention here
>is the matching rules for these names. The attributes defined in SS
>614331 are all of the type 'Directorystring', with matching rule
>'caseIgnoreMatch' (ISO/IEC 9594-6). This means that 'HANS gunnar' will
>be equal to 'hans Gunnar' when doing Directory matching, i.e. it is
>not possible for a Directory agent to differentiate between these
>names, unless non-standard matching is employed. IETF RFC 2459
>(PKIX-1) does specify matching rules that do take case into account,
>but only if the associated ASN.1 types are different from
>'PrintableString'. However, 'PrintableString' is the preferred choice
>in SS 6143331.
>
>I fail however to understand the structures defined in the CEN/TC
>251/N98-083 work; perhaps this partly is due to my unfamiliarity with
>this work, but am I correct in interpreting this as: "An individual
>may be known under several names, e.g. name at birth ('NameatBirth'),
>maiden name ('MaidenName'), etc, and each name may consist of any of
>the following parts: title ('Title'), preferred given name
>'PreferredGivenName', etc." ?? 
>
>If so, and in the context of Directories, IMHO it would be
>preferable, in the interest of interoperability, to use existing
>structures (e.g. 'Name' in the ISO/IEC 9594-2 sense), with aliases
>and/or alternative names (as defined in ISO/IEC 9594-8) when an
>individual needs to be known under several names, and to define a few
>more ASN.1 ATTRIBUTEs. The 'preferredGivenName' and
>'preferredSurName' seems to be useful additions in this respect.
>
>(BTW, the ASN.1 needs several fixes, but I guess this was just an
>outline)
>
>Best regards,
>-- Magnus
>
>Magnus Nyström            Email: [email-masked] 
>
>------------------------------------------------------------
>On Fri, 12 Mar 1999, Gunnar Klein wrote:
>
>[...]
>> Definition of Name from CEN/TC 251/N98-083
>>
>> Names ::= SET of Name{
>> NameatBirth      [0],
>> MaidenName       [1],
>> MarriedName      [2],
>> PreviousName     [3],
>> ProfessionalName [4],
>> Alias            [5]}
>>
>> 
>> Name ::= SET { 
>>     Title                     [0] OCTET STRING (SIZE(3)) OPTIONAL,
>>     L-GivenNames              [1] SEQUENCE (SIZE(1..4)) NameElement OPTIONAL,
>>     PreferredGivenName        [2] NameElement OPTIONAL
>>     Initials                  [3] OCTET STRING (SIZE(1..6)) OPTIONAL,
>>     SurnamePrefix             [4] OCTET STRING (SIZE(1..10))OPTIONAL,
>>     L-Surnames                [5] SEQUENCE (SIZE(1..4)) NameElement
>>     PreferredSurname          [6] NameElement OPTIONAL,
>>     SurnameSufix              [7] OCTET STRING (SIZE(1..10 )) OPTIONAL,
>>     QualificationDistinctions [8] OCTET STRING (SIZE( 1..20))OPTIONAL,
>>     UnstructuredName          [9] OCTET STRING (SIZE(1..1000))OPTIONAL
>> }
>> 
>> NameElement ::= OCTET STRING (SIZE(1..35))
>> -------------------------------
>>
>> Maybe this contains too many optional and not highly needed elements
>> generally though they were included in this proposal taken from a
>> study on names and numbers as personal identifiers (attached). The
>> core thing is that you allow objects of both surname and Given names
>> and give the possibility of unanmbigously pointing out which one is
>> preferred. Some reasons why the proposals suggested by Hans within
>> the "standard GivenNames" are not quite sufficient could easily be
>> pointed out. Unfortunately spaces are included in what is logically
>> to be regarded as one name in some situations both for Surnames and
>> Given names. In some situations they are instead linked indicated by
>> a Hyphen such as Hans-Olof BUT according to the preference of the
>> subject and as allowed in our culture it could be that this should
>> be written without hyphen and yet be distinguished from somebody who
>> has two names "Hans" and "Olof" It is even more complicated and
>> important when considering certain surnames. I do not remember a good
>> example now but they exist. Placing preferred name part first has
>> been suggested by many, but is not sufficient since the registered
>> (or traditionally used) order has a significance different from
>> preferred if only one is to be presented.  Capitalization is a
>> possibility that may be an excellent suggestion within the current
>> standard but not really good since Capitals should be included
>> sometimes within name words and has a meaning at least to include
>> readability eg. McLauren.I think it is time to design computer
>> applications that meet the cultural requirements (and when moving
>> towards the replacement of handwritten signatures for non-repudiation
>> this becomes even more important. I had hoped that gone where the
>> days when we in Europe had to accept that all names where spelled
>> with A-Z and in upper case only. 
>
>> Kind regards Gunnar Klein
>
>
>----------------- SEIS mailing list ([email-masked])
>Info about this list: http://www.nc-forum.com/seis 
>SEIS Contact: [email-masked] 
>
>

----------------- SEIS mailing list ([email-masked])
Info about this list: http://www.nc-forum.com/seis 
SEIS Contact: [email-masked] 

Subject: SEIS: Re: Given names
From: "Petra Gl�ckner" <[email-masked]>
To: [email-masked]
Date: Mon, 15 Mar 1999 10:03:40 +0100

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

Hans Nilsson wrote:
> 
> --- Message on the SEIS mailing list ([email-masked])
> 
> Two comments:
> 
> 1. You should look at Stefan's draft for Qualified Certficates, which is
> very much related to this discussion.
> 
> 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
> 
> ----------------- SEIS mailing list ([email-masked])
> Info about this list: http://www.nc-forum.com/seis
> SEIS Contact: [email-masked]

----------------- SEIS mailing list ([email-masked])
Info about this list: http://www.nc-forum.com/seis
SEIS Contact: [email-masked]

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 16 Mar 1999 09:49:47 +0100

Bob,
>Gunnar,
>You have introduced yet another degree of freedom into to this complex equation. 
snip
>I think this may be way too much to deal with.  Instead, those application should refer to >the directories to look up that additional information as required for their purposes.

I agree that there is no point in making the name issue extremely sophisticated as this
will just lead to new problems with interpretation and use.  To use directories for additional
names and information though assumes that the requesting party has access to other
data concerning the person which effectively limits such a scheme to Intranets or to
genuinely public information [such as...].

Another solution is that a CA issues ID-certificates with other data (Picture, Fingerprint,
Names according to local laws etc.) and let the user [only] access those by authentication with
his/hers "Commerce ID" certificate (which would as you suggest not necessarily contain a
globally unique, always legal name but a unique number within the directory).
All ID-certificates for a certain user and CA could have the same public/private keys to
avoid further key distribution and keep private key operations local. 
Then the control and privacy is in the hands of the user. 
 
Alternatively attribute certificates can be accessed using the scheme above.

Regards

Anders Rundgren
Senior Internet e-commerce Architect

http://www.mobilephones-tng.com