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

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

On 7/19/10 10:13 PM, Shumon Huque wrote:
> On Mon, Jul 19, 2010 at 06:57:50PM +0200, Martin Rex wrote:
>> [...]
>> But frankly, I do no see much value in trying to describe all possible
>> interpretation of a fairly vague wording, that itself was an attempt
>> to characterize, NOT specify, what kind of behaviour there is in the
>> installed base.  Leaving the vague description of rfc-2818 as is,
>> and pointing out more prominently that it is really deprecated
>> should be perfectly sufficient.
>>
>> -Martin
> 
> I'm in full agreement.

I think this spec tries to further deprecate the "most specific" wording
from RFC 2818, but I've tried to amplify upon that in the implementation
note from Section 2.3, as follows:

      ... various specifications refer to the order of RDNs using
      terminology that is not directly related to the information
      hierarchy, such as "most specific" vs. "least specific", "left-
      most" vs. "right-most", "first" vs. "last", or "most significant"
      vs. "least significant" (see for example [LDAP-DN]).   To reduce
      confusion, in this specification we avoid such terms and instead
      use the terms provided under Section 1.4; in particular, we do not
      use the term "(most specific) Common Name field in the Subject
      field" from [HTTP-TLS] and instead state that a CN-ID is a
      Relative Distinguished Name (RDN) in the certificate subject that
      contains one and only one attribute-type-and-value pair of type
      Common Name (thus removing the possibility that an RDN might
      contain multiple AVAs of type CN, one of which would be considered
      "most specific").

/psa