On Tue, May 16, 2017 at 11:31 AM, Russ Housley <[email protected]> wrote:
>
> On May 16, 2017, at 11:23 AM, Eric Rescorla <[email protected]> wrote:
>
>
>
> On Tue, May 16, 2017 at 8:17 AM, Russ Housley <[email protected]> wrote:
>>
>>
>> On May 15, 2017, at 7:01 PM, Eric Rescorla <[email protected]> wrote:
>>
>>
>>
>> On Mon, May 15, 2017 at 12:38 PM, Russ Housley <[email protected]>
>> 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
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
