Re: [keyassure] The draft and subj alt names

[=JeffH <Jeff.Hodges at KingsMountain.com>]

On Mar 31, 2011, at 12:05 PM, Olle E. Johansson wrote:

> I have read the draft and reacted to one thing. Sorry if this already have 
been discussed on the list.
>
> The draft -06 says
> "The end entity certificate from TLS, regardless of whether it was
>   matched with a TLSA type 1 certificate or chained to a TLSA type 2 CA
>   certificate, must have at least one identifier in the subject or
>   subjectAltName field of the matched certificates matches the expected
>   identifier for the TLS server. "
>
> The new RFC 6125 tells us that we should:
> "Move toward including and checking even more specific
>      subjectAlternativeName extensions where appropriate for using the
>      protocol (e.g., uniformResourceIdentifier and the otherName form
>      SRVName)."
>


"Richard L. Barnes" <rbarnes at bbn.com> replied on Thu, 31 Mar 2011 13:12:32 +0200..
>
> As I've said in other threads, this WG should be silent on requirements for
> certificate names, since different applications use TLS certificate names in
> different ways.


+1 to what Richard says.

The RFC6125 (aka "TLS Server Identity Check") text quoted by Olle is a 
suggestion to _applications_ to move away from CN-ID and towards leveraging 
SubjectAlternativeName (SAN) name types in terms of the identifiers embedded in 
certs and checked against _at the app layer_ during TLS connection establishment.

I think that Richard is correct that what the DANE WG is designing lies "below" 
the applications, and it is still their job to ascertain whether the name(s) 
embedded in the cert used to secure the connection meaningfully match the 
intended server. Please see sections 1 and 2 of RFC6125 for an in-depth 
discussion of the nuances.

HTH,

=JeffH