On Thu, 24 Nov 2016, Peter Bowen wrote: [ chair hat on ]
I've been thinking more about [draft-strad-trans-redaction-00](https://tools.ietf.org/html/draft-strad-trans-redaction-00) and I am now leaning against adoption by the WG. This working group is about transparency not translucency. The goals stated in [What is Certificate Transparency?](http://www.certificate-transparency.org/what-is-ct) have not changed since first published in 2013 (according to the WayBackMachine). They are:
Note that the website you quote is the Google transparency project page. It is not the IETF Trans WG charter, which you can find at: https://datatracker.ietf.org/wg/trans/charter/ It includes: While the privacy issues related to use of RFC6962 for public web sites are minimal, the working group will consider privacy as it might impact on uses of CT e.g. within enterprises or for other uses of logs If redaction support is something that can influence whether or not CT gets deployed, it is definitly within the charter (or a charter update) to work on redaction.
I think the primary driver for the redaction draft has been the fact that one major web browser vendor has suggested that they may set a policy to require CT by default. The IETF has been very successful by avoiding policy and focusing on technical protocols.
I would argue that facilitating certain properties like redaction in the standard would be the way to guarantee different logs can apply different local privacy policies to their log operation. With redaction support logs can choose to support redaction or not. With no redaction in the specification, logs cannot make that choice.
The question at hand is watering down CT and that is something I do not think should happen.
That's certainly in scope to discuss on this list during the adoption call. Paul _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
