On Tue, Jun 24, 2014 at 12:23:57AM +0200, Martin Rex wrote:
> 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. :)
You're welcome. My expectation is that in most cases, servers that
support both X.509 certs and bare keys, will simply use the keys
embedded in their certs as their bare keys, and the issue will be
moot.
> This is the missing guidance for the server admin that I talked about.
However, explicit guidance would not be out of order.
> 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.
Yes, this is intentional. Fortunately, we have a TLSA RRset, rather
than a single RR, to work with and it is possible to public
simultaneous associations for multiple "key material" objects.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
