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
