#111: Consider using the cached-info TLS extension
Comment (by [email protected]): I'd like to tackle this in 6962-bis. The original idea in this ticket (i.e. a TLS client sends hashes of SCTs that it has previously seen and cached) seems sub-optimal, in terms of bytes on the wire. So here's what I think is a better approach: When a TLS client uses the cached-info extension to inform a TLS server of 1 or more certs it has cached, the TLS client may also indicate (via a boolean flag) whether or not it has already verified that each cert is "CT compliant" (according to the TLS client's own policies). One approach would be to have a list of boolean flags that corresponds to the list of 1 or more "cert" cached-info records. A simpler approach (which I think would be sufficient) would be to have a single boolean flag that is only set to "true" if all of the (1 or more) cached certs is already deemed by the TLS client to be "CT compliant". This boolean flag could be passed in the transparency_info extension, but I'm not sure it'd be wise to create that sort of interdependency between transparency_info and cached_info. So I suggest that we define a new CachedInformationType so that TLS clients can send this boolean flag via cached_info. Any comments on this proposal? -- -------------------------------------+------------------------------------- Reporter: | Owner: [email protected] | [email protected] Type: enhancement | Status: new Priority: minor | Milestone: Component: to-be-decided | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: <https://trac.tools.ietf.org/wg/trans/trac/ticket/111#comment:6> trans <https://tools.ietf.org/trans/> _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
