#145: Section 9.2 (TLS clients) needs more guidance for browsers
Comment (by [email protected]): Along the lines of [https://mailarchive.ietf.org/arch/msg/trans/kD72jFHiTzS3tSGU755byjNQOSM], I've come up with some text (to replace the current text in Section 9.2) that I think addresses the issues in this ticket while avoiding the use of standards language. This approach will hopefully make it easier for 6962-bis to progress, without first requiring consensus on TLS client behavior. CT benefits a TLS client by providing additional confidence in the authenticity of a TLS server's certificate (if the certificate has been logged). A TLS client that is not CT-aware receives some of the benefit of CT due to normal revocation of mis-issued certificates that have been identified by other components of the CT system. However, a TLS client may receive additional benefits from CT if the client is CT-aware. (A TLS client is deemed to be CT-aware if it is configured with CT metadata that enables it to validate SCTs and other data signed by one or more logs). While CT could be applied to any TLS client, in practice it is designed primarily with web browsers in mind. As such, the remainder of this section discusses browsers. A browser benefits from CT most when the browser can verify that each TLS server certificate chain it relies on has been properly logged, and is thus available to Monitors. To do this, a browser will (indirectly) receive information from logs, potentially via the mechanisms specified in Section 7. The browser will then need to parse and verify that information. A valid SCT or inclusion proof from a properly behaving log provides evidence that the certificate chain was logged. (See Section 9.4 for a top-level discussion of how an Auditor can detect if a log is misbehaving.) Currently there is no plan for incremental deployment of CT that will result in all authentic certificates being logged. Thus it would be inappropriate for a browser to reject a TLS server certificate merely because of the absence of an SCT. However, if a later, standards track RFC is published that describes a backwards-compatible, incremental deployment plan that addresses this problem, then a browser will be able to reject certificate chains that are not accompanied by evidence of logging. A comprehensive specification of requirements for CT-aware browsers will be provided in a document to be published later. If CT is used by other TLS clients, then that specification may apply additionally to those clients, or another specification may be written to specify behavior for those TLS clients. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- [email protected] | [email protected] Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: <https://trac.tools.ietf.org/wg/trans/trac/ticket/145#comment:1> trans <https://tools.ietf.org/trans/> _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
