I would consider the case of using one of the VeriSign roots certificates as the TA certificate to be widely pre-configured and therefore would not think that there is a big problem.
Jim > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Viktor Dukhovni > Sent: Tuesday, April 16, 2013 4:20 PM > To: [email protected] > Subject: Re: [dane] Certificate usage 2 and TLS server certificate_list? > > 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 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
