CA/CT Redaction: Difference between revisions

CA/CT Redaction (view source)

Revision as of 09:31, 30 November 2017

726 bytes removed , 30 November 2017

A few clean-ups

Gerv

Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti

4,925

edits

@@ Line 11: / Line 11: @@
 ===== Response =====
-In Chrome at least, which is currently the only browser that checks CT, 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.
+In Chrome at least, which is currently the only browser that checks CT, 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. However, Chrome's enterprise policy requires a list of all domain names that may appear in non-logged certs, and some enterprise customers have said they manage hundreds of domains that change frequently, so this approach may have challenges. It would be useful to know which reasons for redaction are of interest to such customers; it can't be the "concealing network topography" reason, because surely no company has a list of hundreds of internal-use domains which change frequently.
-However, Chrome's enterprise policy requires a list of all domain names that may appear in non-logged certs, and some enterprise customers manage hundreds of domains that change frequently. These enterprise customers have said that this approach is not workable.
 === Concealing Network Topography ===
@@ Line 39: / Line 37: @@
 ===== Response =====
-Why would someone DOS a random camera just because it was there? One answer may be found here: [https://rhinosecuritylabs.com/internet-of-things/amazon-key-security-cloudcam-disruption-attacks/]
+Why would someone DOS a random camera somewhere else on the Internet just because it was there?
 === Logging Reveals Geolocation Information ===
@@ Line 57: / Line 55: @@
 === Logging Reveals Personally Identifiable Information ===
-For Certificates used for S/MIME, Code Signing, Digital Signatures that contain Personally Identifiable Information (PII) (besides the full name of the Subscriber), there might be Passport, Police, Social Security, Tax ID numbers that could be collected from a single source. E-mail addresses are also included that could be collected by spammers, so redaction would be something useful for these particular cases. For e-mail addresses, redaction in the form PRIVATE@example.com would serve the purpose of transparency and accountability for the CA. As more standards come to play, like the [https://aka.ms/csbr Minimum Requirements for the Issuance and Management of Publicly Trusted Code Signing Certificates], CAs should be able to demonstrate compliance with the issued Certificates and at the same time protect the PII of Subscribers.
+Certificates used for S/MIME, code digning, and digital signatures contain various forms of Personally Identifiable Information (PII).
 ===== Response =====
-Currently there is no application to use and make trust decisions based on SCTs for these types of Certificates. Other solutions might offer similar properties like https://security.googleblog.com/2017/01/security-through-transparency.html which is based on the CONIKS work from Princeton ( https://coniks.cs.princeton.edu/ )
+Currently there are no applications that use and make trust decisions based on SCTs for these types of certificates, and so their consideration is out of scope for this discussion.
 == Against ==