Terms and Conditions that use technical measures to make it difficult to change CAs

[Tim Hollebeek]

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

[Matt Palmer]

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.

[Burton]

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.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Nick France]

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

[Jeremy Rowley]

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 <dev-security-...@lists.mozilla.org> On Behalf Of Nick France via dev-security-policy
Sent: Tuesday, March 17, 2020 11:27 AM
To: Mozilla <mozilla-dev-s...@lists.mozilla.org>
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:

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

[Ronald Crane]

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.

[Ryan Sleevi]

On Mon, Mar 16, 2020 at 5:06 PM Tim Hollebeek via dev-security-policy
<dev-secur...@lists.mozilla.org> 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 much
more serious a matter.

Related to the idea of transparency, perhaps there are ideas from CAA
that might be useful here. Section 4.9.1 of a CA’s CP/CPS, and of the
Baseline Requirements, are meant to describe exactly the situations
when revocation can occur. However, these sorts of situations may not
be obvious when reading a CA’s CP/CPS, because “The CA is made aware
that a Subscriber has violated one or more of its material obligations
under the Subscriber Agreement or Terms of Use” can cover a multitude
of things. Perhaps, similar to how CAA was implemented, Section 2.2 of
the BRs could be updated to make it clear that CAs MUST also disclose
their Subscriber Agreements and/or Terms of Use in their Repository,
just as they do their CP/CPS. Many CAs already do this as part of
their Repository, but this would make it clear that such documents are
also part of the public basis relying parties use to determine when to
trust a CA.

However, just like how there may be a multitude of CP/CPSes for a
single CA, there might be many different Subscriber Agreements / Terms
of Use, and so such information still might not be obvious or easily
determined. 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.

[Robin Alden]

> .. 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

[Ryan Sleevi]

On Tue, Apr 14, 2020 at 8:13 PM Robin Alden <robin...@sectigo.com> 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.

[Tim Hollebeek]

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 <dev-security-...@lists.mozilla.org>
> On Behalf Of Robin Alden via dev-security-policy
> Sent: Tuesday, April 14, 2020 8:13 PM
> To: ry...@sleevi.com
> Cc: Mozilla <mozilla-dev-s...@lists.mozilla.org>
> 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 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.
>

[Ryan Sleevi]

On Thu, Apr 16, 2020 at 4:09 PM Tim Hollebeek
<tim.ho...@digicert.com> 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?