RAs and the BRs
There is a way to get zero-validation certs, totally legit, under the BRs. Currently, the BRs permit pretty much free delegation of Registration Authorities for everything except domain verification. Without RA audit requirements or even a requirement that the CA monitor/control the RA, the cynical-side of me doubts whether the verification is enforced without the CA first receiving a third-party complaint. Section 1.32 permits free RA delegation if the verification requirements are met by the process as a whole and that a contract exist between the delegated third party to do the following:"(1) Meet the qualification requirements of Section 5.3.1, when applicable to the delegated function; (2) Retain documentation in accordance with Section 5.5.2; (3) Abide by the other provisions of these Requirements that are applicable to the delegated function; and (4) Comply with (a) the CA's Certificate Policy/Certification Practice Statement or (b) the Delegated Third Party's practice statement that the CA has verified complies with these Requirements.". Essentially, as long as there is a) a contract between the CA and RA, and b) the CA is performing domain verification (and c) no one complains), the RA is free to do whatever the RA deems appropriate, permitting the CA to circumvent the BRs and audit oversight. There's no requirement that the CA audit the RA's role in the verification process or that the RA provide any reporting to the CA or auditors. Combined with method 1, there is no obligation the CA actually do anything to vet the customer or obtain any evidence that the customer even exists. As you all know, method 1 requires only that the CA confirm the WHOIS information matches the applicant. As long as the WHOIS information matches, problem solved. As noted above, the RA is not actually required to do any validation (just say that they do) so if the RA passes over the WHOIS name as the verified information, the cert will issue without a second glance. I realize that method 1 and method 5 are going away (for good reason), but that doesn't happen until August. I'd be interested in seeing whether someone can get a cert in this manner from a CA that supports RAs. Jeremy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Policy 2.6 Proposal: Require CAs to support problem reports via email
I believe the intent of the certificate problem reporting in the BRs is to encourage CAs to accept and respond to issues. Although the intent is not specifically stated, my reasoning is based on the fact the BRs requiring CAs to maintain a 24x7 ability to respond, a 24 hour ability to process certificate problems, and a public reporting mechanism. To support this objective, I think we should make the process as easy as possible for reporters, including mandating email. Finding the email addresses is a pain with little reward. Having to go through captchas to even get the email sent is just another obstacle in getting the CA a timely certificate problem report. Therefore, I'd adopt Ryan Hurst's proposal and require that the email be in a standardized format (no more hunting for email aliases) without any blockers to prevent the certificate problem report. Filtering through the mess of emails you get on those aliases is the CAs responsibility. Jeremy -Original Message- From: dev-security-policy On Behalf Of Wayne Thayer via dev-security-policy Sent: Tuesday, April 17, 2018 10:50 AM To: mozilla-dev-security-policy Subject: Policy 2.6 Proposal: Require CAs to support problem reports via email Section 4.9.3 of the CA/Browser Forum's Baseline Requirements says: "The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means.” Mozilla has made a central list of these mechanisms in the CCADB [1] but, as it turns out, some of them (such as web forms with CAPTCHAs) are difficult to use. It is proposed that Mozilla policy go above and beyond the BR requirement to state that email must be one of the problem reporting methods supported. Another argument in favor or requiring CAs to accept problem reports via email is that it provides the reporter with evidence of the submission via their email client and server logs. Arguments against this requirement include the burden placed on CAs who must sort through the large quantities of SPAM received by any published email address, concerns with email reliability, and the reporter's inability to confirm that their email has been received by the CA. According to CCADB [1], all but a handful of CAs already support problem reporting via email. I would appreciate everyone's input on this topic. This is: https://github.com/mozilla/pkipolicy/issues/98 [1] https://ccadb-public.secure.force.com/mozilla/ProblemReportingMechanismsReport --- This is a proposed update to Mozilla's root store policy for version 2.6. Please keep discussion in this group rather than on GitHub. Silence is consent. Policy 2.5 (current version): https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)
If you don't specify by EKU, the exercise of determining intent becomes impossible as illustrated by our (many) attempts to define a server cert in CAB Forum. Better to list the EKUs allowed and not allowed in the same cert than rely on another intent requirement. -Original Message- From: dev-security-policy On Behalf Of Doug Beattie via dev-security-policy Sent: Tuesday, April 17, 2018 1:37 PM To: Wayne Thayer ; mozilla-dev-security-policy Subject: RE: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME) > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of > Wayne Thayer via dev-security-policy > Sent: Tuesday, April 17, 2018 2:24 PM > To: mozilla-dev-security-policy pol...@lists.mozilla.org> > Subject: Policy 2.6 Proposal: Require separate intermediates for > different usages (e.g. server auth, S/MIME) > > This proposal is to require intermediate certificates to be dedicated > to specific purposes by EKU. Beginning at some future date, all newly > created intermediate certificates containing either the > id-kp-serverAuth or id-kp- emailProtection EKUs would be required to contain only a single EKU. We'll need to support a list of EKUs if this becomes a requirement. Server Auth certificates should be able to support lots of different EKUs, for example: id-kp-serverAuth id-kp-clientAuth id-kp-ipsecEndSystem id-kp-ipsecTunnel id-kp-ipsecUser KDC Authentication Smart Card Logon iPSec IKE IKE Intermediate > Arguments for this requirement are that it reduces risk of an incident > in which one type of certificate affecting another type, and it could > allow some policies to be restricted to specific types of certificates. > > It was pointed out that Microsoft already requires dedicated > intermediates [1]. I agree with using dedicated intermediates, but I'd prefer that they should not be required to be EKU constrained. > I would appreciate everyone's input on this topic. > > I suspect that it will be tempting to extend this discussion into > intermediate rollover policies, but I would remind everyone of the > prior inconclusive discussion on that topic [2]. > > This is: https://github.com/mozilla/pkipolicy/issues/26 > > [1] https://aka.ms/rootcert > [2] > https://groups.google.com/d/msg/mozilla.dev.security.policy/3NdNMiM- > TQ8/hgVsCofcAgAJ > --- > > This is a proposed update to Mozilla's root store policy for version 2.6. > Please keep discussion in this group rather than on GitHub. Silence is consent. > > Policy 2.5 (current version): > https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md > ___ > 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 smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)
> -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of > Wayne Thayer via dev-security-policy > Sent: Tuesday, April 17, 2018 2:24 PM > To: mozilla-dev-security-policy pol...@lists.mozilla.org> > Subject: Policy 2.6 Proposal: Require separate intermediates for different > usages (e.g. server auth, S/MIME) > > This proposal is to require intermediate certificates to be dedicated to > specific purposes by EKU. Beginning at some future date, all newly created > intermediate certificates containing either the id-kp-serverAuth or id-kp- > emailProtection EKUs would be required to contain only a single EKU. We'll need to support a list of EKUs if this becomes a requirement. Server Auth certificates should be able to support lots of different EKUs, for example: id-kp-serverAuth id-kp-clientAuth id-kp-ipsecEndSystem id-kp-ipsecTunnel id-kp-ipsecUser KDC Authentication Smart Card Logon iPSec IKE IKE Intermediate > Arguments for this requirement are that it reduces risk of an incident in > which > one type of certificate affecting another type, and it could allow some > policies to be restricted to specific types of certificates. > > It was pointed out that Microsoft already requires dedicated intermediates > [1]. I agree with using dedicated intermediates, but I'd prefer that they should not be required to be EKU constrained. > I would appreciate everyone's input on this topic. > > I suspect that it will be tempting to extend this discussion into intermediate > rollover policies, but I would remind everyone of the prior inconclusive > discussion on that topic [2]. > > This is: https://github.com/mozilla/pkipolicy/issues/26 > > [1] https://aka.ms/rootcert > [2] > https://groups.google.com/d/msg/mozilla.dev.security.policy/3NdNMiM- > TQ8/hgVsCofcAgAJ > --- > > This is a proposed update to Mozilla's root store policy for version 2.6. > Please keep discussion in this group rather than on GitHub. Silence is > consent. > > Policy 2.5 (current version): > https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md > ___ > 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
Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)
On 17/4/2018 9:24 μμ, Wayne Thayer via dev-security-policy wrote: This proposal is to require intermediate certificates to be dedicated to specific purposes by EKU. Beginning at some future date, all newly created intermediate certificates containing either the id-kp-serverAuth or id-kp-emailProtection EKUs would be required to contain only a single EKU. We should not require a single EKU but separation of id-kp-serverAuth and id-kp-emailProtection. This means that if an Intermediate CA Certificate includes the id-kp-serverAuth, it MUST NOT include id-kp-emailProtection but it MAY also include (for example) the id-kp-clientAuth EKU. Dimitris. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Define/clarify policy for transfer of intermediate CA certificates
This issue was brought up in the thread that kicked off the 2.6 root store policy update [1]. Mozilla policy section 5.3.2 requires CAs to disclose new unconstrained intermediate CA certificates within one week of creation. Section 8 covers [in my opinion] transfers of roots but not intermediates. This leaves a loophole for a CA to create a new intermediate CA certificate, then transfer it without notice or approval. This problem also applies to cross-signatures from one CA to another. I am aware of three potential solutions: 1. In section 5.3.2, require CAs to also disclose a change in the ownership or control of an unconstrained intermediate CA certificate within one week of the change. 2. Modify section 8 to explicitly include transfers of trust via intermediate CA certificates and cross signatures. Under section 8.1, this would require notice and approval: If the receiving or acquiring company is new to the Mozilla root program, > there MUST be a public discussion regarding their admittance to the root > program, which Mozilla must resolve with a positive conclusion before > issuance is permitted. > 3. Require organizations that are receiving subordinate CA certificates to go through the whole Mozilla inclusion process as if they were applying for a new root. I would appreciate everyone's input on this topic. This is: https://github.com/mozilla/pkipolicy/issues/122 [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/ xGGGaI1_uo0/POMANRWRAAAJ --- This is a proposed update to Mozilla's root store policy for version 2.6. Please keep discussion in this group rather than on GitHub. Silence is consent. Policy 2.5 (current version): https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)
This proposal is to require intermediate certificates to be dedicated to specific purposes by EKU. Beginning at some future date, all newly created intermediate certificates containing either the id-kp-serverAuth or id-kp-emailProtection EKUs would be required to contain only a single EKU. Arguments for this requirement are that it reduces risk of an incident in which one type of certificate affecting another type, and it could allow some policies to be restricted to specific types of certificates. It was pointed out that Microsoft already requires dedicated intermediates [1]. I would appreciate everyone's input on this topic. I suspect that it will be tempting to extend this discussion into intermediate rollover policies, but I would remind everyone of the prior inconclusive discussion on that topic [2]. This is: https://github.com/mozilla/pkipolicy/issues/26 [1] https://aka.ms/rootcert [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/3NdNMiM-TQ8/hgVsCofcAgAJ --- This is a proposed update to Mozilla's root store policy for version 2.6. Please keep discussion in this group rather than on GitHub. Silence is consent. Policy 2.5 (current version): https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Policy 2.6 Proposal: Decide how policy applies to certs under TCSCs
Section 5.3 of Mozilla policy states: All certificates that are capable of being used to issue new certificates, > and which directly or transitively chain to a certificate included in > Mozilla’s CA Certificate Program, MUST be operated in accordance with this > policy and MUST either be technically constrained or be publicly disclosed > and audited. > This could be interpreted as exempting technically constrained subordinate CA certificates from the self-audit requirements in BR section 8.1, or even from any BR compliance requirement. Since the original discussion of this issue [1] back in 2016, we have updated the scope of our policy to clearly include technically constrained certificates, and thus the requirement for BR conformance in section 2.3 does apply to these certificates. I believe that our current policy already resolves this issue. I propose that we further clarify the requirements for technically constrained certificates by adding a second sentence to the second paragraph of section 5.3.1 of the Mozilla policy as follows: If the certificate includes the id-kp-serverAuth extended key usage, then > the certificate MUST be Name Constrained as described in section 7.1.5 of > version 1.3 or later of the Baseline Requirements. The Baseline > Requirements Conformance policy, as defined in section 2.3, applies to > technically constrained subordinate CA certificates. > I would appreciate everyone's input on this topic. This is: https://github.com/mozilla/pkipolicy/issues/36 [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/ZMUjQ6xHrDA/ySofsF_PAgAJ --- This is a proposed update to Mozilla's root store policy for version 2.6. Please keep discussion in this group rather than on GitHub. Silence is consent. Policy 2.5 (current version): https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Policy 2.6 Proposal: Require CAs to support problem reports via email
Section 4.9.3 of the CA/Browser Forum's Baseline Requirements says: "The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means.” Mozilla has made a central list of these mechanisms in the CCADB [1] but, as it turns out, some of them (such as web forms with CAPTCHAs) are difficult to use. It is proposed that Mozilla policy go above and beyond the BR requirement to state that email must be one of the problem reporting methods supported. Another argument in favor or requiring CAs to accept problem reports via email is that it provides the reporter with evidence of the submission via their email client and server logs. Arguments against this requirement include the burden placed on CAs who must sort through the large quantities of SPAM received by any published email address, concerns with email reliability, and the reporter's inability to confirm that their email has been received by the CA. According to CCADB [1], all but a handful of CAs already support problem reporting via email. I would appreciate everyone's input on this topic. This is: https://github.com/mozilla/pkipolicy/issues/98 [1] https://ccadb-public.secure.force.com/mozilla/ProblemReportingMechanismsReport --- This is a proposed update to Mozilla's root store policy for version 2.6. Please keep discussion in this group rather than on GitHub. Silence is consent. Policy 2.5 (current version): https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....
On Tue, Apr 17, 2018 at 12:24 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/04/2018 00:13, Ryan Sleevi wrote: > >> If you expect that, you're absolutely wrong for expecting that, because >> that's not what a High Risk Request is. >> >> > I am not the only one with that expectation. In the concrete case the > expectation was succinctly stated by Mathew in Message-ID > mailman.312.1523571519.2176.dev-security-policy at lists.mozilla.org as > And someone else is wrong on the Internet. That doesn't make it any more correct or reasonable assumption, no more than if you and I both agreed we deserved to be paid $1 million a year by CAs for exchanging emails on this list. > The definition is in section 1.6.1 of the BRs and does not limit itself > to blacklisted site names. Nor does it require blacklisted site names. That's the point. It's describing illustrative, not normative, examples of a process, not an exact output. That is hugely meaningful in explaining why your expectations have no basis in the requirements - nor, for that matter, are desirable. > >>> But just to please your pedantry, I will add two additional outcome >>> options: >>> >>> -1. Thay CA does not really check for high risk names at all. This >>>might be permitted by some readings of BR 4.2.1 / Ballot 78. >>> >>> >> It absolutely is permitted, and not a negative. Your expectations are >> wrong, and you should adjust them, because they're not based in reality. >> >> > BR 4.2.1 is a SHALL, not a SHOULD. > Yes - that you have a process. It does define the process for what quantifies as that high risk in any form of MUST/SHALL language. I can say high-risk requests are anything received via an InterPlanetaryNetwork ( https://en.wikipedia.org/wiki/Interplanetary_Internet ) and that is fully conforment - and in line with expectations. The notion of "High-risk" is fundamentally at the definition of the CA - what the objectives of certificates are, from the CAs view. Thankfully, there are competent CAs that recognize that certificates are not a phishing mitigation, and treat "risk" as an operational risk category (or, to sate some of the frothing masses, a PR risk), since there fundamentally is not some enhanced 'phishing' risk from certifying a domain. > Weak is a common security term and a common English term with similar > meaning in both contexts. > This is patently false. > The question asked by Matthew and me, and which you keep blocking, is if > jomo has publicly disclosed a case in which that CA's procedures > accidentally fail to achieve that CA's security goals for those > procedures. This is a perfectly normally vulnerability issue > investigation, which jomo (not I) made public 4 days ago. No, this is not. Because you're hinging on a flawed understanding of what you're asking, a flawed set of expectations, Matthew is working from a flawed sense of angst, which all are rooted in an improper understanding of the BRs or the goals of certificates, and for which the notion of "security goals" is clearly one you Have Opinions about, but those opinions are not in line with industry best practice or stated CA goals. So your questioning is not whether the CA has failed to achieve their goals, but whether they've failed to achieve your goals, and that's very much a nonsequitur with no basis in the actual goals of certificates. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy
I believe the wording "insecure electronic channels" leaves a lot of space for interpretation. In corporate PKIs for email encryption it is quite common to transfer centrally generated email encryption p12-files to mobile device management systems, email encryption gateways or directly to mobile devices using a wide variety of 'electronic channels'. From the proposed wording it doesn't seem to be clear which of those channels are 'insecure' and which not. Even if not that common, the same applies for email signature p12-files for e.g. email signature on mail gateways or mobile devices. Most of the mobile devices out in the field neither support hardware token, key-pair-generation in the mailer software nor installation of downloaded p12-files (prohibited by app sandboxing). Maybe it would be possible to restrict the new wording to the EKU kp-ServerAuth first and have a detailed discussion about email-encryption and user authentication with more interested parties in the next months? With best regards, Rufus Buschart Siemens AG GS IT HR 7 4 Hugo-Junkers-Str. 9 90411 Nuernberg, Germany Tel.: +49 1522 2894134 mailto:rufus.busch...@siemens.com www.siemens.com/ingenuityforlife -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+rufus.buschart=siemens@lists.mozilla.org] On Behalf Of Wayne Thayer via dev-security-policy Sent: Dienstag, 17. April 2018 02:24 To: mozilla-dev-security-policy Subject: Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy On Tue, Apr 10, 2018 at 7:22 AM, Jürgen Brauckmann via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > Am 10.04.2018 um 01:10 schrieb Wayne Thayer via dev-security-policy: > >> Getting back to the earlier question about email certificates, I am >> now of the opinion that we should limit the scope of this policy >> update to TLS certificates. The current language for email >> certificates isn't clear and any attempt to fix it requires us to >> answer the bigger question of "under what circumstances is CA key generation >> acceptable?" >> >> My updated proposal is to add the following paragraphs to section 5.3 >> “Forbidden and Required Practices”: >> >> CAs MUST not generate the key pairs for end-entity certificates, >> except for >> >>> email certificates with the Extended Key Usage extension present and >>> set to id-kp-emailProtection. >>> >> > > What about user certificates for logon/authentication? CN=John Doe, > extendedKeyUsage=clientAuth? Is that different from email certificates? > > Yes, but certificates with only the clientAuth EKU are out of scope according to section 1.1 of the Mozilla policy Wouldn't it be better to make that a positive list to really limit the > scope of the change? > > Yes, I think so. = > CAs MUST NOT generate the key pairs for end-entity certificates the > scope of the Baseline Requirements. > = > > But this is too vague. I propose that we add the following paragraphs > to section 5.2: CAs MUST NOT generate the key pairs for end-entity certificates that have > EKU extension containing the KeyPurposeIds id-kp-serverAuth or > anyExtendedKeyUsage. > > CAs MUST NOT distribute or transfer certificates in PKCS#12 form through > insecure electronic channels. If a PKCS#12 file is distributed via a > physical data storage device, then: > * The storage must be packaged in a way that the opening of the > package causes irrecoverable physical damage. (e.g. a security seal) > * The PKCS#12 file must have a sufficiently secure password, and the > password must not be transferred together with the storage. Here it is on GitHub: https://github.com/mozilla/pkipolicy/commit/456f869a15b6b9ca9be1df1897852b0c508932c7 Are there any concerns with this approach? - Wayne Thanks, >Jürgen > > ___ 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
Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....
On 17.4.18 06:24, Jakob Bohm via dev-security-policy wrote: > I am not the only one with that expectation. In the concrete case the > expectation was succinctly stated by Mathew in Message-ID > mailman.312.1523571519.2176.dev-security-policy at lists.mozilla.org as > > Mathew> With respect to domain name labels, all CAs maintain high risk > Mathew> lists. I doubt would issue for > Mathew> paypal.any_valid_tld even if CAA would permit. > [ Name of CA elided ] > The question asked by Matthew and me, and which you keep blocking, is if > jomo has publicly disclosed a case in which that CA's procedures > accidentally fail to achieve that CA's security goals for those > procedures. This is a perfectly normally vulnerability issue > investigation, which jomo (not I) made public 4 days ago. I was merely interested if Matthew's statement was correct, as I assumed it was not. This was not intended to be (and is not) a vulnerability issue investigation. It turned out Let's Elide indeed does issue a certificate [0], which I find nothing wrong with. They maintain a blacklist of high risk domains, as has been discussed in their community forums [1]. They do not make the list public, but have made previous statements about it; they have, in the past, accidentally blacklisted permutations of domains that were not malicious, but happened to use a similar name as a "high risk" domain, which made them change their blacklisting mechanisms [2]. They might, for example, blacklist TLD permutations of "high risk" domains registered by the same corporation. In this case it would include, for example, paypal.com and paypal.de, but not paypal.cologne, as it is not registered by the same corporation (PayPal Inc.) as the high risk paypal.com. The BRs do not require CAs to exclude domains from DV only because a big corporation uses a similar name. See also [3]. 0: https://crt.sh/?id=393717424 1: https://community.letsencrypt.org/search?q=%22Name%20is%20blacklisted%22 2: https://community.letsencrypt.org/t/name-is-blacklisted-on-renew/9012/19 3: https://letsencrypt.org/2015/10/29/phishing-and-malware.html jomo ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy