Kaspar Brand wrote:
>
> In section 4 ("Verification of Server Identity"), however, I think we
> should expressly put an end to the debate of what "(most specific)" in
> RFC 2818 really means, otherwise the confusion is perpetuated.
I would prefer to stick with the _exact_ description of rfc-2818.
After all, this method has been deprecated back then and is intended
to remain deprecated.
> Of the two solutions - either explain at great length how it is to be
> understood DER-encoding-wise, or just go loop over all CNs -, the latter
> definitely seems preferrable to me.
RFC2818 is likely a specification looking backwards, trying to describe
the current practice and the behaviour of existing implementations.
A lot of TLS clients and most web browsers had been checking only
one single CN-ID when RFC-2818 was written (and still do), and
the "most specific" is likely the attempt to indicate which
CN-ID they are checking.
To me it sounds like the first match on a string search based on the
reversed ordering in "String Representation of Distinguished Names"
(rfc2253 as far as rfc2818 is concerned, which has since been
obsoleted by rfc-4514).
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
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
