On Mon, Apr 08, 2013 at 10:38:30PM +0000, Viktor Dukhovni wrote:
> 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?
Anyone??? Here, I just need to know whether I can reasonably expect
to be able to obtain the "2 x [12]" TA certificate whose digest
appears in a TLSA RR. With cert usage "2" I certainly can't expect
to find the CA certificate locally, and the digest function is not
invertible, so is the server obligated to provide it or not???
> 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
