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

[Peter Saint-Andre <[e-mail]>]

On 5/11/10 5:47 PM, =JeffH wrote:
>> 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.

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/