Re: [certid] Need to define "most specific RDN"

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

On 6/30/10 12:12 AM, Kaspar Brand wrote:
> On 30.06.2010 00:07, Peter Saint-Andre wrote:
>> Two questions:
>>
>> 1. Some people use "most significant" and "most specific"
>> interchangeably. Which is correct?
> 
> "most specific", I would say. And "correct" in the sense that it's the
> wording used in RFC 2818 (you won't find this term in X.501 in the
> section about names, e.g.).
> 
>> 2. More substantially, we currently have this text:
>>
>>    The subject field of a PKIX certificate is defined as an 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 Names
>>    (RDNs), where each RDN is a set (i.e., an unordered group) of type-
>>    and-value pairs or "attribute value assertions" (AVAs) [LDAP-DN],
>>    each of which asserts some attribute about the subject of the
>>    certificate.  In the DER encoding of a DN, the RDNs are always in
>>    order from most significant to least significant (i.e., the first RDN
>>    is most significant and the last RDN is least significant); however,
>>    in the string representation of a DN as used in various protocols and
>>    data formats, the RDNs might be ordered from most significant to
>>    least significant (e.g., this is true of LDAP) or from least
>>    significant to most significant.
>>
>> Is the first RDN most specific, or is the last RDN most specific?
> 
> The last (as stated by others already). If we want to be really picky
> with definitions, then
> 
>> where each RDN is a set (i.e., an unordered group) of type-and-value
>> pairs or "attribute value assertions" (AVAs)
> 
> isn't entirely correct. RFC 5280 actually defines
> RelativeDistinguishedName as a SET OF AttributeTypeAndValue (not a SET
> OF AttributeValueAssertion, these have a different syntax, cf. X.501).
> 
> I.e., drop "or 'attribute value assertions' (AVAs)" from the above
> definition, 

Based on feedback from you and from Kurt, I have changed the foregoing
paragraph to:

   Certificates are binary objects -- they are encoded using
   distinguished encoding rules (DER).  Thus, the generation of
   displayable (a.k.a. printable) renderings of certificate subject and
   issuer names means that the DER-encoded sequences are decoded and
   converted into a "string representation" before being rendered.
   Because a DN is an ordered sequence, order is preserved in the string
   representation of a DN.  However, because an RDN is an unordered
   group of attribute-type-and-value pairs, the string representation of
   an RDN can differ from the canonical DER encoding; in the canonical
   encoding, the RDN that is nearest to the root of the naming tree is
   called the "most significant" RDN and the RDN that is deepest in the
   tree (and that therefore distinguishes the relative name) is called
   the "most specific" RDN.  See [LDAP-DN] for details.


> and change the definition of CN-ID to
> 
>       *  CN-ID = a Relative Distinguished Name (RDN) in the certificate
>          subject that contains one and only one type-and-value pair
>          of type Common Name (CN)

Done, thanks.

> (On a somewhat related matter: when referring to subjectAltName entries
> - e.g. in Paul's message on "Empty subjects" - using the term AVA should
> be avoided, too. Simply use "a subjectAltName entry of type X".)

So:

   It is perfectly acceptable for a PKIX certificate to have an empty
   subject field as long as there is at least one subjectAltName entry.

Is that better?

Peter

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