Re: [keyassure] TLSA record does not mandate the given certificate

I actually really disagree with the idea that DANE would be some parallel, alternative path to PKIX validation.  If DANE is going to be meaningful, it needs to be able to cause the TLS handshake to fail -- this is the correct behavior when the server says (through DANE) that things should be one way and they aren't.

The relationship between DANE and PKIX is one of the topics for discussion at the DANE meeting tomorrow.  As I'll present (in a discussion too long for this email), they can actually work together very naturally.

--Richard

On Mar 29, 2011, at 10:34 AM, Paul Wouters wrote:

> On Tue, 29 Mar 2011, Jay Daley wrote:
> 
>> Two questions:
>> 
>> 1.  How is the current text in 3. not good enough?
>> 
>> "If a match between one of the certificate association(s) and the
>>  server's end entity certificate in TLS is found, the TLS client
>>  continues the TLS handshake.  If no match between the usable
>>  certificate association(s) and the server's end entity certificate in
>>  TLS is found, the TLS client MUST abort the handshake with an
>>  "access_denied" error."
> 
> I am assuming we will see deployment of DANE and PKIX alongside,
> where there might be contradictions or discrepancies between these two
> (or even other methods of obtaining this information out of band). I
> think what should be stated is that the "DANE validation path" should
> be aborted. We should not dictate to abort the TLS handshake. It would
> be up to a client/browser to implement one or more trust anchor methods
> (PKIX, DANE, LDAP, caching) and decide to abort the TLS handhshake only
> after all its trusted methods have failed.
> 
> Paul
> 
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure