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

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Jun 2010 17:10:48 -0700

>       However, if this
>       legacy identifer configuration is employed, then the server's
>       fully-qualified DNS domain name MUST be placed in the last (most
>       specific) RDN within the RDN sequence making up the certificate's
>       subjectName, as the order of RDNs is determined by the DER-
>       encoded Name within the server's PKIX certificate.

I always get this wrong, so I assume people less familiar with PKIX do as well. Before you say "(most specific)" as if it was a toss-off, you should define "most specific RDN" as "the last RDN within a sequence", probably in section 1.3.

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 29 Jun 2010 16:07:07 -0600

On 6/11/10 6:10 PM, Paul Hoffman wrote:
>> However, if this legacy identifer configuration is employed, then
>> the server's fully-qualified DNS domain name MUST be placed in the
>> last (most specific) RDN within the RDN sequence making up the
>> certificate's subjectName, as the order of RDNs is determined by
>> the DER- encoded Name within the server's PKIX certificate.
> 
> I always get this wrong, so I assume people less familiar with PKIX
> do as well. Before you say "(most specific)" as if it was a toss-off,
> you should define "most specific RDN" as "the last RDN within a
> sequence", probably in section 1.3.

Two questions:

1. Some people use "most significant" and "most specific"
interchangeably. Which is correct?

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? I
realize that the first one now will later be last [1] depending on the
string representation, but my understanding is that in the DER encoding
it's the first RDN that is most specific. Corrections are welcome.

/psa

[1] http://www.bobdylan.com/#/songs/the-times-they-are-a-changin

---

From: Bruno Harbulot <[email-masked]>
Date: Tue, 29 Jun 2010 23:31:04 +0100

> it's the first RDN that is most specific. Corrections are welcome.

I've always understood (perhaps by mistake) that the most specific was 
the last in the sequence. This also seems to reflect going "deeper" in 
the LDAP tree.

For example, (from www.google.com:443), the Subject DN is:

  156  104:     SEQUENCE {
  158   11:       SET {
  160    9:         SEQUENCE {
  162    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
  167    2:           PrintableString 'US'
          :           }
          :         }
  171   19:       SET {
  173   17:         SEQUENCE {
  175    3:           OBJECT IDENTIFIER stateOrProvinceName (2 5 4 8)
  180   10:           PrintableString 'California'
          :           }
          :         }
  192   22:       SET {
  194   20:         SEQUENCE {
  196    3:           OBJECT IDENTIFIER localityName (2 5 4 7)
  201   13:           TeletexString 'Mountain View'
          :           }
          :         }
  216   19:       SET {
  218   17:         SEQUENCE {
  220    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
  225   10:           TeletexString 'Google Inc'
          :           }
          :         }
  237   23:       SET {
  239   21:         SEQUENCE {
  241    3:           OBJECT IDENTIFIER commonName (2 5 4 3)
  246   14:           TeletexString 'www.google.com'
          :           }
          :         }
          :       }

I think most I've seen follow this naming structure: country first and 
CN last. Intuitively, this seems to suggest that the first in the 
sequence is the least specific and that the last in the sequence is the 
most specific, if we use this terminology. (Is this correct?)

Best wishes,

Bruno.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 29 Jun 2010 17:17:28 -0700

>it's the first RDN that is most specific. Corrections are welcome.

This paragraph shows why it is crazy to assume that developers understand this.

First: if the RDN is a sequence, then whether it is encoded in DER or BER is irrelevant. The difference in the two encodings is only relevant for SETs.

According to RFC 5280:
   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

   RelativeDistinguishedName ::=
     SET SIZE (1..MAX) OF AttributeTypeAndValue

However, RFC 5280 does not say which of the sequence is "most specific".

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 30 Jun 2010 07:07:01 +0200

> This paragraph shows why it is crazy to assume that developers understand this.
To me it only shows missing understanding of one person.

'this' refers to what? The the in this draft or rfc 5280?

> However, RFC 5280 does not say which of the sequence is "most specific".
IMO it is not exactly best place but at the end of paragraph 7.1 there is:

    "A distinguished name DN1 is within the subtree defined by the
    distinguished name DN2 if DN1 contains at least as many RDNs as DN2,
    and DN1 and DN2 are a match when trailing RDNs in DN1 are ignored."

Given a natural interpretation of tree and subtree, one can deduce
that the "highest" RDN is the first, or the most specific is the last.

But since this is so nicely hidden, a reminder seems useful.

---

From: Kaspar Brand <[email-masked]>
Date: Wed, 30 Jun 2010 08:12:42 +0200

> 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.).

> 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, 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)

(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".)

Kaspar

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 30 Jun 2010 06:48:00 -0700

> interchangeably. Which is correct?

This is bad.  Most significant and most specific are not interchangeable terms.  Most significant refers to the RDN with the greatest value.  That is, the RDN which is nearest the root of the naming tree.  The most specific RDN refers to the RDN which is deepest in the tree, the RDN that is composed of AVAs which distinguish the relative name within a subtree.

In the DN <cn=Kurt Zeilenga,cn=users,o=Example> (using RFC 4513 notation), o=Example is the most significant (e.g, RDN with the greatest value),  and cn=Kurt Zeilenga is the most specific (RDN which is most specific in describing the named object).

>   significant to most significant.

One could replace 'least/most significant' here with 'most/least specific'.

Regards, Kurt

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 30 Jun 2010 18:23:45 +0200

> One could replace 'least/most significant' here with 'most/least specific'.
+1  significant is a bad term in this context IMO according to W&M:

*1* *:* having meaning; /especially/ *:* suggestive 
<http://www.merriam-webster.com/dictionary/suggestive> <a significant 
glance>
*2 a* *:* having or likely to have influence or effect *:* important 
<http://www.merriam-webster.com/dictionary/important> <a significant 
piece of legislation>; /also/ *:* of a noticeably or measurably large 
amount <a significant number of layoffs> <producing significant profits> 
*b* *:* probably caused by something other than mere chance 
<statistically significant correlation between vitamin deficiency and 
disease>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 30 Jun 2010 11:41:23 -0600

On 6/30/10 12:12 AM, Kaspar Brand wrote:
> 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
> 

Done, thanks.

> 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/

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Jun 2010 19:46:18 +0200 (MEST)

>    the "most specific" RDN.  See [LDAP-DN] for details.

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?

-Martin

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 30 Jun 2010 11:51:54 -0600

> 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.

Peter

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

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 30 Jun 2010 13:51:59 -0700

> we can remove any mention of it.

Peter,

Can you please add a DER encoded Name, the asn1parse/dump version of the name, and the LDAP version of string and annotation what the different parts are called, this confuses me every time I try to in parse the rfc's and drafts.

Thanks
Love

> _________

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 30 Jun 2010 15:56:29 -0600

On 6/30/10 2:51 PM, Love Hörnquist Åstrand wrote:
>>>> Based on feedback from you and from Kurt, I have changed the
>>>> foregoing paragraph to:
>>>> 
>>>> 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.
>>> 
>>> 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.
> 
> Peter,
> 
> Can you please add a DER encoded Name, the asn1parse/dump version of
> the name, and the LDAP version of string and annotation what the
> different parts are called, this confuses me every time I try to in
> parse the rfc's and drafts.

I'm still just learning about all of these different terms, formats,
versions, and representations. And yes it is quite confusing. Perhaps
I'll ask one of the co-editors or contributors to come up with a good
example as you have requested...

Peter

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