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

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 05 Aug 2010 14:58:45 -0600

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 05 Aug 2010 15:03:12 -0600

On 7/19/10 10:12 AM, Martin Rex wrote:

> One thing that I find particularly irritating in -08 is that
> it completely ignores a much more secure authentication
> scheme for servers, by clients knowing the entire subject DName
> of a certificate rather than matching only a single
> name component.

Good point.

To make these (and other) matters clearer, I have written a new section
on the applicability of this document:

***

1.2.  Applicability

   This document does not supersede the rules for certificate validation
   provided in [PKIX]; specifically, in order to ensure proper
   authenticationm application clients need to verify the entire
   certification path (this document addresses only the DNS domain name
   of the application service itself, not the entire trust chain).  This
   document also does not supersede the rules for verifying server
   identity provided in existing application protocol specifications,
   such as those mentioned under Appendix A.  However, it is the intent
   of the authors that the best current practices described here can be
   referenced by future specifications.  It is also expected that this
   document will be updated or obsoleted in the future as best practices
   for issuance and verification of PKIX certificates continue to evolve
   through more widespread implementation and deployment of TLS-
   protected application services over the Internet.

***

/psa