On Mon, Feb 17, 2014 at 06:15:33PM +0000, Viktor Dukhovni wrote:
So one of the important issues to be discussed in London (and of
course on the list) is the question of DANE TLSA records pre-empting
some or all of the content of the associated certificate:
> So I can live with a weaker requirement, if that settles the issue.
> With DANE-EE(3):
>
> - No PKIX signature verification. Covered by TLSA association
> data field, and in any case we don't have a trusted issuer
> whose signature can be checked. [ Obvious. ]
>
> - No name checks based on certificate content. Covered
> by TLSA (service, protocol, base domain) triple. [ Already agreed. ]
>
> - No expiration checks based on certificate content. Covered
> by TLSA RRset's RRSIG expiration time. [ Still under discussion. ]
>
> - No purpose checks based on extended key usage. Covered by
> TLSA RRtype. [ Still under discussion. ]
>
> [ ... ]
>
> Of the two "Still under discussion" fields, the expiration is by
> far the most important for the operational success of DANE. By
> far the most common problem is expired certificates, and with
> DANE-EE(3), we have an opportunity to eliminate this problem.
> There is no more expiration, rather TLSA records are withdrawn from
> DNS by the server operator once the certificate is no longer
> appropriate (for whatever reason).
So please think about this issue before the Thursday dane session,
and/or indicate your views on the list.
Related to this is the following observation:
With "IN TLSA DANE-TA(2) SPKI(1) ..." records, the end entity
server is free to modify any field in the TA certificate other
than its subject name, its public key and fields constrained
by the authority key identifier of the immediate child of the
TA in the chain. Since the end entity is then free to modify
the TA certificate (but anything below it), should/may the
content of such a TA certificate be mostly ignored?
In other words, should/may "IN TLSA 2 1 ?" be treated differently
from "IN TLSA 2 0 ?" with respect to the handling of the TA
certificate content, beyond the obvious difference of using either
the public key only, or the whole certificate to match the TLSA
record.
For example, Postfix effectively ignores everything in the TA
certificate other than the public key with "IN TLSA 2 1 1" (after
all the TLSA record told us to trust the public key), but not with
"IN TLSA 2 0 1".
Since it looks like workable DANE support will be in OpenSSL 1.0.2
(in beta, to be released "soon"), now is a good time to settle
these questions.
There are two slides in the SMTP + OPS talk for London on DANE-EE(3)
and DANE-TA(2) semantics.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
