> 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
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
