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 Markham's personal seal of approval - and could define the way to do so - but they could also say that "Only certificates requested by Gerv Markham are considered High Risk"
Alternatively, a CA could deem that all High Risk certificates will require a second DNS resolution after 30 seconds, to make sure that the first was not forged. And that can be developed, maintained, and implemented - but again, doesn't do what you want. Your suggestion - which was worded as specific domains, but if I might be as bold as to suggest what you meant to say, likely meant substrings in domains - implies that there is a certain common requirement either on how to handle such High Risk requests (block/manually approve/require Gerv's personal seal of approval imbued upon a wax maintained at a 78 degree centrigrade temperature for no less than 30 minutes prior to imbuing) or how to define what is high risk (e.g. substring, CAA, "people we don't like because they embarrassed us") Because the BRs (and Mozilla policy) neither specify what _is_ High Risk or what is _acceptable_ when a High Risk request is processed, it does not make any sense to suggest particular domains (or substrings) be prohibited without tackling those two issues first. This is why I suggested that the solution you've proposed, under the current policies in play, has zero effect. If you believe your solution is right/appropriate, then the first step would be to change the policies. On Wed, Feb 22, 2017 at 7:35 PM, Richard Wang <rich...@wosign.com> wrote: > 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> 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
