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:
* Make it impossible (or at least very difficult) for a CA to issue a SSL certificate for a domain without the certificate being visible to the owner of that domain. * Provide an open auditing and monitoring system that lets any domain owner or CA determine whether certificates have been mistakenly or maliciously issued. * Protect users (as much as possible) from being duped by certificates that were mistakenly or maliciously issued. I believe that a log inclusion proof should provide assurance that these goals are met. It should mean that the certificate was included in the log intact and that it is available from the log for review. This is important when looking at things like NSRequiresCertificateTransparency in Apple App Transport Security and the [Expect-CT draft](https://tools.ietf.org/html/draft-stark-expect-ct). These allow a server or application owner to specify that CT is required for connections. One can also imagine a future draft to update the [TLSA RFC](https://tools.ietf.org/html/rfc6698) to add CT as a flag in certificate usage so that a site could declare via DNS to only trust a certificate that has an inclusion proof (or SCT). Adding some "translucent" option means that these become far less valuable policy directives. 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. For example, the DNS RFCs discuss how DNS works not how it is deployed. Even within the ICANN/PTI rooted DNS, there are policy differences. The dk TLD requires that all DNS servers for registered domains under dk be publicly accessible and meet certain technical requirements while the xyz domain accepts name servers that have IP addresses in address blocks that are not global (as defined in [RFC 6890](https://tools.ietf.org/html/rfc6890), e.g. 10.0.0.0/8). It is also possible to use the DNS protocol on standalone networks not interconnected to other networks. The same should be true for CT -- the protocol and expectations should be well defined and usable in a variety of ways and policy should be separate from the RFCs. To be clear, I do not believe that lack of support for adoption of the redaction draft should imply support for a policy of requiring CT by default. That is a different discussion for a different list. The question at hand is watering down CT and that is something I do not think should happen. Thanks, Peter _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
