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 that such requests are properly verified under these Requirements.” Please clarify this request, thanks. Best Regards, Richard From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Thursday, February 23, 2017 11:21 AM To: Richard Wang <rich...@wosign.com> Cc: Gervase Markham <g...@mozilla.org>; Tony Zhaocheng Tan <t...@tonytan.io>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist 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 proposing a Ballot to the Baseline Requirements to address this. Alternatively, perhaps you would have a concrete suggestion for Mozilla Root CA Inclusion Policy 2.5 that might be able to address this in a consistent and auditable way and in a manner consistent with Mozilla's policy goals regarding misissuance. This is https://github.com/mozilla/pkipolicy/issues/1 for what it's worth, recently resolved in Policy 2.4 On Wed, Feb 22, 2017 at 5:08 PM, Richard Wang via dev-security-policy <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>> wrote: I think "apple-id-2.com<http://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 microsoftonline.us.com<http://microsoftonline.us.com>, a fake Office 365 login site https://crt.sh/?id=71789336 for mail.google-androids.ru<http://mail.google-androids.ru> https://crt.sh/?id=82075006 for marketgoogle.xyz<http://marketgoogle.xyz> https://crt.sh/?id=65208905 for google.ligboy.org<http://google.ligboy.org> Best Regards, Richard -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+richard<mailto:dev-security-policy-bounces%2Brichard>=wosign....@lists.mozilla.org<mailto:wosign....@lists.mozilla.org>] On Behalf Of Gervase Markham via dev-security-policy Sent: Thursday, February 23, 2017 8:30 AM To: Tony Zhaocheng Tan <t...@tonytan.io<mailto:t...@tonytan.io>>; mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist 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<http://apple-id-2.com>. > However, until today, the domain apple-id-2.com<http://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 here. Our team is looking into this and so far we don't see any evidence of mis-issuance in our logs. It looks like the domain in question, 'apple-id-2.com<http://apple-id-2.com>', was registered and DNS resolved for it successfully at time of issuance. Here is the valid authorization record including the resolved IP addresses for 'apple-id-2.com<http://apple-id-2.com>': https://acme-v01.api.letsencrypt.org/acme/authz/uZGv2KXUJ6Hl... We can't be sure why the reporter was unable to find a WHOIS record, we can only confirm that validation properly succeeded at time of issuance. Update: Squarespace has confirmed that they did register the domain and then released it after getting a certificate from us." There is currently an entry in WHOIS, because some well-meaning but unhelpful person registered it today. I assume that if a domain is registered and then released, and then re-registered, the "Creation" date is of the re-registration, not the first ever registration. So unless someone can show it was unregistered at the time of issuance, I don't see an issue here. Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org<mailto: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<mailto: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
