Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06)

["Richard L. Barnes" <[e-mail]>]

The milestone reads:
"
April 2011 - First WG draft of standards-track protocol for using DNS to associate hosts with keys for TLS and DTLS
"
So no, not updating 2818, 3207, etc.

The upshot of this naming discussion is that nothing that touches names is going to be general to TLS and DTLS.  So if you want to update 2818 to use DANE for name matching, you'll have to do it in a separate document, either as a new DANE milestone or (more likely) in TLS.  

--Richard



On Mar 30, 2011, at 10:14 PM, Jay Daley wrote:

> 
> On 31/03/2011, at 9:03 AM, Richard L. Barnes wrote:
> 
>> Nope, it's up to applications.  If you want SN/CAN *not* to be checked for HTTPS, then you need to go revise RFC 2818; for SMTP, RFC 3207; for IMAP/POP3, RFC 2595.
> 
> Indeed.
> 
> I assumed we were updating RFC 2818.
> 
> As for RFC 3207 that says this gem, which is as much use as a chocolate teapot and so will need updating:
> 
> -  A SMTP client would probably only want to authenticate an SMTP
>   server whose server certificate has a domain name that is the
>   domain name that the client thought it was connecting to."
> 
> And RFC 2595 is going to need updating because the name check is specific:
> 
>   - The client MUST use the server hostname it used to open the
>     connection as the value to compare against the server name as
>     expressed in the server certificate.  The client MUST NOT use any
>     form of the server hostname derived from an insecure remote source
>     (e.g., insecure DNS lookup).  CNAME canonicalization is not done.
> 
> Jay
> 
>> 
>> --Richard
>> 
>> 
>> 
>> On Mar 30, 2011, at 9:45 PM, Jay Daley wrote:
>> 
>>> I would argue the complete opposite - that it is in scope for DANE to state that names in certificates should not be checked because the trust chain has been provided by DNSSEC.  Doing that allows individuals and organisations to reuse certificates as they need to for operational reasons and not as dictated to by suppliers or paranoid protocol developers.
>>> 
>>> Jay
>>> 
>>> On 31/03/2011, at 12:55 AM, Richard L. Barnes wrote:
>>> 
>>>> This is outside of DANE's scope.  Checking of names in certificates is up to the application that uses TLS.
>>>> --Richard
>>>> 
>>>> 
>>>> On Mar 30, 2011, at 1:19 PM, Stephen Kent wrote:
>>>> 
>>>>> At 11:14 AM +0200 3/30/11, Peter Palfrader wrote:
>>>>>> On Mon, 21 Mar 2011, Paul Hoffman wrote:
>>>>>> 
>>>>>>> On Mar 21, 2011, at 6:04 AM, Peter Palfrader wrote:
>>>>>>>> Why is it needed in the first place?
>>>>>>> 
>>>>>>> That's a very good question. I don't feel that it is a "need", but it
>>>>>>> "makes some sense". That is, if I want to go to www.example.com, and I
>>>>>>> get an A record for www.example.com, and I get a TLSA record for
>>>>>>> _http._tcp.www.example.com, and I get a certificate that says "this
>>>>>>> key is associated with www.somethingelse.com", what does it mean?
>>>>>>> 
>>>>>>> I can see both ways: "it doesn't matter what the cert says, we are
>>>>>>> trusting the binding from the DNS" vs. "the cert needs to mean
>>>>>>> something"? Jakob and I have that text in because a number of people
>>>>>>> on the list were in the latter category, but it seems like a
>>>>>>> reasonable question to ask separately.
>>>>>> 
>>>>>> I wonder if one approach here would be to require a match if, and only
>>>>>> if, any naming attributes (CN, SubjectAltName) are in the certificate.
>>>>>> 
>>>>>> If there are no CN and no SAN attributes in the certificate then that
>>>>>> would be acceptable too.
>>>>>> 
>>>>>> Cheers,
>>>>>> Peter
>>>>> 
>>>>> A CN is a type of attribute in the Subject DN.  A SAN admits a variety of name types, some of which can have attributes. Do you mean to focus on DNS names as SANs or did you have a broader range of SANs in mind?
>>>>> 
>>>>> Steve
>>>>> _______________________________________________
>>>>> keyassure mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>>> 
>>>> _______________________________________________
>>>> keyassure mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>> 
>>> 
>>> -- 
>>> Jay Daley
>>> Chief Executive
>>> .nz Registry Services (New Zealand Domain Name Registry Limited)
>>> desk: [phone]
>>> mobile: [phone]
>>> 
>> 
> 
> 
> -- 
> Jay Daley
> Chief Executive
> .nz Registry Services (New Zealand Domain Name Registry Limited)
> desk: [phone]
> mobile: [phone]
>