On Thu, May 29, 2014 at 12:59:06PM -0400, Paul Wouters wrote:
> >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?
Per John's note, the existing RFCs specifically exclude bare SPKI,
though otherwise I agree, the mapping is fairly natural/obvious.
> >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.
The server will indeed have full certs and corresponding or
independent bare keys. However all the TLSA RRs MUST be "3 1 X"
RRs (matching all the deployed certificates and public keys),
or else clients MUST NOT indicate support for "oob public key".
The point being that the client does not know which TLSA RRs are
"live" and which are "legacy" as a result of key rotation. If all
the "3 1 X" records are legacy, and only "3 0 1" or "2 0 1" RRs
are "live", the client will fail to authenticate the server if it
learns only the public key of the live leaf certificate.
A client that negotiates "oob public key" can only learn the
server's leaf SPKI, so this needs to be sufficient to perform
authentication, which is only true when *all* the authentication
records are "3 1 X".
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
