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

[Stephen Kent <kent@xxxxxxx>]

Terry,

> Stefan Santesson wrote:
>
>  > ....
>  >
>  > Why can't an e-mail address be part of a reasonable DN? (I guess that's
>  > what the current text implies)
>  >
>
> There is no reason that it can't be.  In fact, I believe that 
> e=name@isp.com 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.
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.

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