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

From: =JeffH <[email-masked]>
Date: Tue, 11 May 2010 16:47:43 -0700

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

Thanks very much for this detailed heads-up.

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

Ah, this (i.e. "the result") would be the resultant DN string representation as 
spec'd by RFC4514 section 2.2.

 > 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

Ok, thx, good catch.

AFAICT, this revelation means we have some re-working to do to 
-tls-server-id-check in sections 2.1 and 3.1.3 in order to denote that RDNs can 
  contain a set of AVAs.

 > Btw. the XMLdsig guys actually recommend an additional restriction
 > on top of rfc4514:
 >
 >   http://www.w3.org/TR/xmldsig-core/#dname-encrules

this item seems to be an escaping of (apparent) ASCII control chars when 
rendering a DER encoded DN as a DN string representation, yes?  And it is a 
MAY-level requirement in the XMLdsig spec.

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

Ok, although I'm unsure how this might affect the -tls-server-id-check spec.

thanks again,

=JeffH

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 12 May 2010 09:35:00 -0600

On 5/11/10 5:47 PM, =JeffH wrote:
> Ah, this (i.e. "the result") would be the resultant DN string
> representation as spec'd by RFC4514 section 2.2.
> 
> 
> -tls-server-id-check in sections 2.1 and 3.1.3 in order to denote that
> RDNs can  contain a set of AVAs.

Is this text more accurate?

   The subject field of a PKIX certificate is defined as a X.501 type
   Name and known as a Distinguished Name (DN) -- see [X.501] and
   [PKIX].  A DN is an ordered sequence of Relative Distinguished Name
   (RDNs), where an RDN is a set (i.e., an unordered group) of type-and-
   value pairs [LDAP-DN], each of which asserts some attribute about the
   subject of the certificate.

Where [LDAP-DN] = RFC 4514 and [PKIX] = RFC 5280.

BTW I don't see any evidence for the following claim in RFC 4514:

   The RDNs are ordered in the DN sequence from
   most general to most specific.

Corrections welcome.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/