On Tue, Nov 15, 2016 at 7:27 AM, Gervase Markham <g...@mozilla.org> wrote: > I certainly think our view of redaction will be driven by use cases. > AIUI, you are strongly encouraging use cases to be brought to the IETF. > However, if 6962bis is in Last Call, and won't be updated, is the TRANS > group still listening to and accumulating use cases for redaction?
(Chrome/Google hat) 6962-bis has completed WGLC. It describes the base mechanism for logging certificates - but makes no statements about the policy (e.g. when it is appropriate to log a certificate). It describes, at present, a single technical mean to avoid logging a certificate. This is covered in https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-20#section-4 The TRANS WG also seems to have rough consensus to continue to discuss https://datatracker.ietf.org/doc/draft-strad-trans-redaction/ on the path to adoption. This draft would define additional methods for redaction, as driven by the use cases, for which you could log a 'certificate' in a way with less information than the methods provided by 6962-bis. So the topic of redaction is by no means closed. Rather, it's being worked on in parallel, with 6962-bis defining the 'base' technology, and the redaction I-D covering more of the nuanced use cases. You might imagine this as the distinction between 'certificates' and 'precertificates' within the existing CT ecosystem. A 'precertificate' has a specific prescribed shape and signalling, and when implemented, is 'as good as' logging the certificate. Similarly, the redaction ID defines a specific shape of how to restrict some information from being logged - without setting any policies on when it may or may not be appropriate to employ that method, versus say 6962-bis full certificate logging, or when 6962-bis' existing defined mechanism may not be sufficient. So the policy is disjoint from the technology (as IETF is awful with policy and tries to avoid it, thankfully); the I-D describing the technical forms to address the use cases is still under active work, but in order to ensure a timely completion, we (Chrome) want to make sure the use cases are fed in as much as possible early in the process, to allow sufficient exploration of a technical solution, and if a technical solution isn't viable, to push towards a policy solution. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
