We've previously agreed on cu=DANE-EE(3) obviating name checks,
since the TLSA base domain with port and protocol prefix is in fact
a more specific binding of the service end-point and public key
than any name in the certificate, and (perhaps more so) because
this dramatically simplifies virtual hosting.
In the OPs draft I went further and stated that verification of
the DANE-EE(3) end-entity certificate stops at matching it against
the TLSA record, and its content MUST otherwise be ignored. This
subsumes at least checks of the expiration date and also the EKU,
both of which are essentially superseded by the TLSA RR.
I may have gone a bit further than necessary. The main goal is to
make DANE authentication usable in protocols with no user to "click
OK". To this end I want to avoid the most common operational
failures with PKIX. Therefore I propose that:
- In addition to name checks, expiration checks also be
performed via the TLSA RR signature lifetime, rather than
the certificate expiration date. The TLSA record is updated
frequently as the DNSSEC zone is periodically re-signed. This
ensures that there are no surprise expirations. Certificates
can be replaced at the operator's convenience.
- Though the EKU is technically superseded by the TLSA RR type,
which implies a TLSA usage, getting this wrong would be
discovered immediately by the server operator, and quickly
fixed. There is no need to complicate implementations by
special-casing DANE EKU processing. Similarly with the key
usage, and other fields.
Therefore, the final proposal for DANE-EE(3) is that only name
checks and expiration checks are out of scope. This applies whether
the selector is Cert(0) or SPKI(1). However, when *all* TLSA records
are "IN TLSA DANE-EE(3) SPKI(1) ?", implementations that support the
proposed bare public key TLS extension, may signal that extension,
in which case if the server cooperates, in effect the rest of the
certificate is ignored (in fact never transmitted).
Any comments? Can the above be the final consensus on this topic?
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
