On Sat, Jun 25, 2022 at 10:13:28PM +0300, Yaron Sheffer wrote:
> My question was about identity validation, which is what 6125bis is
> about. So it's a subset of your second option, "validation of
> certificates". And yes, this boils to, are DANE-based EE certificates
> expected to adhere to the draft's requirements.
Yes, when the DANE TLSA certificate usages are:
* PKIX-TA(0) (trust-anchor constraint)
* PKIX-EE(1) (pkix with EE pinning)
* DANE-TA(2) (trust-anchor assertion)
But when the certificate usage is DANE-EE(3), then for some
application protocols (notably not HTTP) it is admissible to
ignore names and expiration in the certificate, because these
are more than adequately handled at the DNS layer.
> And the reason I raised this question is that the draft defines its
> own scope with these words:
>
> This document applies only to service identities that meet these
> three characteristics: associated with fully-qualified domain
> names (FQDNs), used with TLS and DTLS, and are PKIX-based.
Even DANE-TA(2) is "PKIX based" for validating all the certificates
below the trust-anchor. All that changes is the source of the trust
anchor from local to remote via DNS. Whether DANE-EE(3) also needs
to adhere PKIX-rules depends on whether UKS (Unknown Key Share) attacks
are a concern for the application in question or not.
> I wasn't sure whether "PKIX-based" should be interpreted to include
> DANE certificates.
It does for the majority of the certificate usages, but in practice
today DANE is primarily used with SMTP, and predominantly with
DANE-EE(3) TLSA records, in which case identity questions are settleda
at the DNS layer, and the presented identifiers in the certificate are
irrelevant.
If some point DANE is implemented at a large cloud provider for which EE
bindings are operationally unattractive, and that provider elects
DANE-TA(2) instead, then even in SMTP there may (at least by message
volume, if not domain counts) come a time when PKIX-style identity
rules dominate. This is already the case with MTA-STS of course.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
