On Wed, September 21, 2016 11:15 am, Melinda Shore wrote: > On 9/21/16 5:23 AM, Tarah Wheeler wrote: > > Hi, I'm Tarah, and I'm new at Symantec. I'll be reviewing and responding > > to the CT redaction thread, and actively involved in proposals. > > A few months ago Symantec had stated that they'll be publishing > redacted labels - is that still the case?
Symantec has stood up an RFC 6962-like log that supports an earlier version of the redaction scheme, which reflects the thinking from 6962-bis Draft 14. It is not trusted by any CT client widely deployed, because it does not implement RFC 6962 (which, as we know, does not support redaction). Symantec has also had trouble, both with first-party and third-party integrations (such as Venafi), with logging redacted certificates, resulting in what might be described as 'over-redacted' certificates. That is, certificates which are redacted even though their domains are public and widely known, which is at conflict with Symantec's stated need for the use case of redaction. This has been summarized at https://sslmate.com/blog/post/ct_redaction_in_chrome_53 for example, but reflects redaction occurring for widely used, publicly disclosed domain names - which seems at direct odds with the stated use cases. Such previous explanations of Symantec's redaction policies can be found at http://www.symantec.com/connect/blogs/privacy-redaction-and-certificate-transparency and http://www.symantec.com/connect/blogs/balancing-certificate-transparency-and-privacy , however, the evidence since these posts indicate an inconsistency in the actual use case and policies. This is perhaps a useful study into the utility, and the risk, of redaction. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
