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

[=JeffH <[e-mail]>]

 > 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