On 21/09/16 23:00, Ryan Sleevi wrote:
> 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.
Symantec are still doing this today (e.g., https://crt.sh/?id=33742991
is a precertificate that was logged only a few hours ago).
The following report shows all of the "redacted precertificates" that
Symantec have issued, along with the corresponding certificates (where
known to CT):
> 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
> , 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.
Senior Research & Development Scientist
COMODO - Creating Trust Online
Trans mailing list