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

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
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure