On Fri, Nov 25, 2016 at 8:11 AM, Paul Wouters <[email protected]> wrote: > 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/
You are correct, I cited the Google (6962) project, not the IETF WG charter. That being said, I don't think that the underlying concern is invalid. > 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. Lack of redaction has not prevented 6962 from being widely deployed. There are more than a dozen logs in operation which contain over 24.5 million distinct unexpired certificates. 6962-bis builds on 6962 adding lots of positive features based on experience with 6962 and I'm sure most logs operators will stand up new logs following the standards track RFC when published. Privacy is something that needs to be considered, but that does not mean redaction is the right solution. I would prefer that CT offer a strong guarantee of transparency even if it means not logging every certificate. 6962bis offers an option for privacy -- logging name constrained CA certificates. >> 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. This means different logs have different properties which runs contrary to prior discussions on similar topics. How is allowing logging "redacted" certificates different from allowing a log to accept certificates that it finds valuable even if they don't chain to a known root? >> 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 Thanks, Peter _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
