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

Reply via email to