Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03

From: Martin Rex <[email-masked]>
Date: Wed, 12 May 2010 00:47:30 +0200 (MEST)

Jeff Hodges wrote:
>
> > The various standards for translating a DER encoded Name into
> > a string call for the RDNs to be ordered, left to right, from
> > most specific to most general, the reverse of the order in which
> > they appear in the DER encoded certificate.
>
> AFAICT, there is only one clear non-implementation-specific
> specification for a X.500/LDAP DN string representation,
> and that's (now) RFC4514 (obsoletes 2253, which obsoleted 1779,
> which obsoleted 1485). Is there a DN string rep specified
> anywhere in the ISO specs (I can't find one)?

The description above oversimplifies the process.

In ASN.1 a distinguished name is a sequence of RDNames, which are
sets of attribute-value pairs.  Often these sets only contain a
single attribute value pair, but they _can_ contain several
attribute value pairs, and some CA software seems to stuff
serialNumber and CN into a single RDName set.

The result is a little weird.  Multiple attribute-value pairs
in a set are glued together with a plus (+) sign instead of a
comma (,) and the original ordering of the set is retained!
(where as the ordering of the RDName elements is reversed).

Further complicating the issue: While DER encoding leaves the ordering
of the contents of an ASN.1 SEQUENCE as is, the ordering of the contents
of an ASN.1 SET is "canonicalized" by DER encoding (based on the
numeric ordering of the final binary encoding of each element).
So the shorter elements will always end up first in RDNames
containing multiple attribute-value pairs in a SET.

i.e.

     CN=Foo+2.5.4.5=123ABC,O=bar,C=ZZ
     2.5.4.5=227DEF+CN=LongName,O=bar,C=ZZ

Btw. the XMLdsig guys actually recommend an additional restriction
on top of rfc4514:

  http://www.w3.org/TR/xmldsig-core/#dname-encrules

One area that may create slight interop problems with some legacy software
is the printable attribute label used for certain attributes.

   rfc4514
   SN=        2.5.4.surname(4)
   2.5.4.5=   2.5.4.serialNumber(5)
   ST=        2.5.4.stateOrProvince(8)

The string representation also does not carry through the
"simple type" used in the original ASN.1 DER encoding
(like PrintableString,IA5String,UTF8String,BMPString).

-Martin