Re: Criticism of Google Re: Google Trust Services roots

On 29/03/17 15:35, Peter Kurrasch wrote: > In other words, what used to be a trust anchor is now no better at > establishing trust than the end-entity cert one is trying to validate or > investigate (for example, in a forensic context) in the first place. I > hardly think this redefinition of

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

All, This request is to include the "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit, and enabled EV treatment. In order to help get this discussion moving again, I asked GDCA to provide a side-by-side comparison of the latest version of the BRs with their CP/CPS

Re: Criticism of Google Re: Google Trust Services roots

On 29/03/2017 16:47, Gervase Markham wrote: On 29/03/17 15:35, Peter Kurrasch wrote: In other words, what used to be a trust anchor is now no better at establishing trust than the end-entity cert one is trying to validate or investigate (for example, in a forensic context) in the first place. I

Re: Criticism of Google Re: Google Trust Services roots

I don't think it's a good idea to design our system around the idea of "What would a user be looking for if they read the cert chain manually". For example, in the US, if such a government agency chose to use a Government CA (as a user might reasonably expect!), their users would all get cert

DRAFT - BR Self Assessments

All, As mentioned in the GDCA discussion[1], I would like to add a step to Mozilla's CA Inclusion/Update Request Process[2] in which the CA performs a self-assessment about their compliance with the CA/Browser Forum's Baseline Requirements. A draft of this new step is here:

Re: Criticism of Google Re: Google Trust Services roots

I'm not so sure I want to optimize the system in that way, but I am concerned about the (un)intended consequences of rapidly changing root ownership on the global PKI. It's not inconsequential for Google to say: "From now on, nobody can trust what you see in the root certificate, even if some

Re: Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites

On Wed, Mar 29, 2017 at 7:30 AM, Hector Martin via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > We actually have *five* levels of trust here: > > 1. HTTP > 2. HTTPS with no validation (self-signed or anonymous ciphersuite) > 3. HTTPS with DV > 4. HTTPS with OV > 5. HTTPS

Re: Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites

> Not for those sorts of differences. There are in an IDN context: > http://unicode.org/reports/tr39/ wasn't aware of that TS, thanks! ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf Section 6.1.2 On Wed, Mar 29, 2017 at 3:22 AM, okaphone.elektronika--- via dev-security-policy wrote: > Weird. > > I expect there are no requirements for a CA to keep other people's

RE: DRAFT - BR Self Assessments

Hi Kathleen, This is a good idea, and I like the phased-in approach. The mapping exercise is similar to how other communities evaluate inclusion requests and makes it more apparent how the CA is complying with the various Mozilla requirements. An extension on this could be to have CAs annually

Re: Criticism of Google Re: Google Trust Services roots

On 29/03/2017 20:52, Alex Gaynor wrote: I don't think it's a good idea to design our system around the idea of "What would a user be looking for if they read the cert chain manually". For example, in the US, if such a government agency chose to use a Government CA (as a user might reasonably

Re: DRAFT - BR Self Assessments

On Wednesday, March 29, 2017 at 2:00:05 PM UTC-7, Jeremy Rowley wrote: > ... > An extension on this could be to have CAs annually file an updated mapping > with their WebTrust audit. That way it's a reminder that the CA needs to > notify Mozilla of changes in their process and keeps the CAs

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

Weird. I expect there are no requirements for a CA to keep other people's private keys safe. After all handling those is definitely not part of being a CA. ;-) CU Hans ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites

On 28/03/17 08:23, Peter Gutmann via dev-security-policy wrote: Martin Heaps via dev-security-policy writes: This topic is frustrating in that there seems to be a wide attempt by people to use one form of authentication (DV TLS) to verify another form

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

* Nick Lamb via dev-security-policy: > In order for Symantec to reveal anybody's private keys they'd first > need to have those keys, which is already, IIRC forbidden in the > BRs. I think this requirement was dropped because it makes it unnecessarily difficult to report key compromises. There