On Tue, Apr 16, 2013 at 03:50:23PM -0700, Jim Schaad wrote:
> Such a certificate could be pre-configured.
I am reading this to mean that in some small-scale deployments,
where the set of clients is fully anticipated by the server operator,
there exists an opportunity to publish TLSA "2 x [12]" without the
TA cert in the server's chain, if all the clients are pre-configured
with a copy of the TA certificate.
This may to some extent be true, but it now obligates clients to
try to extend the server's chain with usage 2, which may be difficult
in implementations that only do chain extensions as part of PKIX
validation to a trusted root. If the TA is present in the server's
chain, implementation of usage 2 verification is much more natural,
just locate the TA in the server's chain. So even if the client
"could" in principle locate the missing certificate, it is not
clear that it should be required to try as this may not be easy
with at least some of the popular toolkits.
The simplest and most robust way to "pre-configure" the clients to
validate the server's chain even in our hypothetical small-scale
deployments is to include the trust anchor in the server's certificate
chain. No other pre-configuration mechanism scales to the public
Internet, and the procotocol specified in 6698 is not restricted
to small-scale deployments.
I may yet enable "2 x [12]" verification by default, in the hope
that server operators will do the right thing despite lack of
normative language, but I am hoping that some helpful language will
be added to the RFC.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
