> > > +1 > > > > Plus, this is for TLS, and in TLS, the server is required to present a > cert > > chain. So the situation cited in the erratum can't happen. > > This is false. There is no pre-DANE requirement for servers to > present a *complete* chain, they may for example omit the root CA, > since prior to DANE, the client always needed that on hand. >
Fair enough. But the upshot of this is that the server needs to EITHER: (1) Provide the cert in DANE, OR (2) Provide the cert in TLS So it is completely plausible for DANE to have a mode where only a hash of the cert is presented. As Paul notes, this is deployment guidance, not a gap in the DANE protocol. That said, it might be worth starting a document to collect deployment recommendations of this type. Especially if it were written by people actually deploying DANE :) --Richard > > > On Tue, Apr 16, 2013 at 04:17:09PM -0700, John Gilmore wrote: > > > I think it should be rejected. > > Note, the erratum only suggests requiring the server certificate > when the TLSA RR is a *digest*, so "2 0 0" and "2 1 0" were never > in scope. > > > > The issue is certificate usage "2", defining a new trust anchor. > > Via a digest of public key material. > > > To make a system interoperate with DANE-TLS clients when publishing > > TLSA records that specify usage 2, a server operator and domain > > administrator must: > > > > * Supply the entire trust anchor certificate in their TLSA record, > > specifying selector 0 (full certificate) and matching type 0 > > (exact match); or > > Not in scope for the erratum. > > > * Configure their TLS server to supply the relevant trust anchor > > certificate in the certificate list that it sends [the option > > that Mr. Dukhovni suggests]; or > > Correct. > > > * Supply the public key of the trust anchor in their TLSA record, > > specifying selector 1 (Subject Public Key Info) and matching type 0 > > (exact match), allowing any certificate(s) signed by the trust > anchor > > to be validated; or > > Not in scope for the erratum. > > > * Only interact with clients who already have a copy of the trust > > anchor certificate or public key. Some applications may be > > designed or configured to work only with a restricted set of > > clients. > > Then the specification should say so. That is, either the server > operator intends to *only* support pre-configured clients, or the > server operator MUST include the TA certificate in the server chain. > > My concern is that many server operators have a weak grasp of > cryptography, and may naively expect "2 1 1" or "2 0 1" to work, > since they specified the TA in their TLSA record, (surely that's > enough :-). > > > Any or all of these options are valid and will result in DANE-TLS > > interoperability. The erratum should be rejected. > > For SMTP prior to DANE, TLS is either never used or used > opportunistically, so the server operator will continue to receive > email from DANE-unaware clients for years to come. > > Not publishing the TA certificate is not an access control mechanism, > it just complicates client implementation even for clients that have > a copy of the TA certificate somewhere. > > Augmenting the server chain with TA certs by digest is rather > non-trivial as these can be anywhere in the chain, but OpenSSL, > for example, only stores self-signed roots in the trust store. > > Supporting out-of-band TA certificates is rather non-trivial. The > proposed language makes the protocol more robust and easier for > users to understand and implement correctly. > > -- > 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
