Such a certificate could be pre-configured. Jim
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Viktor Dukhovni > Sent: Tuesday, April 16, 2013 3:21 PM > To: [email protected] > Subject: Re: [dane] Certificate usage 2 and TLS server certificate_list? > > On Tue, Apr 16, 2013 at 11:00:01PM +0200, Jakob Schlyter wrote: > > > On 16 apr 2013, at 16:52, Viktor Dukhovni <[email protected]> > wrote: > > > > > Does either RFC 6698, or draft-ietf-dane-srv mandate (or it is too > > > obvious to state in either standard) that: > > > > > > - Servers with "IN TLSA 2 x [12]" associations are obligated to include > > > the full TA cert in their TLS "certificate_list". > > > > I believe that is the case. RFC 6698 says: "The target certificate > > MUST pass PKIX certification path validation, with any certificate > > matching the TLSA record considered to be a trust anchor for this > > certification path validation." It is not possible to do path > > validation without having the full trust anchor certificate, thus the > > server needs to provide it in most cases. If it is not provided, and > > the client does not have its own copy, validation will fail. > > Thanks for responding, very much appreciated. Somehow we're still not > talking the same language. I understand and agree that the logical > consequence---when the certificate is not provided---is that validation will > generally fail. What I don't see anywhere is the statement in the specification > that: > > - A server with "2 x [12]" TLSA RRs MUST therefore provide the > certificate in question in its server certificate_list. > > Is the server obligated to do this, or not? Where is the normative text? Can I > enable support for "2 x [12]" by default, or should I expect to see a high > failure rate if I do (with no explicit support from the specification to compel > the servers in questions to provide the missing certificate)? > > > > - It is correct to read "IN TLSA 2 1 0" as validating chains "signed by" > > > (not known whether issued by) the TA, when the TA cert itself is not > > > available in the peer's chain. Or, per the previous question, is the > > > TA cert is required, and the issue is moot. > > > > Given that you need to do path validation, I believe the TA cert is > > required. In the case of "IN TLSA 2 1 x" or "IN TLSA 2 0 {1,2}, the > > server has to provide the certificate or the client has its own copy. > > I continue to be puzzled by the "or the client has its own copy". > The protocol has to work for all clients, not just some clients, that happen to > have their own copy. That happenstance is not a basis for interoperability of > the specification. > > Does 6698 certificate usage 2 require interoperable settings on servers? I > don't see the language that states this. Is it to be inferred, or should it be > explicit. > > If I enable default support for "2 1 [12]" RRs in SMTP clients, then this support > will be on for *all* servers, and mail delivery from Postfix SMTP clients will > break to any SMTP servers that don't provide the TA cert. This would not be a > good outcome for anyone. > > I've submitted an erratum to the RFC editor, perhaps this will resolve/clarify > the issue. With any luck I'll be able to ship Postfix with support for all "2 x y" > TLSA RRs enabled by default. > > -- > 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
