#145: Section 9.2 (TLS clients) needs more guidance for browsers
Comment (by [email protected]): My understanding of the original problem raised in the ticket is that the section on TLS clients is vague/confusing because it prescribes some actions but not the results of these actions, is that right? For example that TLS clients MUST reject an SCT whose timestamp is in the future, but not what it implies for a client to have rejected this SCT. Is this understanding accurate? If so, we can remedy these particular points. However,my understanding is that prescribing client behaviour is outside the scope of 6962-bis. Regarding the focus on browsers, I disagree: A significant portion of traffic nowadays is from native mobile applications which rely on SSL+PKI for securing their connections, but are not browsers. Such an application can decide to hard-fail a connection if no valid SCTs are present, for example, because that particular application communicates with a small set of servers, all of which are expected to serve SCTs. For this reason I think that the proposed text in comment 1 about browsers and incremental deployment is not applicable. I have proposed re-wording of the example provided, of SCTs with timestamp in the future, here: https://github.com/eranmes/certificate-transparency- rfcs/commit/c643193aeea93afe57baf7a63589fa5ec4cf5d6e Does that address at least that case? -- -------------------------+------------------------------------------------- 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:2> trans <https://tools.ietf.org/trans/> _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
