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> wrote: > 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 microsoftonline.us.com, a fake Office > 365 login site > https://crt.sh/?id=71789336 for mail.google-androids.ru > https://crt.sh/?id=82075006 for marketgoogle.xyz > https://crt.sh/?id=65208905 for google.ligboy.org > > > Best Regards, > > Richard > > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy-bounces+richard= > 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>; mozilla-dev-security-policy@ > 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. > > 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 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', 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': > > 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 > 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