3
edits
CA/CT Redaction: Difference between revisions
→Logging Reveals Personally Identifiable Information
(First version) |
|||
| Line 50: | Line 50: | ||
How? even if we grant for the sake of discussion that counting certificates is a good way of determining how many devices are shipped, redaction won't change the number of certificates logged. | How? even if we grant for the sake of discussion that counting certificates is a good way of determining how many devices are shipped, redaction won't change the number of certificates logged. | ||
=== 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. | |||
===== 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/ ) | |||
== Against == | == Against == | ||