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

[Kaspar Brand <[e-mail]>]

On 30.06.2010 19:51, Peter Saint-Andre wrote:
> On 6/30/10 11:46 AM, Martin Rex wrote:
>> I'm actually confused by refering to one end with "most significant" and
>> the other with "most specific".  Couldn't we just drop the "most significant"
>> entirely and use "least specific" / "most specific" for the two ends?
> 
> Given that we never use the term "most significant" in this I-D, I'd say
> we can remove any mention of it.

I would definitely recommend that.

It's still present in two places in -07, though:

> 2.2.  Subject Naming in PKIX Certificates
>
>    [...]                                            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.

>    3.1.3.  Server Identity Check
> 
>    [...]                                     For example, some X.500
>    implementations order the RDNs in a DN using a left-to-right (most
>    significant to least significant) convention instead of LDAP's right-
>    to-left convention.

After another look at X.501 and some of the LDAP RFCs (2247 in
particular), I'm getting to the conclusion that the "most specific vs.
most significant" distinction is actually a construct which mainly
originates from / applies to the DNS world - and through various RFCs
(among them 2818) somehow made its way into the PKIX world... but it
doesn't seem that for a "classic" X.500 DN there is really a notion of
"most/least specific". [1]

Section 2.2 in -07 also has

>    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 deepest in the tree (and that therefore
>    distinguishes the relative name) is called the "most specific" RDN.

I don't quite understand what you mean by "in the canonical    encoding,
the RDN that is deepest in the tree" - I think the second sentence is
about the (canonical) encoding of an RDN, and an RDN itself can't have a
"most specific" RDN, obviously...

In any case, using both "specific" and "significant" (and mixing in
"most" and "least") in the text is definitely confusing, as pointed out
by Martin. Let's stick to one, at most.

Kaspar


[1] Re-reading section 3.1 in RFC 2818 can actually confirm this
hypothesis, under the following interpretation: "the (most specific)
Common Name field in the Subject field of the certificate MUST be used"
can be understood to mean the domain name which has the highest number
of DNS labels: if the subject has CN=foo.example.net and CN=example.net,
then the first one must be used for the identity check (it's more
specific than CN=example.net), irrespective of its position in the DER
encoded subject, actually.