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

[Paul Wouters <[e-mail]>]

On Thu, 29 May 2014, Viktor Dukhovni wrote:

>> In reviewing the draft, I noticed that it doesn't ever describe how
>> you store such a public key in a TLSA record.
>
> I think there is an obvious format, that should be spelled out
> explicitly in some suitable document.  Namely the same format as
> for the SPKI of a leaf certificate with any supported matching
> type:
>
>    ; Match SPKI of a certificate or just the bare public key
>    _25._tcp.mx1.example.com IN TLSA DANE-EE(3) SPKI(1) ? {blob}

Where is this not clear in the existing DANE RFCs?

> DANE TLS clients that also support the new TLS oob public key
> extension can include it in their client HELLO, provided every RR
> in the TLSA RRset is a "3 1 X" RR (they must perform the DNS lookup
> before client HELLO).  If any of the RRs have a different usage,
> then a full leaf certificate may be required, and the client MUST
> NOT signal oob public key support (since the client would potentially
> be unable to match a subset of the TLSA records, which may the
> currently active configuration).

Can you explain why that is needed? I would envison people to migrate
from full certs to bare keys to have both available in their TLS server
and in their TLSA record set.

Paul
> --
> 	Viktor.
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>