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
[email protected]
https://www.ietf.org/mailman/listinfo/dane
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
