Subject: Re: [TLS] [dane] #13: Server name check for certificate type 1

From: Paul Wouters <[email-masked]>
Date: Tue, 8 Nov 2011 17:11:44 -0500 (EST)

On Tue, 8 Nov 2011, Richard Barnes wrote:

> That is the correct behavior.  The name matching algorithm is not a TLS-layer issue, but an application-layer one.
> "
>   Some specifications for applications that run under TLS, such as
>   [RFC2818] for HTTP, require the server's certificate to have a domain
>   name that matches the host name expected by the client.  Some
>   specifications such at [RFC6125] detail how to match the identify
>   given in a PKIX certificate with those expected by the user.
> "

That will require an update anyway for http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01

Perhap this update needs to be made explicit in that draft to reflect this change. However, it would be nice if
we did not have to force people to use raw pubkeys if they do not want to maintain a subjectAltname= list in their
certificates but still want to take advantage of PKIX validation.

Paul

>
>
> On Nov 8, 2011, at 11:10 AM, Zack Weinberg wrote:
>
>> On 2011-11-08 2:39 AM, dane issue tracker wrote:
>>> #13: Server name check for certificate type 1
>>>  This addressed in draft-ietf-dane-protocol-12 in Sections 2.1, 2.2, 2.3,
>>>  most of section 4 and Appendix B.
>>
>> I'm sorry I missed this when you sent out the call for comments.  I do not believe this issue has been adequately addressed in -12.  In particular, when the end-entity certificate matches a valid TLSA record but does NOT contain embedded name information matching the hostname under which the record was found, client behavior is unspecified.
>>
>> (It's possible that you think "pass PKIX validation" covers this case, but that term is ill-defined to the point where I think it needs to be eradicated from the spec.)
>>
>> (I was not able to resolve this issue in my rewrite because I don't know what the client *ought* to do in this circumstance, only that there needs to be a specified behavior.)
>>
>> zw
>> _______________________________________________
>> dane mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dane
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>