Subject: C=country; just a convention?

From: Vivian Cancio <[email-masked]>
Date: Fri, 18 May 2001 14:18:07 -0700

A simple question ...
Security applications which display certificate attributes use short
'acronyms' to describe the parts of the "relative distinguish name" such as
C=country, O=organization, S=state, etc.

I'm aware of the OIDs for the ASN1 structures ... I haven't found a
description of this 'acronym' convention which is also used in X.5xx
examples.

Is it just a de-facto convention or is it specified somewhere?

I checked just about all the X.5xx documents and I couldn't find even a
legend for the examples using this convention, ... although it might be
specified in some of the  many references. Can someone tell me where they
are defined?

Thanks,
Vivian

---

From: Peter Williams <[email-masked]>
Date: Fri, 18 May 2001 15:04:38 -0700

RFC 1485

-----Original Message-----
From: Vivian Cancio [mailto:[email-masked]]
Sent: Friday, May 18, 2001 2:18 PM
To: 'PKI List'
Subject: C=country; just a convention?

A simple question ...

Thanks,
Vivian

---

From: Vivian Cancio <[email-masked]>
Date: Fri, 18 May 2001 16:34:40 -0700

Thanks Peter,
I noticed that RFC 1485 is not included in the RFC 2459 references and the
table (in RFC 1485) is rather limited.  Also it references "X.520 keys", but
these are only examples in X.520, and the RFC incorrectly uses ST for State:

                       Key  Attribute (X.520 keys)
                        ______________________________
                        CN   CommonName
                        L    LocalityName
                        ST   StateOrProvinceName
                        O    OrganizationName
                        OU   OrganizationalUnitName
                        C    CountryName

                      Table 1:  Standardised Keywords

The example in X.520 Section 5.3.3 State or Province Name - shows the "S="
and not "ST=".

"An attribute value for State or Province Name is a string, e.g. S = "Ohio".

stateOrProvinceName  ATTRIBUTE  ::=  {
	SUBTYPE OF	name
	WITH SYNTAX	DirectoryString {ub-state-name}
	ID			id-at-stateOrProvinceName }

I'm assuming that since it doesn't go "on the wire" it is somewhat
irrelevant?

Vivian

> From: Peter Williams [mailto:[email-masked]]
> Sent: Friday, May 18, 2001 3:05 PM
> To: Vivian Cancio; 'PKI List'
> Subject: RE: C=country; just a convention?
> 
> 
> 
> RFC 1485
> 
>

---

From: Alex Deacon <[email-masked]>
Date: Fri, 18 May 2001 17:48:59 -0700

It may be also interesting to have a look at RFC 1778.  In addition you
should note that RFC 1485 and RFC 1779 have been obsoleted by RFC  2253.

Alex

> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, May 19, 2001 5:34 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Vivian Cancio <[email-masked]> writes:
> 
> >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: Frank Balluffi <[email-masked]>
Date: Fri, 18 May 2001 18:41:46 -0700

> I'm assuming that since it doesn't go "on the wire" it is somewhat

As I recall LDAP does transmit the string representation of a Name (e.g.,
"CN=Steve Kille,O=Isode Limited,C=GB") over the wire in an OCTET STRING (or
LDAPString). You can even roll your own AttributeTypeAndValues using
period-delimited attribute types and hexadecimal attribute values. For
example

1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB [From RFC 2253.]

Frank

---

From: Frank Balluffi <[email-masked]>
Date: Mon, 21 May 2001 11:06:01 -0700

Vivian,

RFC 2253 is the most up-to-date standard for the string representation of a
distinguished name, which defines ST for stateOrProvinceName and STREET for
streetAddress.

X.520 does not define string representations -- it defines attributes in
ASN.1.

Peter's list is Peter's list :-).

I would go with RFC 2253.

Frank

> Sent: Monday, May 21, 2001 1:55 PM
> To: 'Frank Balluffi'
> Cc: [email-masked]
> Frank Balluffi said:
> > As I recall LDAP does transmit the string representation of a 
> > Name (e.g., "CN=Steve Kille,O=Isode Limited,C=GB") over the 
> > wire in anOCTET STRING (or LDAPString).
> 
> It may not work if "stateOrProvinceName" is ever one of the fields
> transmitted between vendors. See the discrepancies from the 
> feedback. I have
> concluded that there's no specification defining a formal 
> standard for these
> short names. Any expected interoperability over the wire must 
> rely on the
> OID (which was the intention in the first place?).
> 
> I guess the users reading displayed certificates using this 
> terminology must
> be clever and deduct based on the information on the right of 
> the "=", or
> vendors should provide "legends" defining their use.
> 
> Here is one example of discrepancy:
> In X.520:
> s	stateOrProvinceName
> 
> In Peter's list:
> sp	stateOrProvinceName
> st	streetAddress
> s	surname
> 
> In RFC 2253
> st	stateOrProvinceName
> 
> 
> Vivian
> 
> 
> > From: Frank Balluffi [mailto:[email-masked]]
> > Sent: Friday, May 18, 2001 6:42 PM
> > To: Vivian Cancio
> > Cc: [email-masked]

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 22 May 2001 08:08:47 (NZST)

"Housley, Russ" <[email-masked]> writes:

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

Yes I know, I took the ones which are in common use.  RFC 2253 has its
definitions for things like street addresses and state or province, but other
places define them differently, and it appears that people are using the
definitions given in other places.

                    "But it izz written!" bellowed Beelzebub.
                    "But it might be written differently somewhere else" said
                        Crowley.  "Where you can't read it".
                    "In bigger letters" said Aziraphale.
                    "Underlined" Crowley added.
                    "Twice" suggested Aziraphale.
                        -- Neil Gaiman and Terry Pratchett, "Good Omens"

Peter.

---

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 21 May 2001 14:25:51 -0600

My very vague recollection is that these "business card abbreviations" were originally defined in X.400??

Bob

>>> Peter Gutmann <[email-masked]> 05/22/01 08:08AM >>>

Peter.

---

From: "Timothy Hahn" <[email-masked]>
Date: Mon, 21 May 2001 16:22:44 -0400

Hi all,

FWIW, the most up-to-date information regarding string forms of 
distinguished names, as prescribed by LDAP-related documents can be found 
in:

"Lightweight Directory Access Protocol (v3): UTF-8 String Representation 
of Distinguished Names", Kurt Zeilenga, 04/30/2001. (19892 bytes)
(http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-dn-05.txt)
     The X.500 Directory uses distinguished names as the primary keys to 
entries in the directory. Distinguished Names are encoded in ASN.1 in the 
X.500
     Directory protocols. In the Lightweight Directory Access Protocol, a 
string representation of distinguished names is transferred. This 
specification defines the
     string format for representing names, which is designed to give a 
clean representation of commonly used distinguished names, while being 
able to
     represent any distinguished name. 

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

[email-masked] (Terry Hayes)
Sent by: [email-masked]
05/21/2001 02:47 PM

        To:     Vivian Cancio <[email-masked]>
        cc:     "'Frank Balluffi'" <[email-masked]>, [email-masked]
        Subject:        Re: C=country; just a convention?

I believe the string representation of a Distinguished Name (DN) that we 
are discussing is defined by the LDAP RFCs, not by X.500 or PKIX .  As 
such we should expect that the LDAP RFC would give some indication as to 
the proper form of the attribute type. Looking in RFC 2253, we find the 
following statement:

  "If the AttributeType is in a published table of attribute types 
associated with LDAP [4], then the type name string from that table is 
used, otherwise it is encoded as the dotted-decimal encoding of the 
AttributeType's OBJECT IDENTIFIER."

The reference "LDAP [4]" is for RFC 2252.  However I don't see a table 
of values in that document.  RFC 2252 itself references X.520, so it may 
be intended that attribute type strings from that document should apply.

Terry Hayes

Vivian Cancio wrote:

>transmitted between vendors. See the discrepancies from the feedback. I 
have
>concluded that there's no specification defining a formal standard for 
these
>short names. Any expected interoperability over the wire must rely on the
>I guess the users reading displayed certificates using this terminology 
must
>be clever and deduct based on the information on the right of the "=", or
>>Name (e.g.,

---

From: Peter Williams <[email-masked]>
Date: Mon, 21 May 2001 14:36:02 -0700

The way your bis reference text on AttributeType encoding is phrased
suggests 
that it is INCORRECT to use country=GB; one MUST use c=GB.

The specification also suggests, strongly, that using the name of the
ASN.1 type for the string-name of the AttributeType is WRONG. Unless
the type is one of those listed in the table of 2.3; one MUST use the 
dotted-decimal form.

PKIX may want to provide specification advice, on all this.

 -----Original Message-----
From: Timothy Hahn [mailto:[email-masked]]
Sent: Monday, May 21, 2001 1:23 PM
To: [email-masked]
Subject: Re: C=country; just a convention?

Hi all, 

"Lightweight Directory Access Protocol (v3): UTF-8 String Representation of
Distinguished Names", Kurt Zeilenga, 04/30/2001. (19892 bytes) 
(http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-dn-05.txt) 
     The X.500 Directory uses distinguished names as the primary keys to
entries in the directory. Distinguished Names are encoded in ASN.1 in the
X.500 
     Directory protocols. In the Lightweight Directory Access Protocol, a
string representation of distinguished names is transferred. This
specification defines the 
     string format for representing names, which is designed to give a clean
representation of commonly used distinguished names, while being able to 
     represent any distinguished name. 

Regards,
Tim Hahn

        
        To:        Vivian Cancio <[email-masked]> 
        cc:        "'Frank Balluffi'" <[email-masked]>,
[email-masked] 
        Subject:        Re: C=country; just a convention? 

Terry Hayes

have
these
must

---

From: "Timothy Hahn" <[email-masked]>
Date: Mon, 21 May 2001 17:56:00 -0400

Peter,

The Internet Draft is written with those words to ensure that string forms 
are consistently interpreted.  For attributes that do not appear in "the 
table", it is possible that the non-OID form of the attribute type name 
could be different between different servers.

The Internet Draft also makes the usage of the "short attribute names" 
more explicit than the prior RFC.

Kurt Zeilenga is the author of the Internet Draft and can provide more 
details regarding the intent.

Regards,
Tim Hahn

Peter Williams <[email-masked]>
05/21/2001 05:36 PM

        To:     "'Timothy Hahn'" <[email-masked]>, [email-masked]
        cc: 
        Subject:        RE: C=country; just a convention?

 -----Original Message-----
From: Timothy Hahn [mailto:[email-masked]]
Sent: Monday, May 21, 2001 1:23 PM
To: [email-masked]
Subject: Re: C=country; just a convention?

Hi all, 

of
clean

Regards,
Tim Hahn

 

Terry Hayes

have
these
must

---

From: Vivian Cancio <[email-masked]>
Date: Mon, 21 May 2001 15:18:17 -0700

Terry Hayes wrote:

> RFC 2252 itself references X.520, so it may 

In the X.500, X.509, X.520 and others, I couldn't find a 'normative' section
specifying the use of these short names, they are only used in examples.

Frank Balluffi wrote:

> RFC 2253 is the most up-to-date standard for the string 
> representation of a distinguished name, which defines
> ST for stateOrProvinceName and STREET for streetAddress.
> <snip>

Hmm ... it's really not 'defined' ...
RFC 2253 reads (and exactly quote below) ... 
"As an example, strings for a few of the attribute
   types frequently seen in RDNs include:

                    String  X.500 AttributeType
                    ------------------------------
                    CN      commonName
                    L       localityName
                    ST      stateOrProvinceName
                    <snip>

This is not normative, and are included as examples, and although it
references X500, they are also used in examples in those series of
documents.

Thanks. I appreciate all the feedback!
We need to be careful about making any assumptions with these short names as
there seems to be no normative text defining them. Is there a need to
recommend a standard way of using these short names (where discrepancy
exist)?

Vivian

Vivian

---

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 22 May 2001 13:06:51 +1000

X.500 uses object identifiers, not strings. Therefore, there is no
'normative' definition of the attribute names. LDAP generally uses string
names for attributes. The names reflect those used in the X500 documents.
Many definitions are given in RFC 2256.

Ron

-----Original Message-----
From: Vivian Cancio [mailto:[email-masked]]
Sent: Tuesday, 22 May 2001 8:18
To: [email-masked]'; 'Frank Balluffi'
Cc: [email-masked]
Subject: RE: C=country; just a convention?

Vivian

Vivian