On Sun, Jun 01, 2014 at 10:04:13PM -0400, Tom Gindin wrote:
> On a technical, or at least quasi-technical point, doesn't usage 3 say
> that it must match the "end-entity certificate given by the server in
> TLS"?
Usage DANE-EE(3) with selector SPKI(1) matches the subject public
key info of the peer. While as specified in 6698 this SPKI is
expected to be adorned in X.509 finery, it is a natural extension
to allow the same association to apply to bare public keys.
There is simply no need for a new certificate usage here (one for
which selector 0 would make no sense). Indeed it would force
server operators to needlessly publish the SPKI digest twice:
example. IN TLSA 3 1 1 {blob}
example. IN TLSA 4 1 1 {blob}
for no good reason.
> Certificate usage 4 is used to specify a certificate, or the
> public key of such a certificate, that MUST match the public key given by
> the server in TLS or TLSA. Unlike certificate usage 3, this usage
> implies that the server supplies a key with neither validity dates nor
> name in the session negotiation.
Those qualifications already apply to usage 3 (ops draft document
which specifies this to be published soon), with SPKI(1), DANE-EE(3)
is already a bare key usage, just sometimes embedded in an X.509
cert. There is no need for a usage 4 (yet), at least not for this
use-case.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
