On Sat, Mar 23, 2013 at 05:23:41PM -0400, James Cloos wrote:
> VD> Are servers that publish their trust anchor details via DNS in full:
> VD> _25._tcp.mail.example.com. IN TLSA 2 0 0 <DER cert in hex>
> VD> exempt from being obligated to provide the same certificate somewhere
> VD> in their trust chain?
>
> I had a probably too long answer written, but after reading the rfc a
> couple more times, and notwithstanding our early discussion here (some
> of which would have supported permitting elision), I've concluded that
> the text in ?2.1.1:
>
> ,----< 2 -- Certificate usage 2 ... >
> | 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.
> `----
>
> means that the cert has to be included in the tls startup negotiation;
> it cannot be elided.
I take it you read the phrase "with any certificate matching the
TLSA record... " to mean that such a certificate must come from
the server in the server SSL HELO. If I squint hard enough, I can
read it the same way, but I could also suppose that the PKIX
validation path in question was in part constructed by the verifier,
and so no explicit requirement for the server to provide the
certificate.
This should probably be spelled out more completely in an implementation
guideline section, or similar. The above is rather subtle.
Since of course with usage 2 there is no presumption that the verifying
client has the TA public key (or equivalently a certificate containing
it) already in hand, the requirement to include the certificate in the
trust chain should I think be more explicit.
At some noticeable complexity cost (though not a lot of lines of
code), I've added full support for "2 0 0" and "2 1 0" TLSA records,
so now I can verify trust chains that omit the corresponding issuing
certificate and begin with something signed by the TA.
> VD> I am also hoping that ... in practice all TLSA records will be
> VD> sha2 digests.
>
> Sha2 matches should be documented as the Best Practice for TLSA.
So at this point what I have is:
- Full support for "IN TLSA [13] x y ..." for all x, y.
- Full support for "IN TLSA [02] x 0 ..." for all x.
- Support for "IN TLSA 2 x [12] ..." for all x, provided it is clear
from the RFC that the server is obligated to include the TA
cert in its server SSL HELO (reply). If this is not clear,
then I might need to treat "IN TLSA 2 x [12] ..." as "unusable".
[ If mail to enough sites fails because domain owners are having
trouble creating a usable configuration, senders will not want
to enable DANE TLSA support. There should be no subtle traps
for domain owners publishing TLSA records. ]
If the RFC does not clearly require "IN TLSA 2 x [12] ..."
to mandate the TA cert in server's SSL HELO, then I'll have
to go with "2 x [12]" as "unusable".
- I likely have to treat "0 x [12]" as "unusable", because when the
TA in the association is a public root CA, they will typically
(common practice pre-DANE) not include the TA cert in their trust
chain. I cannot require Postfix MTAs to have every single public
CA in their CAfile, this is a non-starter. So "0 x [12]" will
fall back to mandatory TLS with no authentication.
I can only improve on qualified support for:
IN TLSA 0 0 1 - Trust anchor cert likely not available in server HELO
IN TLSA 0 0 2 - ...
IN TLSA 0 1 1 - ...
IN TLSA 0 1 2 - ...
IN TLSA 2 0 1 - Trust anchor cert in SSL HELO may not be RFC mandated
IN TLSA 2 0 2 - ...
IN TLSA 2 1 1 - ...
IN TLSA 2 1 2 - ...
if the RFC requires conforming server implementations to always
include the TA certificate in their SSL HELO (reply) trust chain.
I expect that progress on the "IN TLSA 2 x [12] ..." front is
possible, by clarifying the RFC text. I would guess that I'll find
resistance on the "IN TLSA 0 x [12] ..." front, so support for that
will likely not be available in Postfix.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
