#112: Consider permitting the status_request_v2 TLS extension Currently we require TLS clients to implement the original status_request (RFC6066) TLS extension (aka OCSP stapling) in order to comply with CT.
The IETF standardized status_request_v2 (RFC6961) a couple of years ago. I'm not aware of any implementations of it yet. Indeed, some browsers may never implement it, because they already have proprietary mechanisms for revoking intermediate certificates. Nevertheless, it would seem a little strange for 6962-bis to contain absolutely no mention of status_request_v2. If a TLS client and a TLS server both implement CT and both implement status_request_v2, why not permit status_request_v2 to be used for distributing SCTs? I think we should permit status_request_v2 as an optional 4th mechanism for distributing SCTs. In other words... - TLS servers MUST support at least 1 of the 3 existing mechanisms for sending SCTs (same as today); and TLS servers MAY also support sending SCTs via status_request_v2. - TLS clients MUST implement all 3 existing mechanisms for receiving SCTs (same as today); and TLS clients MAY also support receiving SCTs via status_request_v2. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- [email protected] | [email protected] Type: enhancement | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/112> trans <http://tools.ietf.org/trans/> _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
