RE: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

2017-02-22 Thread Richard Wang via dev-security-policy
I think "apple-id-2.com" is a high risk domain that must be blocked to issue DV SSL to those domains. Here is the list of some high risk domains related to Microsoft and Google that Let's Encrypt issued DV SSL certificates to those domains: https://crt.sh/?id=77034583 for

Let's Encrypt appears to issue a certificate for a domain that doesn't exist

2017-02-22 Thread Tony Zhaocheng Tan via dev-security-policy
On 2017-01-03, Let's Encrypt issued a certificate for apple-id-2.com. However, until today, the domain apple-id-2.com has apparently never been registered. How was the certificate issued? Sources: https://crt.sh/?q=24ba82659f808f6c5af1816857701bf970cf6ec5751357fea42ef8c4140a4caf

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

2017-02-22 Thread Tony Zhaocheng Tan via dev-security-policy
Yep, no issue here anymore. Josh Aas hadn't posted on hacker news when I sent this. Thanks, Tony Tony Zhaocheng Tan | t...@tonytan.io | PGP Key Original Message On Feb 22, 2017, 7:30 PM, Gervase Markham wrote: On 22/02/17 14:42, Tony Zhaocheng Tan wrote: > On 2017-01-03,

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

2017-02-22 Thread Ryan Sleevi via dev-security-policy
There is no definition or requirement for what a high risk domain is. That's the point/problem. WoSign may determine "apple", "google", "microsoft", and "github" as High Risk. Amazon may determine certificates issued on the first of the month are more likely to be High Risk (because it may be

Re: Misissued/Suspicious Symantec Certificates

2017-02-22 Thread Ryan Sleevi via dev-security-policy
Hi Steve, Thanks for your continued attention to this matter. Your responses open many new and important questions and which give serious question as to whether the proposed remediations are sufficient. To keep this short, and thereby allow Symantec a more rapid response: 1) Please provide the

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

2017-02-22 Thread Ryan Sleevi via dev-security-policy
Hi Richard, There's no policies in the Baseline Requirements or Mozilla Requirements that normalize or define high risk domain, which I believe your suggestion presupposes. Perhaps you (or Qihoo 360, as the voting member of the Forum of the Qihoo/WoSign/StartCom collection) would consider

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

2017-02-22 Thread Ryan Sleevi via dev-security-policy
Hi Richard, My point was that policy requirement simply states that there needs to be a procedure, but does not establish any normative requirements. For example, a CA could develop, maintain, and implement procedures which states that any certificate that is qualified as High Risk requires Gerv

Re: Misissued/Suspicious Symantec Certificates

2017-02-22 Thread Jeremy Rowley via dev-security-policy
Webtrust doesn't have audit criteria for RAs so the audit request may produce interesting results. Or are you asking for the audit statement covering the root that the RA used to issue from? That should all be public in the Mozilla database at this point. > On Feb 22, 2017, at 8:33 PM, Ryan

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

2017-02-22 Thread Matt Palmer via dev-security-policy
On Thu, Feb 23, 2017 at 01:08:49AM +, Richard Wang via dev-security-policy wrote: > I think "apple-id-2.com" is a high risk domain that must be blocked to issue > DV SSL to those domains. Why? > Here is the list of some high risk domains related to Microsoft and Google > that Let's

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

2017-02-22 Thread George Macon via dev-security-policy
On 2/22/17 7:30 PM, Gervase Markham wrote: > On Hacker News, Josh Aas writes: > > > > Update: Squarespace has confirmed that they did register the domain and > then released it after getting a certificate from us." In this case, should Squarespace have requested that the certificate be revoked

RE: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

2017-02-22 Thread Richard Wang via dev-security-policy
Hi Ryan, As I understand, the BR 4.2.1 required this: “The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate’s approval, as reasonably necessary to ensure

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

2017-02-22 Thread Peter Bowen via dev-security-policy
On Wed, Feb 22, 2017 at 7:35 PM, Richard Wang via dev-security-policy wrote: > As I understand, the BR 4.2.1 required this: > > “The CA SHALL develop, maintain, and implement documented procedures that > identify and require additional verification activity

RE: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

2017-02-22 Thread Richard Wang via dev-security-policy
I don't agree this. If "apple", "google", "Microsoft" is not a high risk domain, then I don’t know which domain is high risk domain, maybe only "github". Best Regards, Richard -Original Message- From: Peter Bowen [mailto:pzbo...@gmail.com] Sent: Thursday, February 23, 2017 11:53 AM To:

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

2017-02-22 Thread Vincent Lynch via dev-security-policy
Hi Richard, Peter's point is that there is no standard definition of a "high-risk" request." It is a term defined in Section 1.6.1: "High Risk Certificate Request: A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, which may

Re: Google Trust Services roots

2017-02-22 Thread Peter Bowen via dev-security-policy
Ryan, Both Gerv and I posted follow up questions almost two weeks ago. I know you have been busy with CT days. When do you expect to have answers available? Thanks, Peter On Fri, Feb 10, 2017 at 2:01 AM, Gervase Markham via dev-security-policy wrote: >

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

2017-02-22 Thread Peter Bowen via dev-security-policy
Rather than what you suggest, I think the following could be high risk: свiтова-пошта.info. xn--i--7kcbgb7fdinng1f.info. гooms17139.link. xn--ooms17139-uzh.link. мцяsц.lol. xn--s-wtb4ab7b.lol. сaентология.net. xn--a-ftbfnnlhbvn2m.net. aμ.net. xn--a-mmb.net. μc.net. xn--c-lmb.net. ωe.net.

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

2017-02-22 Thread Gervase Markham via dev-security-policy
On 22/02/17 14:42, Tony Zhaocheng Tan wrote: > On 2017-01-03, Let's Encrypt issued a certificate for apple-id-2.com. > However, until today, the domain apple-id-2.com has apparently never > been registered. How was the certificate issued? On Hacker News, Josh Aas writes: "Head of Let's Encrypt

Re: Misissued/Suspicious Symantec Certificates

2017-02-22 Thread Ryan Sleevi via dev-security-policy
On Wed, Feb 22, 2017 at 8:36 PM, Jeremy Rowley wrote: > Webtrust doesn't have audit criteria for RAs so the audit request may > produce interesting results. Or are you asking for the audit statement > covering the root that the RA used to issue from? That should all

Re: Misissued/Suspicious Symantec Certificates

2017-02-22 Thread Jeremy Rowley via dev-security-policy
I am aware of the requirements but am interested in seeing how an RA that doesn't have their own issuing cert structures the audit report. It probably looks the same, but I've never seen one (unless that is the case with the previously provided audit report). On Feb 22, 2017, at 8:48 PM, Ryan