Subject: RE: C=country; just a convention?

From: [email-masked] (Peter Gutmann)
Date: Sat, 19 May 2001 12:33:35 (NZST)

Vivian Cancio <[email-masked]> writes:

>I noticed that RFC 1485 is not included in the RFC 2459 references and the
>table (in RFC 1485) is rather limited.

The short forms of DN components is another one of these "hunt the thimble"
affairs which is even more fun than looking for OIDs.  Here are the ones I've
found either in common use or at least defined in only one place (ie they're at
least definitely (in)accurate):

Label	Component
bc		businessCategory
c		countryName
cn		commonName
d		description
dc		domainComponent
email	emailAddress (PKCS #9)
g		givenName
i		initials
isdn	internationalISDNNumber
l		locality
o		organisationName
ou		organisationalUnitName
s		surname
sn		serialNumber
sp		stateOrProvinceName
st		streetAddress
t		title

Peter.

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 21 May 2001 08:46:34 -0400

Peter:

The table in RFC 2253 has a few discrepancies with your table.

                     String  X.500 AttributeType
                     ------------------------------
                     CN      commonName
                     L       localityName
                     ST      stateOrProvinceName
                     O       organizationName
                     OU      organizationalUnitName
                     C       countryName
                     STREET  streetAddress
                     DC      domainComponent
                     UID     userid

Russ

---

From: "Robert Klerer" <[email-masked]>
Date: Mon, 21 May 2001 11:52:49 -0400

And also remember that the ASN.1 in the subjectDN is written so that any
prefix is a valid entry in the directory (from x.501) -- which translates
into

c=us, o=My Company ,cn=me

While LDAP traditionally presents the cn first in the textual
representations and is generally considered the authoritative (since x.500
is silent on this issue) for the textual representation of DNs so the same
name would be:

cn=me,o=My Company,c=us

:)

Now which name will the api Certificate.SubjectDN().getName() return depends
upon how carefully that particular implementation's authors read the
standards that must be inferred.  Also note that getName() returns a String
representation and if anyone were to suggest that the ASN.1 is authoritative
please respond with a "How come getName does not return the ASN.1 DER
encoded in a byte[]?"

----

Peter:

Russ