Just commenting on Section 4.2 …
>
> > 3. Section 4.2.
> >
> > "In general, detailed certificate validation procedures are out of
> > scope for TLS (see [RFC5280]). This section provides TLS-specific
> > requirements."
> >
> > I don't see an explanation of why it is out-of-scope. The reference
> > is just to RFC5280, which seems odd. I would expect the reference to
> > be to something that explains why it is out-of-scope.
I think the the separation of certificate path validation from the TLS protocol
is correct, but perhaps this can be explained differently. Perhaps the
approach should be that TLS depends upon certificate path validation as
described in RFC 5280.
> In general, TLS's policy (dating back to TLS 1.0) has been that the
> job of TLS is to carry the certificates and other authentication
> material but to leave it up to other parts of the system to
> interpret them. It's been a long time since that decision was made,
> but from my perspective, there are a number of major reasons:
>
> 1. Most of PKI processing (path construction, etc.) is generic and
> not specific to TLS. What is specific to TLS is:
>
> * How to indicate what your PKI capabilities are
> (see, e.g, S 4.2.4 and 4.3.2)
> * How to stuff the PKI material into the protocol
> (principally S 4.4.2)
> * How to determine whether a given certificate is suitable for
> use in TLS 4.4.4.2 and 4.3.2.1).
>
> So we want to outsource the generic PKI part
>
>
> 2. It matches the software architecture that people often use,
> which is to have a TLS stack but separate PKI validation. For
> instance, Firefox uses NSS for TLS but moz::pkix for
> validation. Similarly, Chrome uses BoringSSL for TLS
> but the system PKI libraries for validation.
>
>
> In this case, I think that this text was more intended to
> say "and go read 5280 to learn how to do this". To that end,
> I suggest we say"
>
>
> "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.”
I agree with the reasoning, however the dependency on RFC 5280 should be called
out in a MUST statement. I suggest something like:
"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.”
Note that RFC 5280 is already a normative reference.
Russ
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
