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 <[email protected]> Sent: Friday, June 1, 2018 2:51 PM To: Jeremy Rowley <[email protected]> Cc: Wayne Thayer <[email protected]>; Jakob Bohm <[email protected]>; mozilla-dev-security-policy <[email protected]> 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 <[email protected] <mailto:[email protected]> > 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:[email protected]> > On Behalf Of Wayne Thayer via dev-security-policy Sent: Friday, June 1, 2018 1:02 PM To: Jakob Bohm <[email protected] <mailto:[email protected]> > Cc: mozilla-dev-security-policy <[email protected] <mailto:[email protected]> > 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 < [email protected] <mailto:[email protected]> > 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 [email protected] <mailto:[email protected]> https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] <mailto:[email protected]> https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
