> On May 16, 2017, at 11:36 AM, Kathleen Moriarty
> <kathleen.moriarty.i...@gmail.com> wrote:
>
> OK, does that put us back to the suggested wording:
>
> "TLS depends on certificate path validation, and a conformant
> TLS implementation MUST implement certificate paths validation
> in a manner that achieves the same result as [RFC5280]. This
> section provides TLS-specific requirements.”
>
> For any developers following, does this help enough with any
> interoperability questions?
TLS does not depend on certificate path validation. Many TLS
*applications* rely PKIX certificate path validation (along with
RFC 6125 server identity verification), but TLS itself supports
various alternative authentication (and non-authentication) modes.
* PSK or SRP without certificates
* Opportunistic unauthenticated TLS (perhaps anon-(EC)DH with TLS <= 1.2)
* TOFU public key pinning
* Static leaf key or leaf cert matching
* RFC7250 raw public keys
* DANE-EE(3) leaf certificate/key verification, without expiration
or server name checks
* DANE-EE(3) ... with name checks (where UKS attack are relevant)
* DANE-TA(2) with RFC5280 chain verification, but the trust-anchor
is part of the chain, and identified via DNS TLSA records.
* PKIX-EE(1) which is RFC5280 + DANE leaf cert "constraint"
* PKIX-TA(0) which is RFC5280 + DANE CA "constraint"
Keeping in mind that many implementations of RFC5280 violate that specification
by interpreting EKUs in CA certificates to constrain the kinds of certificates
that the CA may issue. That de-facto usage is I think much more widely
implemented
than the far too complex X.509 policy constraints (RFC5280 4.2.1.11).
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
