Subject: Can we form certificates with just name and e-mail address

From: Stefan Santesson <[email-masked]>
Date: Fri, 16 Jun 2000 16:29:17 +0200

Just a seemingly easy question!

How do you form a certificate according to PKIX where the subjects name 
only consists of a name (commonName or GivenName + surname) and an e-mail 
address ?? It seams to be virtually impossible to do this.

I'm almost certain that this must have been up before, so I would 
appreciate some hints here.
The problem is that son of RFC 2459 in "4.1.2.6  Subject" says

    Conforming implementations generating new certificates with elec-
    tronic mail addresses MUST use the rfc822Name in the subject alterna-
    tive name field (see sec. 4.2.1.7) to describe such identities.
    Simultaneous inclusion of the EmailAddress attribute in the subject
    distinguished name to support legacy implementations is deprecated
    but permitted.

My problem with this is that the name (given name + surname) is not unique. 
I.e. it can't be stored in the subject field nor as a name form in the 
subjectAltName ext, unless combined with some disambiguating data (such as 
an e-mail address), which is deprecated according to the current text.

This means that inclusion of a name in the subject field must be combined 
with some disambiguating data other than an e-mail address (if the name is 
not unique enough). This seams like a pragmatic view that hardly meets the 
requirements of a practical world.

What has historic debates concluded in?

/Stefan

---

From: Oscar Jacobsson <[email-masked]>
Date: Fri, 16 Jun 2000 18:07:35 +0200

Stefan Santesson wrote:
> [...]

I don't actually know the history here, but I would wager a suggestion:

Could you not leave the subject name empty and include both a rfc822Name
and a directoryName (which would then contain your given name and
surname attributes) in the subject alternate name extension?

//oscar

---

From: "Christopher Williams" <[email-masked]>
Date: Fri, 16 Jun 2000 18:07:47 +0100

You put your common name (or given name + surname) in the SubjectName field
and your e-mail address in the rfc822Name field in a SubjectAlternativeName
field extension.  I don't think that it is too important if the SubjectName
is not unique; the combination of SubjectName and SerialNo has to be unique.

Alternatively, you can leave the SubjectName field blank (unusual but the
standard permits it) and put your common name in a directoryName field in
your alternative name and your e-mail address in an rfc822Name.  While
you're at it, why not include the URL of your homepage in a uRI field!
Remember that a SubjectAlternativeName is type GeneralNames, which means it
can have any number of elements.

On the subject of alternative names, what exactly is an ediPartyName,
anybody?  I know that EDI stands for "Electronic Data Interchange" but I
don't know anything more.

Also, I have to say that I think it's crazy that your e-mail address has to
go into an extension, or can only be placed in the name field by means of a
(deprecated) kludge.  In a world context, your e-mail address is as
important (at least) as your X-500 characteristics.  If I get a personal
certificate, I don't have an "organization" or an "organizational unit"  -
it's just me.

Christopher Williams

Software engineer, NetLexis Ltd.
http://www.netlexis.com "Intelligent Trust"

---

From: Stephen Kent <[email-masked]>
Date: Fri, 16 Jun 2000 14:13:47 -0400

Christopher,

>is not unique; the combination of SubjectName and SerialNo has to be unique.

We have had this discussion in this list.  The decision was that if 
you're going to use a DN field (subject name or a directory name as 
an alt name) then the contents should be "reasonable" in a directory 
context.  That's why, when Denis Pinkas proposed a name form built 
from DN attributes but not consistent with real directory use, he 
agreed to define a new data type for it.  The bottom line is that 
just because a name is constructed from directory attributes, that 
does not make it a reasonable DN.

>can have any number of elements.

But, it is still of type DirectoryName and thus should be a name 
suitable for use in a directory, as noted above.

>don't know anything more.

I always assumed the EDI folks have really exclusive parties and 
never invite the rest of us.

>certificate, I don't have an "organization" or an "organizational unit"  -

I agree that having a cert with an alt subject name that is JUST an 
RFC822 name would be fine.  Your comments re O and OU are correct, 
but perhaps you are missing some context here.  The directory 
distinguishes between organizational persons and residential persons. 
The latter don't contain an O or OU attribute.

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 19 Jun 2000 00:43:48 +0200

Steve,

<snip>
At 14:13 2000-06-16 -0400, you wrote:
>We have had this discussion in this list.  The decision was that if you're 
>going to use a DN field (subject name or a directory name as an alt name) 
>then the contents should be "reasonable" in a directory context.  That's 
>why, when Denis Pinkas proposed a name form built from DN attributes but 
>not consistent with real directory use, he agreed to define a new data 
>type for it.  The bottom line is that just because a name is constructed 
>from directory attributes, that does not make it a reasonable DN.
Rest deleted ....

So I guess you confirm my conclusion that givenName + surname in the 
subject field, or as a directory name in alt name, does NOT by itself form 
a reasonable DN. Especially since there will be duplicate names.

So the only thing left seams to be putting the names in 
SubjectDirectoryAttributes but I have problems/thoughts with that:

1) What will the current installed base of products say about that?
2) The latest X.509 version implies that attributes stored in the 
SubjectDirectoryAttributes are primary for authorization and not part of 
the subjects name.

It seams that we have no where to go.

Why can't an e-mail address be part of a reasonable DN? (I guess that's 
what the current text implies)

/Stefan

---

From: [email-masked] (Terry Hayes)
Date: Mon, 19 Jun 2000 10:16:34 -0700

Stefan Santesson wrote:

> ....

There is no reason that it can't be.  In fact, I believe that e=[email-masked] is a
perfectly good DN.  It's probably not a good DN in the X.509 world, since it isn't
very helpful in locating the portion of the "global" directory that actually
contains the entry.  It is a unique name and probably will work in many LDAP or
other directory environments.

The RFC deprecates using an email component of the DN as the RFC822 name for
delivering email.  This means that you need to put the email address in the
Subject Alternate Name extension as well, to allow S/MIME (and other) applications
to find it there.  It does not mean that it is disallowed as a component in the
DN.

Terry

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Jun 2000 14:52:56 -0400

Terry,

>other directory environments.

I think you mean in the "X.500 world" not "the X.509 world."  X.509 
deals with certs and CRLs, whereas X.500 is the broader directory 
environment.  DNs are X.500 constructs, not X.509 constructs, so it 
is in the directory context that one ought to evaluate the 
appropriateness of a candidate DN.  In that context, the example you 
provide is not a good one, e.g., for the searching reasons you cite, 
as well as others.

David Kemp's suggestion is an example of what one could reasonably do 
to map a DNS name into the DIT.  However, I disagree with David in 
that a real DN, if it does not begin with a country code attribute, 
should begin with an international organization attribute (e.g., for 
the OCRC, NATO, UN, etc.).  The DNS, for legacy reasons, has a 
handful of TLDs that are not country names, which has been the source 
of numerous name battles, scaling problems, etc.

>to find it there.  It does not mean that it is disallowed as a 

I don't think I would characterize the 2459 discussion of e-mail 
addresses in names in quite this way.  What section 4.1.2.6 says is 
that newly generated certs should not contain an EmailAddress 
attribute in the Subject name field. Instead, the preferred approach 
is to place the e-mail address in a subject alt name of the type 
rfc822name.  If a non-null subject name is present, it may include an 
EmailAddress attribute, but such inclusion is permitted for backwards 
compatibility, and it is deprecated.

The overall message from this text is that EmailAddress is a 
directory attribute that has no place in a DN, but we allow it, with 
prejudice, to avoid breaking existing (S/MIME) systems.  Going 
forward, the right approach is to put an e-mail address into the 
subject alt name using the name type designed to carry it.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Jun 2000 15:12:51 -0400

Stefan,

>>an alt name) then the contents should be "reasonable" in a 
>>directory context.  That's why, when Denis Pinkas proposed a name 
>>form built from DN attributes but not consistent with real 
>>directory use, he agreed to define a new data type for it.  The 
>>bottom line is that just because a name is constructed from 
>>directory attributes, that does not make it a reasonable DN.
>Rest deleted ....
>
>subject field, or as a directory name in alt name, does NOT by 
>itself form a reasonable DN. Especially since there will be 
>duplicate names.

Right.

>1) What will the current installed base of products say about that?

I don't know.  Many would probably ignore attributes in that extension.

>SubjectDirectoryAttributes are primary for authorization and not 
>part of the subjects name.

Right again.

>Why can't an e-mail address be part of a reasonable DN? (I guess 
>that's what the current text implies)

The argument is that a DN is the name of an entry in the DIT. One 
would not create a schema where a e-mail address was tacked onto the 
end of an otherwise good DN. It would create an additional layer of 
the tree that served no purpose, as it dangles under the real user 
entry.  An e-mail address is an alternative way of identifying an 
entity. Thus it is a perfectly fine attribute for a directory entry, 
but it makes no sense as an added attribute in a DN.

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 20 Jun 2000 00:50:22 +0200

Steve,

Thank's for useful input. Just to round this up, can you confirm the 
conclusion that issuing certificates where subjects are represented by just 
e-mail address + givenName + surname (and maybe also country) is simply not 
possible.

The name must simply be combined with a serialNumber attribute or some 
other information that makes the name (with e-mail address excluded) a 
reasonable DN.

Right?

/Stefan

At 15:12 2000-06-19 -0400, Stephen Kent wrote:
>>>you're going to use a DN field (subject name or a directory name as an 
>>>alt name) then the contents should be "reasonable" in a directory 
>>>context.  That's why, when Denis Pinkas proposed a name form built from 
>>>DN attributes but not consistent with real directory use, he agreed to 
>>>define a new data type for it.  The bottom line is that just because a 
>>>name is constructed from directory attributes, that does not make it a 
>>>reasonable DN.
>>Rest deleted ....
>>
>>subject field, or as a directory name in alt name, does NOT by itself 
>>form a reasonable DN. Especially since there will be duplicate names.
>
>Right.
>
>>
>The argument is that a DN is the name of an entry in the DIT. One would 
>not create a schema where a e-mail address was tacked onto the end of an 
>otherwise good DN. It would create an additional layer of the tree that 
>served no purpose, as it dangles under the real user entry.  An e-mail 
>address is an alternative way of identifying an entity. Thus it is a 
>perfectly fine attribute for a directory entry, but it makes no sense as 
>an added attribute in a DN.
>
>Steve

---

From: Aram Perez <[email-masked]>
Date: Mon, 19 Jun 2000 18:54:22 -0700

Hi Terry,

> From: [email-masked] (Terry Hayes)
> Date: Mon, 19 Jun 2000 10:16:34 -0700
> To: Stefan Santesson <[email-masked]>
> Cc: Stephen Kent <[email-masked]>, PKIX Mailing List <[email-masked]>
> Subject: Re: Can we form certificates with just name and e-mail address
> 
> Stefan Santesson wrote:
> 
>> ....
>> 

I haven't seen any provide this answer so here I go: Someone can correct my
ASN.1, but a reason you shouldn't use "e=[email-masked]" in a/or as a DN is
that it does not meet the ASN.1 rules for a DN (the '@' symbol is not in one
of the valid character sets for DNs). There are a number of "public CAs"
that do put the '@' in a DN, but technically they are incorrect.

Regards,
Aram Perez

[snip]

---

From: Hans Schupp <[email-masked]>
Date: Tue, 20 Jun 2000 12:06:31 +0200

Aram Perez schrieb:

> I haven't seen any provide this answer so here I go: Someone can
> correct my ASN.1, but a reason you shouldn't use "e=[email-masked]"
> in a/or as a DN is that it does not meet the ASN.1 rules for a DN
> (the '@' symbol is not in one of the valid character sets for DNs).
> There are a number of "public CAs" that do put the '@' in a DN, but
> technically they are incorrect.

There is no single valid character set for "DName", only one for each
defined "AttributeValueAssertion" (i.e. every pair XX=YY).
The email-Attribute (OID 1.2.840.113549.1.9.1) has IA5String as defined
character set, which contains the '@' character.

So there is no problem.

best regards,
Hans Schupp

---

From: Stephen Kent <[email-masked]>
Date: Tue, 20 Jun 2000 11:13:52 -0400

Stefan,

>conclusion that issuing certificates where subjects are represented 
>by just e-mail address + givenName + surname (and maybe also 
>country) is simply not possible.
>
>The name must simply be combined with a serialNumber attribute or 
>some other information that makes the name (with e-mail address 
>excluded) a reasonable DN.
>
>Right?

Well, its possible to issue certs with any sort of DN.  The question 
is what makes sense given the semantics of a DN, not just viewing it 
as a string of AVAs irrespective of context. The question I would ask 
is what would the directory tree look like given a proposed DN.  How 
would the tree be distributed and managed?  Think about the schema 
with those considerations in mind.

For example, if one uses a geopolitical and organizational structure, 
which is the common model for DNs, we see lots of reasonable options 
for dividing the tree and determining who is responsible for 
maintainign what portions of it.  On the other hand, if a DN consists 
of an e-mail address plus givenname and surname, this seems rather 
odd.  The e-mail address, as a single attribute, results in a very 
broad fan out under the root. (in contrast, if one used DC 
attributes, as mentioned recently, one could mimic the structure of 
the DNS, which is well suited for separation and distributed 
maintenance, as the DNS has shown.)  Since e-mail addresses are 
already globally unique, what does the given name and surname do for 
you, from a tree structure standpoint?

Steve