RE: Criticism of Google Re: Google Trust Services roots

2017-03-30 Thread Richard Wang via dev-security-policy 
To be transparent, WoSign are NOT "acquiring the HARICA root" that we NEVER 
contact HARICA, and we don't think our brand is "tarnishing", we are working 
hard to try to regain the trust and confidence in this community.


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Peter Kurrasch via dev-security-policy
Sent: Thursday, March 30, 2017 9:02 PM
To: Gervase Markham via dev-security-policy ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Criticism of Google Re: Google Trust Services roots

By "not new", are you referring to Google being the second(?) instance where a 
company has purchased an individual root cert from another company? It's fair 
enough to say that Google isn't the first but I'm not aware of any commentary 
or airing of opposing viewpoints as to the suitability of this practice going 
forward.

Has Mozilla received any notification that other companies ‎intend to acquire 
individual roots from another CA? I wouldn't ask Mozilla to violate any 
non-disclosures but surely it's possible to let the community know if we should 
expect more of this? Ryan H. implied as much in a previous post but I wasn't 
sure where he was coming from on that.

Also, does Mozilla have any policies (requirements?) regarding individual root 
acquisition? For example, how frequently should roots be allowed to change 
hands? What would Mozilla's response be if WoSign were to say that because of 
the tarnishing of their own brand they are acquiring the HARICA root? What if 
Vladimir Putin were to make such a purchase? Any requirements on companies 
notifying the public when the acquisition takes place?

Perhaps this is putting too much of a burden on Mozilla as a somewhat protector 
of the global PKI but I'm not sure who else is in a better position for that 
role?


  Original Message
From: Gervase Markham via dev-security-policy
Sent: Thursday, March 30, 2017 1:06 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Reply To: Gervase Markham
Subject: Re: Criticism of Google Re: Google Trust Services roots

On 29/03/17 20:46, Peter Kurrasch wrote:
> It's not inconsequential for Google to say: "From now on, nobody can
> trust what you see in the root certificate, even if some of it appears
> in the browser UI. The only way you can actually establish trust is to
> do frequent, possibly complicated research." It doesn't seem right
> that Google be allowed to unilaterally impose that change on the
> global PKI without any discussion from the security community.

As others in this thread have pointed out, this is not a new thing. I wouldn't 
say that Google is "imposing" this need.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Automated email reminders about intermediate certs missing audit or CP/CPS

2017-03-30 Thread Kathleen Wilson via dev-security-policy 
On Thursday, March 30, 2017 at 10:35:37 AM UTC-7, Kathleen Wilson wrote:
> Within the next few days, we plan to start sending automated email reminders 
> to CAs about their intermediate cert records in the Common CA Database that 
> are missing audit or CP/CPS information.
> 
> The email template is here:
> https://wiki.mozilla.org/CA:Email_templates#Disclosure_Incomplete_Email_Template
> 

We have deployed this to production, and the batch process is scheduled to run 
on the first and third Sunday of each month.

Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

2017-03-30 Thread Nick Lamb via dev-security-policy 
Doesn't Chrome's behaviour already "penalise" plaintext HTTP? You can't build a 
login form, or use shiny new features.

We aren't where we'd ideally be, everybody is agreed about that. That's not the 
same thing as agreeing our direction of travel is wrong.

I am far from home reduced to using mobile devices, or I'd do it myself but I 
recommend someone try to measure the proximate cause of these certificates. 
Unlike with earlier "free" certs the advent of ACME means hosts are throwing in 
certs with hosting, I suspect that some sizeable fraction of the 14k were 
issued on this basis. If so phishers may not even be using the HTTPS feature, 
any more than they'd have used free vouchers for discounted T-shirts if the 
host included those. So 14k becomes a measure not of criminal interest in TLS 
certificates but of the success of full automation in bulk hosting combined 
with the high turnover of phishing sites.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Automated email reminders about intermediate certs missing audit or CP/CPS

2017-03-30 Thread Kathleen Wilson via dev-security-policy 
All,

Within the next few days, we plan to start sending automated email reminders to 
CAs about their intermediate cert records in the Common CA Database that are 
missing audit or CP/CPS information.

The email template is here:
https://wiki.mozilla.org/CA:Email_templates#Disclosure_Incomplete_Email_Template

Please let me know if you have any feedback on this.

Also, what would be a good frequency for sending these email reminders?

Thanks,
Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

2017-03-30 Thread Hector Martin via dev-security-policy 
On 2017-03-30 23:30, Alex Gaynor via dev-security-policy wrote:
>>> 1. HTTP
>>> 2. "I explicitly asked for security and didn't get it" (HTTPS with no
>>> validation)
>>> 3. HTTPS
> 
> You're not wrong that (2) is better than (1). It's also indistinguishable
> from a downgrade attack from (3).

But so is (1) if the URI didn't come from somewhere that already
requested HTTPS. Enter HSTS, etc. Ultimately, yes, ideally we'd have had
something like HSTS levels for each trust level, plus matching URI
schemes or some other way of requesting a minimum trust level in the URI.

> If we got to do the web all over again, I think we'd make the UX for (1)
> have an interstitial, or just not exist. Unfortunately, we're paying down
> two decades of technical debt :-)

Indeed. This is something that was a day 1 design flaw in HTTPS (with
the UX as implemented). The moment you start throwing up big scary
warnings for self-signed certs and not for HTTP, you've lost, because
the people with certs aren't going to want to become susceptible to
downgrade attacks. Though browser makers have progressively made this
worse by making the warning scarier and scarier.

Ah well, we are where we are. I'm grateful I can finally nuke a couple
random personal CAs and just Let's Encrypt everything, with HSTS. With
any luck browsers will start significantly penalizing the HTTP UX and
we'll finally get on the path to ubiquitous encryption.

-- 
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

2017-03-30 Thread Patrick Tronnier via dev-security-policy 
On Sunday, March 26, 2017 at 11:48:43 PM UTC-4, wangs...@gmail.com wrote:
> We compiled an analysis document on our CP/CPS’s Compliance with the BRs for 
> everyone to review and comment. You can find the document at the following 
> address of the 
> BUG:https://bug1128392.bmoattachments.org/attachment.cgi?id=8851230
>  
> Your suggestions will be much appreciated.

As part of the suggestion process it would be useful to expand on the tables 
you listed in section 2 "Compliance Analysis". Would you be able to attach an 
editable MS Word version?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Criticism of Google Re: Google Trust Services roots

2017-03-30 Thread Peter Kurrasch via dev-security-policy 
By "not new", are you referring to Google being the second(?) instance where a 
company has purchased an individual root cert from another company? It's fair 
enough to say that Google isn't the first but I'm not aware of any commentary 
or airing of opposing viewpoints as to the suitability of this practice going 
forward.

Has Mozilla received any notification that other companies ‎intend to acquire 
individual roots from another CA? I wouldn't ask Mozilla to violate any 
non-disclosures but surely it's possible to let the community know if we should 
expect more of this? Ryan H. implied as much in a previous post but I wasn't 
sure where he was coming from on that.

Also, does Mozilla have any policies (requirements?) regarding individual root 
acquisition? For example, how frequently should roots be allowed to change 
hands? What would Mozilla's response be if WoSign were to say that because of 
the tarnishing of their own brand they are acquiring the HARICA root? What if 
Vladimir Putin were to make such a purchase? Any requirements on companies 
notifying the public when the acquisition takes place?

Perhaps this is putting too much of a burden on Mozilla as a somewhat protector 
of the global PKI but I'm not sure who else is in a better position for that 
role?


  Original Message  
From: Gervase Markham via dev-security-policy
Sent: Thursday, March 30, 2017 1:06 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Reply To: Gervase Markham
Subject: Re: Criticism of Google Re: Google Trust Services roots

On 29/03/17 20:46, Peter Kurrasch wrote:
> It's not inconsequential for Google to say: "From now on, nobody can
> trust what you see in the root certificate, even if some of it
> appears in the browser UI. The only way you can actually establish
> trust is to do frequent, possibly complicated research." It doesn't
> seem right that Google be allowed to unilaterally impose that change
> on the global PKI without any discussion from the security
> community.

As others in this thread have pointed out, this is not a new thing. I
wouldn't say that Google is "imposing" this need.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Grace Period for Sub-CA Disclosure

2017-03-30 Thread Rob Stradling via dev-security-policy 

On 30/03/17 13:11, Gervase Markham via dev-security-policy wrote:

On 28/03/17 12:21, Rob Stradling wrote:

Increased attack surface.  An undisclosed dormant sub-CA most likely has
its private key in an online HSM, and so I think it's prudent to assume
that it's more vulnerable (to being compromised by an attacker, or to
being accidentally used to misissue a cert) than an offline root key.


If it's dormant, there's no particular reason the HSM will be online.
But it might be, and it doesn't make much sense to make a distinction in
the policy.


IINM, the purpose (so far) of Mozilla's intermediate cert disclosure
policy is to map the attack surface.  Right?


That's certainly one goal :-)

Does a week sound about right?


SGTM.

Presumably that week begins at either 1) the moment the intermediate is 
issued or 2) the moment the CA is first granted access to the CCADB, 
whichever is the latter?


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Grace Period for Sub-CA Disclosure

2017-03-30 Thread Gervase Markham via dev-security-policy 
On 28/03/17 12:21, Rob Stradling wrote:
> Increased attack surface.  An undisclosed dormant sub-CA most likely has
> its private key in an online HSM, and so I think it's prudent to assume
> that it's more vulnerable (to being compromised by an attacker, or to
> being accidentally used to misissue a cert) than an offline root key.

If it's dormant, there's no particular reason the HSM will be online.
But it might be, and it doesn't make much sense to make a distinction in
the policy.

> IINM, the purpose (so far) of Mozilla's intermediate cert disclosure
> policy is to map the attack surface.  Right?

That's certainly one goal :-)

Does a week sound about right?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

2017-03-30 Thread okaphone.elektronika--- via dev-security-policy 
Right. It is then.

It says private keys can only be stored with permission of the subscriber and 
encryption must always be used to transfer them. And of course the certificate 
must be revoked if/when it becomes known that a private key has gotten to the 
wrong person.

Well... NOT my private keys. I'll create the CSR myself, thank you. ;-)

Anyway, would be nice if there was some evidence in this thread.

CU Hans

On Thursday, 30 March 2017 00:31:50 UTC+2, Ryan Sleevi  wrote:
> 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 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
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Criticism of Google Re: Google Trust Services roots

2017-03-30 Thread Gervase Markham via dev-security-policy 
On 29/03/17 20:42, Jakob Bohm wrote:
> That goal would be equally (in fact better) served by new market
> entrants getting cross-signed by incumbents, like Let's encrypt did.

Google will be issuing from Google-branded intermediates under the
ex-GlobalSign roots. So the chains would be basically the same whether
GS or GTS owned the parent root. So how does requiring them to do it by
cross-signing improve things? Requiring them to do it by cross-signing
just exposes them to business risk which they don't have if they
actually own the roots.

> For example, when doing ordinary browsing with https on-by-default,
> users rarely bother checking the certificate beyond "the browser says
> it is not a MitM attack, good".  Except when visiting a high value
> site, such as a government site to file a change in ownership of an
> entire house (such sites DO exist).  Then it makes sense to click on
> the certificate user interface and check that the supposed "Government
> Land Ownership Registry of the Kingdom of X" site is verified by
> someone that could reasonably be trusted to do so (i.e. not a national
> CA of the republic of Y or the semi-internal CA of some private
> megacorp).

This is what we have CAA and HPKP for.

> With this recent transaction, the browser could show "GlobalSign" when
> it should show "Google", two companies with very different security and
> privacy reputations.  

If Google were issuing from a Google-owned intermediate under a
GlobalSign-owned root, why would the browser show "Google"? I don't
understand how you see the chain differing in this situation.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy