CA/CT Redaction

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

This page is an attempt to summarise the arguments for and against the idea of redaction in CT.

For

Enterprise Users Are Requesting It

CAs report that enterprise customers are requesting this feature, for some of the reasons given in this document.

Response

In Chrome at least, enterprises already have this capability via enterprise policies, which do not require the installation of a specific root CA. I.e. they can turn off the CT requirement for particular roots.

Concealing Network Topography

Redaction means organizations can use publicly-trusted, CT logged certificates behind their firewalls that do not reveal their security topography by revealing all nodes in the FQDN during CT logging. Multiple wildcard certs with different key pairs would be hard to track.

Response

This is an argument for security through obscurity. And, in fact, will not succeed in achieving the obscurity sought.

IoT Usage

"Things" that connect to the internet (cars, baby monitors, etc.) will want to use publicly trusted certificates that work in common browsers and applications, but will not want the device identity number hierarchy publicly disclosed on CT logs for security purposes. While private roots could be used, going that direction could prevent interoperability, and incompatibility with modern browser software could cause IoT device software to rely on custom software that doesn’t receive security updates (as browser software does) and lead to the same kind of frozen legacy root stores that can’t be updated that we saw during SHA-1 deprecation problems. For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker.

Response

Chrome, at least, believes that the IoT should use private roots, or roots separate from the WebPKI, to avoid the sort of stagnation and legacy compatibility problems we have seen previously, e.g. with SHA-1.

Against

Recourse is Hard

It is difficult to build robust policies and procedures around what happens when a domain owner sees a redacted cert they didn't request. How can they get an unredacted copy of the original? What happens if the CA can't or won't provide it? What recourse does the domain owner have? More details on this can be found in this CT policy post.