Subject: Re: Regarding "Given names"

From: "Zahid Ahmed" <[email-masked]>
Date: Mon, 15 Mar 1999 09:05:26 -0800

I agree we want to limit the scope of naming attribute to a minimum
set so that the mapping between certificates and directories can be
administered easily and reliably.

However, I think it is going to valuable if we can include in we can
link the basic user object, as viewed and managed from the
enterprise security standpoint, to the application-level user object,
i.e., the customer user object. Internet applications must have
reliable and consistent user management frameworks.

 I don't see in PKIX any thing clearly defined to bridge the gap between
primitive, secuirty-centric, user Objects (based on X.509) and
application-level user object that clients are going to initialize
routinely.

Zahid Ahmed                     Commerce One, Inc.
Commerce Security Architect
email: [email-masked]
v: (650)-623-2814
fax: (650)-938-8055
-----Original Message-----
From: Bob Jueneman <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Monday, March 15, 1999 4:05 PM
Subject: Regarding "Given names"

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Mar 1999 10:02:31 -0500

Zahid,

>reliable and consistent user management frameworks.

The focus of qualified certificates is identification suitable for
non-rtepudiable, legal signatures.  Many applications do not require such
certificates, so it may not be reasonable, or necessary, to find a way to
universally link name forms in these qualified certs to name forms employed
by a wide range of applications.  However, I do agree with the basic
principle you cite here, i.e., close matching of name forms between certs
and applications.  My general suggestion of how to achieve this is by
issuing multiple certs to users, each with a name form managed by an
application (or closely releated set of applications).

>application-level user object that clients are going to initialize

Well, it depends on the applications.  For example, RFC 2459 encourages use
of the rfc822Name AltSubjectName for S/MIME users.  That's a good example
of a nice, close mapping.  In the IPsec context, appropriate name forms
include IP addresses, DNS names, and rfc822 names, all of which are
supported in X.509 certs.

Steve