Viktor Dukhovni wrote:
>
> 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.
Thank your for agreeing with me. :)
This is the missing guidance for the server admin that I talked about.
You can not make a DANE/TLSA-aware TLS client that does not support
bare keys at the TLS protocol level, to *not* try matching SPKI TLSA
records to certs exchanged at the TLS protocol level, because it
is not possible to mark an SPKI selector as applying only to bare keys.
-Martin
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
