On 20/01/2017 00:35, Nick Lamb wrote:
On Thursday, 19 January 2017 20:20:24 UTC, Jakob Bohm wrote:
Google's CT initiative in its current form has serious privacy problems
for genuine certificate holders. I applaud any well-run CA that stands
up to this attack on the Internet at large.
I notice that you have not specifically identified which Certificate Authorities you
believe are "well-run", perhaps your argument would have more force if you
could name some market leaders in that category.
Presumably most that haven't been distrusted by Mozilla or otherwise
publicly shamed for massive misissuance.
As a Relying Party for the Web PKI I think Google's initiative makes a sensible
trade off, you can't have privacy while also delivering oversight. The public
CAs are clearly in need of oversight. This did not happen in a vacuum but as a
consequence of trusted Certificate Authorities exhibiting incompetence and
greed over many years.
As both a relying party and a certificate holder, I see no reason for
public listing of most of the details in the CT logs, and I do take
specific measures to not get public certificates for a number of things
(such as my e-mail addresses) that I don't want listed in Google
searches or attacked by spammers.
So far, I have not seen any good uses for CT logging stuff such as:
- Full domain name (below public suffix + 1) for things like employee
/contractor portals.
- Full domain name (below public suffix + 1) for alpha / beta tests,
staging servers etc.
- Full domain name (below public suffic + 1) for CDN / cluster names,
such as r2---sn-op5oxu-j2il.googlevideo.com
- E-mail addresses other than the RFC2142 special ones.
- City and street address.
- Telephone number.
- Citizens ID/Social security number/Company registration ID.
What is really needed for most non-malicious CT uses are the relevant
2nd/3rd level domain (1 level below public suffix), country, state and
organization names (or CN if not an internet name and no O name part),
slow one way hash of full name entries (e.g.
SHA-512**65536("someu...@gmail.com"),
full issuer details, cryptographic algorithm and strength, plus serial
number and technical details such as EKUs and other non-special cased
items.
For example, to check if someone issued a fraudulent certificate for
any domain or address under google.com, Google Inc could check the list
of redacted CT entries for *@*.google.com, then compare it against an
in-house non-public database of such certificates authorized by their
internal management procedures.
To check for certificates issued to non-existent / suspect domains such
as example.com and/or test[1-9].com (recent Symantec related post in
this group), this would still be fully visible too. So would SHA-1
certificates issued in 2016, duplicate serial numbers, etc. Someone
getting a misissued wildcard cert for a semi-public suffix such as
"sf.net" or "blogblog.com" would also show up.
For a service such as gmail.com, the information suggested above would
allow someone knowing a specific e-mail address such as
"someu...@gmail.com" to check if a certificate was misissued for that
address, but would not provide an easy way for a third party (such as a
spammer) to extract a list of all @gmail.com user names that happen to
have S/MIME certificates (Of cause Google has the original list of
their users already, but no one else should).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
