Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys

["Simon Arlott" <[e-mail]>]

On Wed, June 4, 2014 03:55, Viktor Dukhovni wrote:
> On Tue, Jun 03, 2014 at 10:23:39PM -0400, James Cloos wrote:
> The onus to get this corner case avoided needs to be either on the
> client or on the server.  The client-side solution is simpler:
>
>     * Avoid "oob public key" negotiation when authentication is
>       via DANE and TLSA records may require a full certificate.

If at least one TLSA record is DANE-EE(3) then a full certificate
is not required for that record.

Why do you need to restrict the client behaviour when the other
currently defined record types are also present?

What is the intended behaviour of the oob-capable client when new
TLSA record types are defined? Do those records also cause it to
refuse to do OOB or does it ignore them?

-- 
Simon Arlott