-----Original Message-----
From: dane [mailto:[email protected]] On Behalf Of Viktor Dukhovni
Sent: Thursday, May 29, 2014 7:16 AM
To: [email protected]
Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public
keys
On Thu, May 29, 2014 at 01:05:17AM -0700, John Gilmore 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}
[JLS] That may be one obvious format. I think that an even better format
would be to define a new TLSA certificate type so that the client will know
that an OOB bare key is what is coming. Thus
; Match SPKI of a certificate or just the bare public key
_25._tcp.mx1.example.com IN TLSA DANE-BARE-KEY(4) SPKI(1) ? {blob}
This means that there is no overlap between those that are planning to do
PKIX and those that are planning to do bare keys both in the filtering of
the information and publishing of the data. Both could be offered, and the
DANE query would allow a client to know that OOB is going to be acceptable.
Jim
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).
--
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
