Re: Terms and Conditions that use technical measures to make it difficult to change CAs
On Thu, Apr 16, 2020 at 4:09 PM Tim Hollebeek wrote: > On the other hand, for example in Shanghai, some > have argued that there is nothing wrong with a CPS that does not disclose > anything > about how CAs implement any of the policy requirements. Understandably, it's a spectrum. For these sorts of implementation questions, I think this is really an area where the Detailed Control Reporting ( see https://cabforum.org/2020/03/20/minutes-for-ca-browser-forum-f2f-meeting-49-bratislava-19-20-february-2020/#WebTrust-Update for an example) would be helpful here. In the end, the transparency is about finding the right level of relevant information that's useful. Complete transparency can be useful, but can also hide shenanigans in the information overload. We see this regularly with CP/CPS reviews, in which dozens of CPSes may have subtle and ill-defined interactions that are only obvious after hundreds of pages of reading. Figuring out how to better surface these, through both normative requirements and standardized disclosures, is the approach. > I would personally find it very unfortunate if the trend continues, and we > have > increasingly vacuous CPSs that contain no relevant information. But in the > absence > of requirements to disclose relevant practices, I'm not surprised that that's > a trend > that has been embraced by some CAs. Figuring out the right transparency for the original problem on the thread is difficult. Do you think the steps I proposed work? I'm not confident they do, but I think they might be a useful stepping stone. Given DigiCert originally raised this, perhaps you have suggestions for possible means of unambiguously getting disclosure around revocation practices and policies? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Terms and Conditions that use technical measures to make it difficult to change CAs
Generally, I'm in favor of transparency requirements, and many of Ryan's ideas would be useful or interesting to pursue. Transparency is often the first and best step towards improving business practices. And the entire purpose of a CPS is to disclose the business practices that implement a particular certificate policy (e.g. the Baseline Requirements). So I think it's entirely appropriate that Mozilla and other root policies consider and implement disclosure policies that mandate that certain security-relevant business practices be disclosed. Such requirements have even appeared in the Baseline Requirements from time to time, and should continue to do so. Unfortunately, some CAs have chosen to use CPSs that have very little content other than "we comply with the baseline requirements". Root programs have taken a variety of stances on this in the past. For example, Mozilla has required CAs to actually disclose which validation methods they use, as opposed to which they _might_ use (all of them!). On the other hand, for example in Shanghai, some have argued that there is nothing wrong with a CPS that does not disclose anything about how CAs implement any of the policy requirements. I personally find myself in the transparency camp, and would prefer that when the details of how a CA complies with a particular requirement is security relevant, it would be an improvement if those details were disclosed. But that's in conflict with the "Default Non-disclose" policy that many people, both on the root program and CA side, have advocated for. I would personally find it very unfortunate if the trend continues, and we have increasingly vacuous CPSs that contain no relevant information. But in the absence of requirements to disclose relevant practices, I'm not surprised that that's a trend that has been embraced by some CAs. -Tim > -Original Message- > From: dev-security-policy > On Behalf Of Robin Alden via dev-security-policy > Sent: Tuesday, April 14, 2020 8:13 PM > To: r...@sleevi.com > Cc: Mozilla > Subject: RE: Terms and Conditions that use technical measures to make it > difficult to change CAs > > > .. There’s plenty of precedent in having Root Policy or the Baseline > > Requirements require a CP/CPS explicitly state something; examples > > such as the CAA domain name, the problem reporting mechanism and > > contact address, and compliance to the latest version of the BRs. > > > > If we apply that idea here, it might make sense to require the CA’s > > CP/CPS make a clear and unambiguous statement about whether or not > > they engage in X as a practice. I’m not quite sure what X should say, > > but the idea is that it would be transparent to Relying Parties > > wanting to evaluate a CA, as well as to User Agents when evaluating > > whether or not a given CA's practices provide a service relevant to > > user's of that software product. While it's conceivable that sites are > > already having these practices disclosed to them, having a consistent > > and public disclosure would help bring transparency into what CAs are > > engaging in this practice, and which have committed not to use > > revocation in this way, which can help make it easier to compare the > > trustworthiness of CAs up-front. > > I am ambivalent to the idea of having a list of business practices, presumably > over and above those required in law, that CAs must publish to the > community. > I suppose that CAs' existing contractual terms, particularly for large > subscribers such as enterprise organizations, are negotiated between the > two parties and so are typically known only to the CA and to the subscriber. > For other individual subscribers a standard subscriber agreement published in > advance more likely applies. > I'm sure that some subscribers will be happy to have additional oversight of > contractual terms rather than rely on their own reading and understanding of > the contract they sign, while others would not choose it, were that choice > available to them. > > Paraphrasing Jeremy's answer, actions speak louder than words. > Are these things that have been done, or things that contracts permit? > Is it words or actions that you seek to restrict? > > Kathleen posted this on the Mozilla PKI Policy github. > https://github.com/mozilla/pkipolicy/issues/208 > saying > > ".. some CAs have Terms and Conditions which say that if the customer > > moves to (or even tries to use) another CA, all of their certificates > > will be revoked. Enforcing all revocations (independent of reason) > > supports this bad behavior by CAs, helping them to hold their > > customers hostage. But if
Re: Terms and Conditions that use technical measures to make it difficult to change CAs
On Tue, Apr 14, 2020 at 8:13 PM Robin Alden wrote: > I am ambivalent to the idea of having a list of business practices, > presumably over and above those required in law, that CAs must publish to > the community. I know it was more an aside, but I’m not sure I follow what you mean by “over an above”. Was that meant to suggest those required in law need not be documented? I suppose that CAs' existing contractual terms, particularly for large > subscribers such as enterprise organizations, are negotiated between the > two parties and so are typically known only to the CA and to the > subscriber. For other individual subscribers a standard subscriber > agreement published in advance more likely applies. > I'm sure that some subscribers will be happy to have additional oversight > of contractual terms rather than rely on their own reading and > understanding of the contract they sign, while others would not choose it, > were that choice available to them. Indeed, there’s real trade-offs here. Browsers selection of which CAs to trust is based on how well those CAs align with the browsers’ goals and needs. This is why we don’t just trust every Average Joe who knows how to run openssl via the cmdline, and why the Mozilla policy exists. There are two main ways to ensure that CAs’ actions are aligned with browsers’ needs: requirements & prohibitions on certain actions (e.g. browser policies, audit criteria, guidelines like the Baseline Requirements) and transparency (via CT, via CP/CPS, etc) Paraphrasing Jeremy's answer, actions speak louder than words. > Are these things that have been done, or things that contracts permit? > Is it words or actions that you seek to restrict? Why does this distinction matter? The reality is outright restricting either and/or both is challenging on a number of dimensions, least of all being that we continue to have trouble capturing basic technical requirements clearly and unambiguously (or at least, creative interpretations about ambiguity). The first step is to transparency to try and quantify this problem. Simplistically, the life of a certificate today is either: > Issue - use - expire; or > Issue - use - revoke, > and in each case no further management of the certificate's state is > possible by either the CA or the subscriber after the terminal event. > However, if there are 'bad' revocations that will be ignored the life-cycle > gets another step under certain circumstances: > Issue - use - 'bad' revocation (ignored) - use - 'good' revocation. > This requires both that the user is able to request a second revocation > for a different reason after an earlier revocation, and also that the CA > has further obligations to take actions concerning this certificate after > it had been initially revoked, e.g. re-revoking if misissuance or > subscriber key compromise were detected. I mean, this is spot on the problem. The certificate lifecycle between different parties is misaligned, and this is an area where existing technologies don’t have easy answers. This isn’t a problem unique to CAs either; consider a Root Program A that explicitly requires revocation for Reason X, but a different Root Program B does not want to have certificates and sites stop working just Root Program A doesn’t like the certificate. Presumably, if a UA is going to define policies, such as around the reason codes to use and how and when they’re used, then it’s going to have to require that the CA be responsible for that certificate unless and until it hits one of those terminal reasons. These problems are “solvable”, but take time. Having more robust expressions for revocation is an approach worth exploring. Legacy clients would still treat them as absolutely rejected, but modern clients responding to modern problems can use these modern solutions. Regardless, starting work on a normative profile for CRL Reasons to reduce ambiguity seems... useful? If only to flesh out precisely the problem space involved where a CA has the near-universal power (when revocation checking is supported) to rescind a certificate arbitrarily, contrary to the browser, user, and site needs and desires. Having that sort of choke point, which spans a variety of software clients, and for which limited alternatives exist by necessity, seems bad for all. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Terms and Conditions that use technical measures to make it difficult to change CAs
> .. There’s plenty of precedent in having Root Policy or the > Baseline Requirements require a CP/CPS explicitly state something; > examples such as the CAA domain name, the problem reporting mechanism > and contact address, and compliance to the latest version of the BRs. > > If we apply that idea here, it might make sense to require the CA’s > CP/CPS make a clear and unambiguous statement about whether or not > they engage in X as a practice. I’m not quite sure what X should say, > but the idea is that it would be transparent to Relying Parties > wanting to evaluate a CA, as well as to User Agents when evaluating > whether or not a given CA's practices provide a service relevant to > user's of that software product. While it's conceivable that sites are > already having these practices disclosed to them, having a consistent > and public disclosure would help bring transparency into what CAs are > engaging in this practice, and which have committed not to use > revocation in this way, which can help make it easier to compare the > trustworthiness of CAs up-front. I am ambivalent to the idea of having a list of business practices, presumably over and above those required in law, that CAs must publish to the community. I suppose that CAs' existing contractual terms, particularly for large subscribers such as enterprise organizations, are negotiated between the two parties and so are typically known only to the CA and to the subscriber. For other individual subscribers a standard subscriber agreement published in advance more likely applies. I'm sure that some subscribers will be happy to have additional oversight of contractual terms rather than rely on their own reading and understanding of the contract they sign, while others would not choose it, were that choice available to them. Paraphrasing Jeremy's answer, actions speak louder than words. Are these things that have been done, or things that contracts permit? Is it words or actions that you seek to restrict? Kathleen posted this on the Mozilla PKI Policy github. https://github.com/mozilla/pkipolicy/issues/208 saying > ".. some CAs have Terms and Conditions which say that if the customer > moves to (or even tries to use) another CA, all of their certificates > will be revoked. Enforcing all revocations (independent of reason) > supports this bad behavior by CAs, helping them to hold their > customers hostage. But if CAs always add the CRLReason for > revocations, we can selectively enforce revocation for certain reasons, > and have varying levels of enforcement (e.g. overridable versus > not-overridable) Enforcing or restricting some revocation reasons is an interesting idea but I think that selective implementation of revocation based on the concept of there being 'good' and 'bad' revocation reasons has an implicit challenge. It changes the certificate life-cycle. Simplistically, the life of a certificate today is either: Issue - use - expire; or Issue - use - revoke, and in each case no further management of the certificate's state is possible by either the CA or the subscriber after the terminal event. However, if there are 'bad' revocations that will be ignored the life-cycle gets another step under certain circumstances: Issue - use - 'bad' revocation (ignored) - use - 'good' revocation. This requires both that the user is able to request a second revocation for a different reason after an earlier revocation, and also that the CA has further obligations to take actions concerning this certificate after it had been initially revoked, e.g. re-revoking if misissuance or subscriber key compromise were detected. Regards Robin Alden Sectigo Limited 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: Terms and Conditions that use technical measures to make it difficult to change CAs
On Mon, Mar 16, 2020 at 5:06 PM Tim Hollebeek via dev-security-policy wrote: > > > > Hello, > > > > I'd like to start a discussion about some practices among other commercial > CAs that have recently come to my attention, which I personally find > disturbing. While it's perfectly appropriate to have Terms and Conditions > associated with digital certificates, in some circumstances, those Terms and > Conditions seem explicitly designed to prevent or hinder customers who wish > to switch to a different certificate authority. Some of the most disturbing > practices include the revocation of existing certificates if a customer does > not renew an agreement, which can really hinder a smooth transition to a new > provider of digital certificates, especially since the customer may not have > anticipated the potential impact of such a clause when they first signed the > agreement. I'm particularly concerned about this behavior because it seems > to be an abuse of the revocation system, and imposes costs on everyone who > is trying to generate accurate and efficient lists of revoked certificates > (e.g. Firefox). > > > > I'm wondering what the Mozilla community thinks about such practices. Thanks for raising this issue! At the core, it seems like the concern being raised is about policies that might limit certificate or ecosystem agility. From discussions around certificate lifetimes, and from CA distrust, we know that agility is one of the most important things to keeping users secure, so it's understandable to be concerned if agility is jeopardized. Such policies have material impact on end-users. As the number of revoked certificates grow, this requires larger CRLs (for systems that use CRLs), or larger databases/updates for browser-provided systems, like Mozilla's CRLLite or Apple's valid. For end-users, because revocation is treated equally, it runs the risk that potential contract or payment disputes become highly visible as revocations, rather than revocations reflecting signals of the site or the CA's trustworthiness. Overall, that seems harmful to users' security and the ecosystem. These policies only seem to matter because of revocation. If user agents did not check revocation, then CAs revoking these certificates would be a non-issue, because there would be no disruption. However, because some user agents check revocation, they end up giving the CA even more control over the end-user experience, and this allows CAs to cause disruptions that the user agents and end-users are harmed by, rather than benefit from. Perhaps it makes sense to take the approach of the Baseline Requirements and Root Store Policies. The BRs disclose a number of situations where the CA MUST NOT issue a certificate, such as not having validated a domain correctly, as well as define a limited subset of what a CA MAY issue, such as particular optional extensions or name fields. Anything not in those lists are also expected as MUST NOT. It may make sense to take the same approach with revocation, such as by describing a set of policies where a CA MUST revoke a certificate (as is done in 4.9.1.1), a set of scenarios where a CA MAY revoke a certificate, and any reason not on those lists are a MUST NOT. One of the challenges with this is that the BRs require the CA MUST revoke if a Subscriber violates their Subscriber Agreement / Terms of Use. It sounds like CAs are bundling such terms of sale into those Agreements / Terms of Use, so an approach like I just described would not be sufficient. It would be indistinguishable to users / relying parties as a Subscriber who posted their private key publicly (also a violation of the Agreement). In order to deal with this, it's probably necessary to go further: to describe the CRL/OCSP reason codes that MUST or MAY be used, and revocations that don't fall into those enumerated lists MUST NOT use those reason codes. This would allow user agents/relying parties to be more selective when they honor CA-indicated revocation data. For example, if it was possible for user agents to distinguish when the Subscriber violated one of the BR-defined portions of the Subscriber Agreement, versus the CA-defined portion of the Subscriber Agreement, they might choose to only respect the BR-defined reasons. This would also provide tools to limit how much data needs to be sent to all of a browser’s users, when using browser-distributed revocation mechanisms, by allowing the browser to focus on the revocations it’s most concerned about. These ideas are far from perfect, but try to address the challenge the same way that many of the PKI problems have been tackled: trying to bring transparency into CAs’ practices, and through that, greater security and accountability. These ideas are intentionally simple, and avoid unnecessarily complex schemes like revocation transparency. Such systems would only be needed if we expect CAs to be intentionally misleading in revocations, and if that was the case, that seems mu
Re: Terms and Conditions that use technical measures to make it difficult to change CAs
This is an abusive practice that tends to injure the operation of the internet, particularly by encouraging victims to operate sites without authentication and encryption in the interregnum between revocation and the acquisition of a new cert. It also needlessly raises the cost to operate a site, and possibly violates antitrust and/or restraint-of-trade laws [1]. Mozilla should consider advocating the creation of an "abusive practices that could lead to distrust" section in the BRs, which should enumerate this practice. -R [1] Consult your lawyer for legal advice. On 3/16/2020 2:06 PM, Tim Hollebeek via dev-security-policy wrote: Hello, I'd like to start a discussion about some practices among other commercial CAs that have recently come to my attention, which I personally find disturbing. While it's perfectly appropriate to have Terms and Conditions associated with digital certificates, in some circumstances, those Terms and Conditions seem explicitly designed to prevent or hinder customers who wish to switch to a different certificate authority. Some of the most disturbing practices include the revocation of existing certificates if a customer does not renew an agreement, which can really hinder a smooth transition to a new provider of digital certificates, especially since the customer may not have anticipated the potential impact of such a clause when they first signed the agreement. I'm particularly concerned about this behavior because it seems to be an abuse of the revocation system, and imposes costs on everyone who is trying to generate accurate and efficient lists of revoked certificates (e.g. Firefox). I'm wondering what the Mozilla community thinks about such practices. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Terms and Conditions that use technical measures to make it difficult to change CAs
Yes - please share the details with me as I am very surprised to hear that. I know the DigiCert agreements I've seen don't permit revocation because of termination so whoever (if anyone) is saying that is contradicting the actual agreement. Threatening revocation because of termination or revoking upon termination also violates our internal policies - certs issued are good for the duration of the cert, even if the console agreement terminates. Since I'm sure we haven't actually revoked because of termination, please send me the details of the threats and I'll take care of them. -Original Message- From: dev-security-policy On Behalf Of Nick France via dev-security-policy Sent: Tuesday, March 17, 2020 11:27 AM To: Mozilla Subject: Re: Terms and Conditions that use technical measures to make it difficult to change CAs On Monday, March 16, 2020 at 9:06:33 PM UTC, Tim Hollebeek wrote: > Hello, > > > > I'd like to start a discussion about some practices among other > commercial CAs that have recently come to my attention, which I > personally find disturbing. While it's perfectly appropriate to have > Terms and Conditions associated with digital certificates, in some > circumstances, those Terms and Conditions seem explicitly designed to > prevent or hinder customers who wish to switch to a different > certificate authority. Some of the most disturbing practices include > the revocation of existing certificates if a customer does not renew > an agreement, which can really hinder a smooth transition to a new > provider of digital certificates, especially since the customer may > not have anticipated the potential impact of such a clause when they > first signed the agreement. I'm particularly concerned about this > behavior because it seems to be an abuse of the revocation system, and > imposes costs on everyone who is trying to generate accurate and efficient > lists of revoked certificates (e.g. Firefox). > > > > I'm wondering what the Mozilla community thinks about such practices. > > > > -Tim Tim, Completely agree on your statement that it's a disturbing practice. We've sadly come across it several times in the past 12-18 months, leading to problems for the customer and of course lost business for us as they inevitably decide to remain with the incumbent CA when faced with a hard deadline for certificate revocation - regardless of the natural expiry dates. Your points about the impact and costs to the wider ecosystem ring true, as well. Revocation should not be used to punish those wishing to migrate CAs. We certainly don't do it. More troubling is that each time it's either been mentioned early in discussions or has caused a business discussion to cease at a late stage - it's been DigiCert that was the current CA and they/you participated in this practice of threatening revocation of certificates well before expiry due to contract termination. I have at least 5 major global enterprises that this has happened to recently. Am happy to share more details privately if you wish to discuss. Nick ___ 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: Terms and Conditions that use technical measures to make it difficult to change CAs
On Monday, March 16, 2020 at 9:06:33 PM UTC, Tim Hollebeek wrote: > Hello, > > > > I'd like to start a discussion about some practices among other commercial > CAs that have recently come to my attention, which I personally find > disturbing. While it's perfectly appropriate to have Terms and Conditions > associated with digital certificates, in some circumstances, those Terms and > Conditions seem explicitly designed to prevent or hinder customers who wish > to switch to a different certificate authority. Some of the most disturbing > practices include the revocation of existing certificates if a customer does > not renew an agreement, which can really hinder a smooth transition to a new > provider of digital certificates, especially since the customer may not have > anticipated the potential impact of such a clause when they first signed the > agreement. I'm particularly concerned about this behavior because it seems > to be an abuse of the revocation system, and imposes costs on everyone who > is trying to generate accurate and efficient lists of revoked certificates > (e.g. Firefox). > > > > I'm wondering what the Mozilla community thinks about such practices. > > > > -Tim Tim, Completely agree on your statement that it's a disturbing practice. We've sadly come across it several times in the past 12-18 months, leading to problems for the customer and of course lost business for us as they inevitably decide to remain with the incumbent CA when faced with a hard deadline for certificate revocation - regardless of the natural expiry dates. Your points about the impact and costs to the wider ecosystem ring true, as well. Revocation should not be used to punish those wishing to migrate CAs. We certainly don't do it. More troubling is that each time it's either been mentioned early in discussions or has caused a business discussion to cease at a late stage - it's been DigiCert that was the current CA and they/you participated in this practice of threatening revocation of certificates well before expiry due to contract termination. I have at least 5 major global enterprises that this has happened to recently. Am happy to share more details privately if you wish to discuss. Nick ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Terms and Conditions that use technical measures to make it difficult to change CAs
A customer should able have the choice to change their CA provider without threats of revocation by the CA. It’s definitely an abuse of the revocation function. I do understand terms and conditions are in normal circumstances legally binding once signed by a customer but this practice is abuse of trust between the customer and the CA. The CA is acting in bad faith. I suggest Mozilla to send a strongly worded signed letter to every CAs highlighting the abuse of revocation function and say whoever it is must to stop immediately or face consequences. On Mon, 16 Mar 2020 at 23:51, Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, Mar 16, 2020 at 09:06:17PM +, Tim Hollebeek via > dev-security-policy wrote: > > I'd like to start a discussion about some practices among other > commercial > > CAs that have recently come to my attention, which I personally find > > disturbing. While it's perfectly appropriate to have Terms and > Conditions > > associated with digital certificates, in some circumstances, those Terms > and > > Conditions seem explicitly designed to prevent or hinder customers who > wish > > to switch to a different certificate authority. Some of the most > disturbing > > practices include the revocation of existing certificates if a customer > does > > not renew an agreement, which can really hinder a smooth transition to a > new > > provider of digital certificates, especially since the customer may not > have > > anticipated the potential impact of such a clause when they first signed > the > > agreement. I'm particularly concerned about this behavior because it > seems > > to be an abuse of the revocation system, and imposes costs on everyone > who > > is trying to generate accurate and efficient lists of revoked > certificates > > (e.g. Firefox). > > > > I'm wondering what the Mozilla community thinks about such practices. > > Utterly reprehensible, and should be called out loudly whenever it's found. > > However, it might be tricky for Mozilla itself to create and enforce such a > prohibition, since it gets deep into the relationship between a CA and its > customer. I know there are already several requirements around what must > go > into a Subscriber Agreement in the BRs, etc, but they're a lot narrower > than > a blanket "thou shalt not put anything in there that restricts a customer's > ability to move to a competitor", and a narrow ban on individual practices > would be easily gotten around by a CA that was out to lock in their > customers. > > I recognise that it can be tricky for a CA to (be seen to) criticise their > competitors' business practices, but this really is a case where public > awareness of these kinds of shady practices are probably the best defence > against them. Get enough people up in arms, hopefully hit the shonkster in > the hip pocket, and it'll encourage them to rethink the wisdom of this kind > of thing. > > - Matt > > -- > A polar bear is a rectangular bear after a coordinate transform. > > ___ > 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: Terms and Conditions that use technical measures to make it difficult to change CAs
On Mon, Mar 16, 2020 at 09:06:17PM +, Tim Hollebeek via dev-security-policy wrote: > I'd like to start a discussion about some practices among other commercial > CAs that have recently come to my attention, which I personally find > disturbing. While it's perfectly appropriate to have Terms and Conditions > associated with digital certificates, in some circumstances, those Terms and > Conditions seem explicitly designed to prevent or hinder customers who wish > to switch to a different certificate authority. Some of the most disturbing > practices include the revocation of existing certificates if a customer does > not renew an agreement, which can really hinder a smooth transition to a new > provider of digital certificates, especially since the customer may not have > anticipated the potential impact of such a clause when they first signed the > agreement. I'm particularly concerned about this behavior because it seems > to be an abuse of the revocation system, and imposes costs on everyone who > is trying to generate accurate and efficient lists of revoked certificates > (e.g. Firefox). > > I'm wondering what the Mozilla community thinks about such practices. Utterly reprehensible, and should be called out loudly whenever it's found. However, it might be tricky for Mozilla itself to create and enforce such a prohibition, since it gets deep into the relationship between a CA and its customer. I know there are already several requirements around what must go into a Subscriber Agreement in the BRs, etc, but they're a lot narrower than a blanket "thou shalt not put anything in there that restricts a customer's ability to move to a competitor", and a narrow ban on individual practices would be easily gotten around by a CA that was out to lock in their customers. I recognise that it can be tricky for a CA to (be seen to) criticise their competitors' business practices, but this really is a case where public awareness of these kinds of shady practices are probably the best defence against them. Get enough people up in arms, hopefully hit the shonkster in the hip pocket, and it'll encourage them to rethink the wisdom of this kind of thing. - Matt -- A polar bear is a rectangular bear after a coordinate transform. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy