On Tue, Jun 24, 2014 at 12:00:27AM +0200, Martin Rex wrote:
> Viktor Dukhovni wrote:
> >
> > The underlying meaning of "DANE-EE(3) SPKI(1) ?" is unchanged, it
> > matches a leaf SPKI object in either form. There is no confusion.
>
> It will not be possible to use DANE only for bare keys and
> traditional PKIX _without_ DANE for certificate-based authentication,
> because DANE/TLSA-aware clients, that do not support bare keys in TLS,
> would encounter a DANE validation failure with the PKIX cert they get
> from the server.
This is simply not the case. The TLSA RRset contains multiple
records. If the server is designed to serve clients that employ
traditional X.509 handshakes (not just clients that do RPK), then
that server's TLSA RRset needs to include at least one TLSA RR that
matches the server's chain presented in its TLS "certitificate
message". Typically the same TLSA record:
_443._tcp.www.example.com. IN TLSA 3 1 1 {SPKI-SHA2-256-digest}
is sufficient to match both the bare key and the *same* key embedded
in an X.509v3 certificate. If for some reason the "bare" keys are
not available in certificate finery, the RRset needs to list multiple
values:
_443._tcp.www.example.com. IN TLSA 3 1 1 {crt-SPKI-SHA2-256-digest}
_443._tcp.www.example.com. IN TLSA 3 1 1 {rpk-SPKI-SHA2-256-digest}
Where the first record is for the leaf certificate and the second
is for the bare key, repeated as necessary for additional certs
and additional bare keys, with the usual transitional states for
key rollover.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
