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
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
