On Thursday, January 19, 2017 at 6:05:22 PM UTC-8, Jakob Bohm wrote:
> 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.
You presume a lot, I fear. "No disasters yet" is not proof of disaster
prevention.
Apologies for the late reply and this diversion from the thread, but I felt I
should respond to some of this.
> > 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:
>
> - (list cut)
I don't really see the point of putting a Citizen ID number in a website
certificate, either. If you don't put it in the certificate, it doesn't need to
be logged.
Remember that CT as specified is only for WebPKI website validation
certificates, not S/MIME certificates (though I suspect you could submit them).
> 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.
This has enormous complexity requirements above "log the full certificate".
History shows us this would result in even less adoption than we have right now.
> 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.
Disregarding the issue of S/MIME certificates, what do you propose for Honest
Achmed's Car Dealership, whom do not need nor have rigorous management
procedures for SSL certificates? (Replying to the first 3 items in your list
here.)
Hypothetical: A monitoring service says "We saw a certificate logged for
????.honestachmedcars.com. It came from [CA name], SHA256, serial number
xxxxxxxxxx."
Achmed asks around the office and nobody's quite sure why this certificate
was created. It would help a lot if the monitor delivered the full list of
subject names for the certificate, because if it did they would've seen it was
issued for mail.honestachmedcars.com, which would point them to questioning
their managed e-mail provider (who just did a scheduled renewal of all customer
certificates).
>
> 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).
Again, disregarding this because CT was never meant for e-mail certificates.
~Kane York
Speaking as an individual.
>
> 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
