On Tue, May 16, 2017 at 9:49 AM, Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote:
> On Tue, May 16, 2017 at 12:37 PM, Viktor Dukhovni > <ietf-d...@dukhovni.org> wrote: > > > >> 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). > > Sorry, I grabbed the wrong text as I was ineffective at multi-tasking. > I think we are back to the following text and would like to confirm > that and make sure it is agreeable to the WG and implementers: > > "In general detailed certificate validation procedures are out of > scope for TLS. [RFC5280] provides general procedures for > certificate validation. This section provides TLS-specific > requirements." > > Yeah, I think so. > There's also a thread that was discussing some interoperability > problems related to validation and I'd like to see the resolution for > that as well. > Matt has provided a PR for that that I'll be looking at this week. Thanks, -Ekr > Thanks, > Kathleen > > > > > -- > > Viktor. > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
