Re: Namecheap refused to revoke certificate despite domain owner changed
Official reply from Comodo: We do not normally intervene on behalf of our resellers, however we expedited this matter for you by revoking the certificate on June 4, 2018. Unfortunately, our ticketing system failed to deliver a templated Notification Of Revocation email to you on the same date. We appreciate your patience and apologize for the impact to you, your users, and your organization. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Namecheap refused to revoke certificate despite domain owner changed
Howdy, An update to the situation. Mr. Rob Stradling replied me on Twitter saying that the issue has been resolved last week. After checking with crt.sh, It does seems to be revoked on 2018-06-04 12:54:09 UTC, sadly, with no response from Comodo or Namecheap, so I did not know it happended. For now the issue has been solved, looking forward to the better future with new proposal being discussed. Richard ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Namecheap refused to revoke certificate despite domain owner changed
Howdy, Thank you all for the discussions around this topic, just a quick update on the situation. Following Jakob's advice, I have notified both Comodo and Namecheap that under BR, they needed to revoke that specific certificate I brought up. So far, Comodo's SSL Abuse Dept. ( ssl_abuse#comodo.com ) had automatic replied that the person in charge is currently out of the office and will be back June 13. Namecheap's "Risk Management Team" has no response. Will update after June 13 I suppose. Thank you. Richard ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Namecheap refused to revoke certificate despite domain owner changed
On 01/06/2018 21:01, Wayne Thayer wrote: On Fri, Jun 1, 2018 at 5:06 PM Jakob Bohm via dev-security-policy < 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. Note that as I read it, all they need to do is to check that the whois has changed since the date of issuance/validation, thus making any validation to the former domain owner probably outdated (it could of cause happen that the legit owner has made a technical change such as a new phone number). Though the "Registered" date or "Creation Date" being after the validation date would be pretty strong evidence, even if no other fields are visible. Where whois is not visible (such as the unfortunate way that some registrars have handled GDPR), the person requesting revocation under the existing 4.9.1.1 #6 would have to provide documentation that domain ownership was changed. Again, no proof of their own identity, simply proof that an ownership change happened between validation and revocation request. This isn't conditional on the original validation involving a whois lookup, or the CA having any record of the name of the domain owner. It's a simply a "domain ownership changed => old certificates should be voided on request". 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 Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Namecheap refused to revoke certificate despite domain owner changed
On 01/06/2018 22:39, Joanna Fox wrote: In light of the limited visibility of WHOIS, Wayne's suggestion of "... allow anyone to revoke by proving that they control the domain name using one of the BR 3.2.2.4 methods" is preferable as it is a bit more encompassing rather than restricting to to same validation process. This also supports the idea of transparency around revocation processes. That would make it trivially easy for someone hijacking any other aspect of a domain to extend their attack to revocation of the real domain owners certificate. This includes situations such as BGP attacks, DNS attacks, rogue hosting providers, all of which are common problems. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Namecheap refused to revoke certificate despite domain owner changed
RFC 6844: "The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the Certification Authorities (CAs) authorized to issue certificates for that domain. " CAA record checks would be outside the scope of revocation requests. I'm not sure I agree with " In any event, proof of ability to modify the authoritative DNS over each label in the certificate should almost certainly suffice to revoke a previously issued certificate that relied exclusively upon just about any other sort of domain validation." But only because I doubt every CA supports DNS checking, and I know several companies where the people operating the DNS are not the same entities authorized to manage certificates. -Original Message- From: dev-security-policy On Behalf Of Matthew Hardeman via dev-security-policy Sent: Friday, June 1, 2018 5:17 PM To: Jeremy Rowley Cc: mozilla-dev-security-policy ; Jakob Bohm ; Wayne Thayer Subject: Re: Namecheap refused to revoke certificate despite domain owner changed On Fri, Jun 1, 2018 at 2:38 PM, Jeremy Rowley via dev-security-policy < 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. > > I agree that it would be forensically interesting to have that data available in the certificate. I question whether a policy of using only the same method of demonstrating control anew is appropriate as a policy for granting revocation. There is a hierarchy of supremacy in domain validation. The party controlling the NS delegations from the registry has absolute precedence over the present effective DNS server administrator, should they choose to flex it. The party immediately in effective control of the authoritative DNS takes precedence over a website admin within the domain. Consider that now current CAA records and policy (for good cause, even) might presently prohibit successful validation via the method previously utilized to acquire the certificate that the current domain holder wishes to have revoked. (Even if only by specifying a new CA, rather than the CA that previously issued the certificate for which revocation is being sought.) Would you then advocate that if the validation can succeed -- save for the CAA mismatch -- that this be regarded as sufficient evidence to revoke? That probably deserves some careful thought. In any event, proof of ability to modify the authoritative DNS over each label in the certificate should almost certainly suffice to revoke a previously issued certificate that relied exclusively upon just about any other sort of domain validation. ___ 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: Namecheap refused to revoke certificate despite domain owner changed
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 Sent: Friday, June 1, 2018 4:08 PM To: Jeremy Rowley Cc: r...@sleevi.com; Wayne Thayer ; Jakob Bohm ; mozilla-dev-security-policy 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 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 mailto:r...@sleevi.com> > Sent: Friday, June 1, 2018 2:51 PM To: Jeremy Rowley mailto:jeremy.row...@digicert.com> > Cc: Wayne Thayer mailto:wtha...@mozilla.com> >; Jakob Bohm mailto:jb-mozi...@wisemo.com> >; mozilla-dev-security-policy 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 mailto:dev-security-policy@lists.mozilla.o
Re: Namecheap refused to revoke certificate despite domain owner changed
On Fri, Jun 1, 2018 at 2:38 PM, Jeremy Rowley via dev-security-policy < 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. > > I agree that it would be forensically interesting to have that data available in the certificate. I question whether a policy of using only the same method of demonstrating control anew is appropriate as a policy for granting revocation. There is a hierarchy of supremacy in domain validation. The party controlling the NS delegations from the registry has absolute precedence over the present effective DNS server administrator, should they choose to flex it. The party immediately in effective control of the authoritative DNS takes precedence over a website admin within the domain. Consider that now current CAA records and policy (for good cause, even) might presently prohibit successful validation via the method previously utilized to acquire the certificate that the current domain holder wishes to have revoked. (Even if only by specifying a new CA, rather than the CA that previously issued the certificate for which revocation is being sought.) Would you then advocate that if the validation can succeed -- save for the CAA mismatch -- that this be regarded as sufficient evidence to revoke? That probably deserves some careful thought. In any event, proof of ability to modify the authoritative DNS over each label in the certificate should almost certainly suffice to revoke a previously issued certificate that relied exclusively upon just about any other sort of domain validation. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 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 > *Sent:* Friday, June 1, 2018 2:51 PM > *To:* Jeremy Rowley > *Cc:* Wayne Thayer ; 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 > > > > 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> 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 digicert@lists.mozilla.org> On Behalf Of Wayne Thayer via > dev-security-policy > Sent: Friday, June 1, 2018 1:02 PM > To: Jakob Bohm > Cc: mozilla-dev-security-policy 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> wrote: > > > &
RE: Namecheap refused to revoke certificate despite domain owner changed
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 Sent: Friday, June 1, 2018 2:51 PM To: Jeremy Rowley Cc: Wayne Thayer ; Jakob Bohm ; mozilla-dev-security-policy 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 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 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 mailto:jb-mozi...@wisemo.com> > Cc: mozilla-dev-security-policy 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
Re: Namecheap refused to revoke certificate despite domain owner changed
In light of the limited visibility of WHOIS, Wayne's suggestion of "... allow anyone to revoke by proving that they control the domain name using one of the BR 3.2.2.4 methods" is preferable as it is a bit more encompassing rather than restricting to to same validation process. This also supports the idea of transparency around revocation processes. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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> 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 digicert@lists.mozilla.org> On Behalf Of Wayne Thayer via > dev-security-policy > Sent: Friday, June 1, 2018 1:02 PM > To: Jakob Bohm > Cc: mozilla-dev-security-policy 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> 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 > 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
RE: Namecheap refused to revoke certificate despite domain owner changed
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 On Behalf Of Wayne Thayer via dev-security-policy Sent: Friday, June 1, 2018 1:02 PM To: Jakob Bohm Cc: mozilla-dev-security-policy 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> 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 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: 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> 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 https://lists.mozilla.org/listinfo/dev-security-policy
Re: Namecheap refused to revoke certificate despite domain owner changed
On 01/06/2018 06:22, Richard S. Leung wrote: I'm not sure if this is the appropriate place to post this topic, but I felt like this is important. I bought myself a new domain this month, and found out that there is a 3-year SSL certificate valid for my domain via crt.sh. Naturally I contacted Comodo SSL Abuse Dept. and got redirected to the reseller - Namecheap, after reaching out to Namecheap they insisted that as long as I issued a new certificate, the valid certificate that the former domain owner had will have no power whatsoever ( which is not true ). Quote: ``` Hello Richard! Thank you for clarifying. Regretfully, revocation can only be done with the authorization of certificate owner (i.e. the same details are required for it). The certificate in question is not installed on your hosting, so it will not affect your domain name any way. Unless the person with the access to the certificate hacks your hosting access, he will not be able to use it. As the extra measure, you can also prohibit that certificate usage with CAA DNS record or HPKP header. ``` Even after ticket escalation, they're just re-assuring me that MITM somehow will not exist as long as I set up a new SSL cert and "there is no need to worry about the security of your website and the information transmitted via Internet". So, according to Namecheap's statement, Wosign accident is just a fraud and people obtained github.com's certificate will do absolutely no harm to Github. I will post the whole reply Namecheap sent me if someone requested. 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. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
