Re: [TLS] AD Review of draft-ietf-tls-tls13

[Sankalp Bagaria <[e-mail]>]

Hi,

I would like to mention that TLS can be used with non-X.509 certificates
also.
In particular, it can be used with ITS ETSI and IEEE certificates.
https://datatracker.ietf.org/doc/html/draft-serhrouchni-tls-certieee1609

So, in my opinion, TLS should be very loosely or not at all coupled with
RFC 5280.

Thanks and Regards,
Sankalp Bagaria.


> On Tue, May 16, 2017 at 11:31 AM, Russ Housley <[e-mail]>
> wrote:
> >
> > On May 16, 2017, at 11:23 AM, Eric Rescorla <[e-mail]> wrote:
> >
> >
> >
> > On Tue, May 16, 2017 at 8:17 AM, Russ Housley <[e-mail]>
> wrote:
> >>
> >>
> >> On May 15, 2017, at 7:01 PM, Eric Rescorla <[e-mail]> wrote:
> >>
> >>
> >>
> >> On Mon, May 15, 2017 at 12:38 PM, Russ Housley <[e-mail]>
> >> wrote:
> >>>
> >>> 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.
> >>
> >>
> >> A MUST here would be a pretty material change to historical TLS
> practice.
> >> As Viktor says, there are TLS-using applications that just don't
> validate
> >> the cert via 5280 at all.
> >>
> >>
> >> I think we want to say that if the certificates are used, then the
> >> certification path MUST be validated in a manner that is compatible with
> >> Internet X.509 certificate profile [RFC5280]; however, other approaches
> to
> >> validation of the public key, such as the DANE TLSA resource record
> >> [RFC6698], are also acceptable.
> >
> >
> > I can see how you would want to say that, but it's not really consistent
> > either
> > with historical practice or with the way that other standards track RFCs
> use
> > TLS
> > with certificates (see RFC 5763).
> >
> >
> > Actually, that is a great example.  I accept the need for loose coupling.
>
> 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?
>
> Thanks,
> Kathleen
>
> >
> > Russ
> >
>
>
>
> --
>
> Best regards,
> Kathleen
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>
> ------------------------------
>
> End of TLS Digest, Vol 154, Issue 61
> ************************************
>