I was thinking more that this would be the minimum where a CA is required to revoke. For example, if the revocation requester can demonstrate control in the same fashion as the certificate issued, then the CA MUST revoke. This likely wouldn’t be the only way a CA would be required to revoke. And I do agree it won’t solve all cases. However, if the CA was able to issue a certificate using a particular domain control mechanism, shouldn’t they also be able to complete the domain control mechanism for revocation? Perhaps the domain holder cannot but that shouldn’t necessarily prevent the CA from supporting it.
From: Ryan Sleevi <r...@sleevi.com> Sent: Friday, June 1, 2018 4:08 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: r...@sleevi.com; Wayne Thayer <wtha...@mozilla.com>; Jakob Bohm <jb-mozi...@wisemo.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Namecheap refused to revoke certificate despite domain owner changed Yes, as mentioned in the CABF in the first link Wayne provided, even for our other methods, it can be problematic for domain holders to demonstrate control using particular methods. As Joanna mentioned, .2 can be problematic in a post-WHOIS world. I realize that shooting down suggestions doesn't help us build sustainable solutions, but this was a problem we thought about a lot in the context of the CT redaction discussions, because the only 'effective' mitigation to inappropriate redaction was reveal-(and-revoke) - that is, reveal the redacted name, and possibly revoke the cert if you don't like what was revealed. Trying to decide how to authorize that request and what the consequences of that would be occupied a substantial part of our time (... I promise I didn't hate redaction "just because"). As an example scenario beyond what Wayne pointed out in the https://cabforum.org/pipermail/public/2018-January/012824.html link, consider such situations such as All CAs being required to support all validation methods for revocation. One possible scenario is a lack of interoperable interpretations of some methods (yet compliant with the letter) - for example, GlobalSign's validation methods compared to Let's Encrypt's use of the (draft) ACME validation methods, which comply with the letter but are different protocols. Another possible scenario is that a CA only supports a given method for revocation, not issuance, and thus the robustness of it and the testing of it is far weaker than might be expected (and detected) for domain validation. Understandably, we can try to patch those two examples I gave (and there is useful result in doing so), such as trying to further specify exactly how domains are validated, or potentially requiring CAs to also support all such methods for domain validation as well (although determining whether that means CAs MUST also support DV is a related and natural implication that follows that sort of policy). However, I was trying to present them to indicate the sort of holistic challenges we should think about, and why it's not quite as easy as 'revoke the same way you validated' or 'validate using any/every possible method'. So what does that mean for Richard? Well, I agree with Jakob in that he quoted the appropriate section, and there is a reasonable expectation in principle for the CA to do due diligence to investigate for possible revocation. And I think Wayne's directions on revocation do offer a number of important contributions to that, by providing some degree of flexibility for CAs to do meaningful investigations (although with some degree of transparency inevitably being needed when offering CA discretion). And I think the Root Stores have a role to play in how they communicate that expectation to CAs, such that domain holders have recourse if the CA is not taking meaningful steps. On Fri, Jun 1, 2018 at 5:42 PM, Jeremy Rowley <jeremy.row...@digicert.com <mailto:jeremy.row...@digicert.com> > wrote: Which is yet another reason why removing method 1 and method 5 was a good idea. Do any of the other methods share the same problem? Maybe IP address verification right now. From: Ryan Sleevi <r...@sleevi.com <mailto:r...@sleevi.com> > Sent: Friday, June 1, 2018 2:51 PM To: Jeremy Rowley <jeremy.row...@digicert.com <mailto:jeremy.row...@digicert.com> > Cc: Wayne Thayer <wtha...@mozilla.com <mailto:wtha...@mozilla.com> >; Jakob Bohm <jb-mozi...@wisemo.com <mailto:jb-mozi...@wisemo.com> >; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org <mailto:mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: Namecheap refused to revoke certificate despite domain owner changed You know I'm strongly supportive of requiring disclosure of validation methods, for the many benefits it brings, I'm not sure how that would address the concern. Consider a certificate validated under .5. Would Richard now need to hire a lawyer to say they own their domain name now? On Fri, Jun 1, 2018 at 3:38 PM, Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: This is one of the reasons I think we should require an OID specifying the validation method be included in the cert. Then you can require the CA support revocation using the same validation process as was used to confirm certificate authorization. With each cert logged in CT, everyone in the world will know exactly how to revoke an unauthorized or no-longer-wanted cert. -----Original Message----- From: dev-security-policy <dev-security-policy-bounces+jeremy.rowley=digicert....@lists.mozilla.org <mailto:digicert....@lists.mozilla.org> > On Behalf Of Wayne Thayer via dev-security-policy Sent: Friday, June 1, 2018 1:02 PM To: Jakob Bohm <jb-mozi...@wisemo.com <mailto:jb-mozi...@wisemo.com> > Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org <mailto:mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: Namecheap refused to revoke certificate despite domain owner changed On Fri, Jun 1, 2018 at 5:06 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: > > Please contact the CA again, and inform them that BR 4.9.1.1 #6 > requires the CA (not some reseller) to revoke the certificate within 24 hours > if: > > The CA is made aware of any circumstance indicating that use of a > Fully-Qualified Domain Name or IP address in the Certificate is no > longer legally permitted (e.g. a court or arbitrator has revoked a > Domain Name Registrant’s right to use the Domain Name, a relevant > licensing or services agreement between the Domain Name Registrant > and the Applicant has terminated, or the Domain Name Registrant has > failed to renew the Domain Name); > > While CAs are not required to discover such situations themselves, > they must revoke once made aware of the situation (in this case by you > telling them). > > At least, this is how I read the rules. > > This issue has come up in several CAB Forum discussions such as [1]. > In practice, I believe that the requirement Jakob quoted is rarely invoked because (despite the examples), the language is too vague and narrow. It can also be quite difficult for a CA to verify that the revocation request is coming from the legitimate domain name registrant [1], making it less likely the CA will take action. I've made a couple of attempts to fix this, resulting in the current language proposed for ballot 213 [2]: The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon. I'd prefer a more prescriptive requirement that CAs allow anyone to revoke by proving that they control the domain name using one of the BR 3.2.2.4 methods, but this is a problem because most CAs don't support every domain validation method and many domains are configured such that some validation methods can't be used. - Wayne [1] https://cabforum.org/pipermail/public/2018-January/012824.html [2] https://cabforum.org/pipermail/public/2018-May/013380.html _______________________________________________ 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
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
