On Wed, 4 Jun 2014, Viktor Dukhovni wrote:
(skip oob when somewhat likely to fail and the client implements use of PKIX
certs).
It's not "likely to fail" when there is an exising "3 1 x" TLSA record
published!
Since I'm wasting
money on the cert, full-cert clients might as well pkix verify it.
And trust one of the 600 (give or take a 100) CAs to not be compromised?
I would argue that if you are using oob, but also want compatibility
with classic X.509 certificates, you should use the same "3 1 x" record,
and ignore all pkix verification.
the only reason to pick something else is if you want the trust anchor
to be a CA and not an EE cert. In which case, why are you doing
oob+dane?
if one publishes "311" along with it, all the benefit is lost, and
there is no reason whatever to also publish the "2 0 1".
You can still pin to a single CA for "classic x.509" and pin to a pubkey
for "oob". But you are right in that it is only postponing the
inevitable administration that is needed to publish just TLS public keys
and not legacy CAs.
The only time use of "oob" is discouraged for clients
that support both "oob" and not, is when the transition mixes
(usable) TLSA usage/selector combinations.
Still don't see that :P
Even if all of the tlsas *are* 31x, there is no guarantee any will
match.
Now we're talking misconfiguration, that's the server's fault.
Leaves me puzzled even more about what you _are_ trying to convey as
the requirement for not mixing "3 1 x" and other types.
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
