> On Feb 21, 2018, at 10:57 AM, Shumon Huque <shu...@gmail.com> wrote:
>
> On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni <ietf-d...@dukhovni.org>
> wrote:
>
> Summary as I see it:
>
> * Mandatory DANE: MUST Refuse absence of TLSA RRs or failure
> of PKIX-TA(0) and PKIX-EE(1). Must fail when no TLSA RRs
> are cache and the server does not present the extension.
Just to clarify "failure of PKIX-TA(0) and PKIX-EE(1)" is intended to
consider failure to satisfy the usual PKIX verification requirements
for these certificate usages. Naturally, mandatory DANE can also be
satisfied via matching DANE-TA(2) or DANE-EE(3) or fail via broken
DANE-TA(2) or DANE-EE(3).
>
> * "Opportunistic DANE": MAY refuse failed PKIX-TA(0) and PKIX(1)
> if caching replies, and SHOULD attempt to refresh cache before
> expiration to reduce opportunity for downgrades. Non-caching
> clients don't really gain security by refusing valid PKIX on
> DANE failure, and MAY choose to continue.
>
> This seems reasonable to me too.
Here too, a client MAY choose to fail when the presented certificate
chain fails all the associated (cached or freshly obtained) DANE TLSA
records whether these are PKIX-TA/EE, DANE-TA/EE or some mixture.
The restricted focus on just PKIX-TA/PKIX-EE is not needed.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
