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/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
