RE: [TLS] Record layer corner cases
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [TLS] Record layer corner cases



I see that Peter Williams is correct in that this topic is no
more amenable to a meeting of the minds than is religion or
politics.  There is very little to say that hasn't already
been said, except ...


> It is legal and secure to ignore certificates that are outside of
> the certification path between the peers end entity cert and the
> verifiers chosen trust anchor.
>
> Security-wise, the signature verification on the certification path
> should be performed starting with the trust anchor and towards the
> end entitiy certificate.
>
> However, if a local trust anchor matches a rootCA cert, then that
> rootCA cert then it is at the discretion of the verifier to consider
> it part of the certification path or attempt an optimization and
> eliminate it.  There certainly is no requirement that it be ignored!

Correct, no such requirement appears in RFC 2246 or RFC 4346:

       Because
       certificate validation requires that root keys be distributed
       independently, the self-signed certificate which specifies the
       root certificate authority may optionally be omitted from the
       chain, under the assumption that the remote end must already
       possess it in order to validate it in any case.

In the interest of unambiguity and interoperability, I would suggest
that the "ignore" statement you previously imputed to TLSv1 be
added as a requirement to TLS 1.2 (draft 4346bis):

       TLSv1 improved the situation, indicating that the path may
       or may not contain a rootCA (=self-signed) cert, and
       mentioned that such a cert, if present, should not have
       an impact on the decision whether the peer's certificate
       is trusted.


Signing off,
Dave


_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.