On Tue, Mar 26, 2013 at 09:54:07PM +0000, Viktor Dukhovni wrote:
> What about the larger issue, how can I use "2 x 1" or "2 x 2" if
> the TA certificate is not required in the peer's chain? Or is it?
>
> How can I use "2 1 0" (waste of bits and all) if I must check
> "issued" rather than "signed"? Is the group tired of my questions?
Is my question not in scope for this group? Or perhaps does it
need to be asked in the narrower context of ietf-draft-dane-smtp, rather
than of RFC 6698?
I need to know whether:
- It is correct to expect that (SMTP?) servers with "IN TLSA 2 x [12]"
associations are obligated to include the full TA cert in their TLS
"certificate_list". (The latest Postfix DANE snapshot by default
treats "[02] x [12]" TLSA records as "unusable", the administrator
can configure support for either "2 x [12]", "0 x [12]" or both).
- 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 whether per the previous question,
the TA cert is required, and the issue is moot. (The latest Postfix
DANE snapshot goes to some lengths to implement 'signed by' for
"[02] 1 0". This is not configurable).
Both Postfix snapshot behaviours are predicated on the assumption
that SMTP clients cannot not rely on SMTP servers with TLSA "2 x y"
trust-anchor associations to present the associated TA certificates
in the TLS handshake "certificate_list" message.
Can 6698 be clarified to specify server behaviour wrt. to the above,
or does this need separate answers in the context of each application
(HTTP, SMTP, SIP, ...)?
My vote (if anyone is counting votes) is to require that TA certs
be provided in peer chains, at least for usage "2". And (at least)
in the context of draft-ietf-dane-smtp also for usage "0", alternatively,
the SMTP draft can relegate usage "0" to special-case intramural
use-cases, with no support for usage 0 with SMTP on the public internet.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
