Re: Implementation of DN vs. SubjAltName Field

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

Murray,

There has been some very interesting discussion along those lines 
on the SMIME list recently.

It has been pointed out that e-mail addresses may be an invitation to 
spamming, and that it is all too easy to forge the apparent From address
of an e-mail message if only the addr-spec portion of an RFC822 name
is matched.

In addition, as you are recognizing, it can be very difficult to get directory 
administrators to modify their directory structure, even in a fairly small 
organization. Trying to get say the US Navy to change their directory 
structure would be a mind-boggling effort.  Using the RFC822 address
as the primary key field, i.e., primary DN, would result in a very flat directory 
structure that might be hard to maintain.

A third issue is that neither ordinary directory names (as usually deployed)
nor RFC822 names are particularly meaningful or use friendly.

A fourth issue is that none of the name forms provide long term stability
across name changes, organizational changes, etc.

For long term planning, I would suggest that you consider using a constant
employeeID as the linkage between your two DIT structures, whether or not
you include this attribute in the certificate.

Then I would suggest using at least three name forms in your certificates.
the first, which I would like to see used as the primary display form for
the Signer (replacing the From address on a message banner, would be
a subjectAltName in directoryName format containing at a minimum a "real"
commonName, and not some imposed mailbox name.

The second, optional attribute displayed would be the RFC822 name, 
if present, and the third would be the DN in the certificate, which would 
match the DN in the directory.

My advice would be to not make too much of an issue about reissuing 
certificates. Certificates are going to expire in any case, and they should not 
be that expensive or hard to reissue -- if they are, you need to find a different 
CA or CA toolkit vendor, especially since it sounds like you are doing all of 
the due diligence in any case.

Regards,

Bob


Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
bjueneman@novell.com
1-801-861-7387

DISCLAIMER:
  If this message (with or without attached documents) is digitally signed, and/or if certificates are attached, the intended purpose is to 
   (1) Ensure that e-mail came from the apparent sender
   (2) Protect e-mail from tampering
   (3) Ensure that the content of e-mail sent to me and encrypted in  my dual-use key cannot be viewed by others.
  It is explicitly NOT the intent of any such signed message or document to represent any type or form of legally binding contract or other representation, and any such interpretation should not be considered commercially reasonable and WILL BE REPUDIATED, notwithstanding any wording or implications to the opposite effect in the text of the message itself; due in part, but not exclusively, to the fact that the security of my workstation and its associated cryptography is not judged adequately strong for such purposes at present.

>>> "Yutzy, Murray" <murray.yutzy@lmco.com> 02/14/00 02:47PM >>>
We are attempting to accommodate a migration from a PKI that will initially
start with a dedicated PKI directory structure to a corporate directory
structure with different DIT's.  A view is to utilize the SubjAltNAme field
with the email as the unique identifier . This would then be the key field
to populate the corporate DS when that time comes. My understanding is that
if you use a DN in the Subject Field, a change in DIT would require
reissuance of the certificate.

Any pointers to additonal information to better understand how applications
utilize the Subject Field for obtaining information about the certificate
would be appreciated.

Murray Yutzy
Lockheed Martin
407/306-1917
Orlando,FL