On Thu, 29 May 2014, Viktor Dukhovni 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,
I think that's still up for discussion. But your above comment made it
appear you thought something else was missing, something about leaf
certificates and selector SPI?
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".
A client can indicate support for oob public key that is not based on
DANE.
The point being that the client does not know which TLSA RRs are
"live" and which are "legacy" as a result of key rotation.
Why does that matter? the client receives either the server's full
certificate or its 'bare key certificate'. It looks throug the list of
obtained TLSA records and looks if anything matches. It does not need
to prove every TLSA record is valid.
Also, all TLSA records are "live", and I don't understand your
terminology of "live" versus "legacy" at all.
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.
If the client only has a bare public key of the server and the TLSA record
is only "2 x x" the setup is broken. sure. Don't do that? If there is a
"3 x x" TLSA record, there is no issue.
If the client has the full public cert of the server, then any of the
certificate usage TLSA types could be used, and there is no issue.
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".
Why isn't only _one_ TLSA record of type "3 1 x" good enough? Why can't
the admin publish a "3 1 x" and a "1 x x" or "2 x x" ?
So you brought up John's point (which all centers around "can we call a
ASN.1 SPKI a 'certificate'") and a new issue which I completely don't
understand why it is an issue.
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
