Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys

[Viktor Dukhovni <[e-mail]>]

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.