Re: Financial incentive against security ( was Re: [EXTERNAL] Recent Entrust Compliance Incidents)
On Sun, Jun 9, 2024 at 3:34 PM Paul Wouters wrote: > On Jun 8, 2024, at 23:53, Mike Shaver wrote: > > The CA’s primary responsibility is to the web’s users, not to its > customers. > > That is an interesting view, possibly not shared by its shareholders or > the legal framework of the countries they operate in. > If you have a different view of the BRs to which Entrust and other CAs have committed, or how they conflict in a concrete way with other legal frameworks, then that would be a fine thing to discuss with details in another thread here or perhaps on the CCADB list. I don’t know what they tell their shareholders, but that’s also not my problem. They don’t have to be in this business, however we got to this situation historically; I think we may well find out that the web can operate just fine without Entrust acting in this capacity at all. There are many technology businesses which are successful even with the existence of non-profit or similar competition. CAs are not owed a profitable business, especially not at the expense of the integrity of the web’s critical, fragile PKI. I don’t see how using the DNS and a registrar (instead of a TLS handshake and a root CA) to distribute service identity information fundamentally changes the economics or pressures, but I’m happy to be pointed to something if you think it’s germane to the discussion of how we want CAs to create, or not create, incentives related to automation and certificate agility. Again, perhaps a topic more suited to the CCADB list than to this branch of a discussion of Entrust’s behaviour. Mike -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZquGfD6c48rijU%3DH%3DQ7f2yJt3eEuXzo9CNzw-skxfGY_dw%40mail.gmail.com.
Re: Financial incentive against security ( was Re: [EXTERNAL] Recent Entrust Compliance Incidents)
Apologies, I somehow managed to send white-on-white HTML from gmail mobile
and I honestly have no idea how.
On Sat, Jun 8, 2024 at 9:48 PM Jeffrey Walton wrote:
> I would caution against that. Effectively, Mozilla would be fiddling
> with the market. The market should be the one to punish (or reward)
> Entrust for the premiums on manual issuance, not Mozilla. When
> subscribers get tired of paying too much for the service, the customer
> will go elsewhere.
Hey, uh, yeah…Mozilla sort of exists to “fiddle with the market” in ways
that it feels protect the web’s users from the direction that The Market
might otherwise take. It’s sort of “their thing”.
But that rather jarring dissonance aside, nobody is objecting to premiums
on manual issuance. It is precisely the opposite: it is an objection to
charging Subscribers *extra* for using *automated* tools that make the web
safer (and which indeed should be cheaper for the CA to operate than a
manual process, but you know how it is with rent seeking).
The CA’s primary responsibility is to the web’s users, not to its
customers. They all know this. It can require that they not always optimize
for short-term business outcomes, but if they are not comfortable with that
*very* explicit tension, then this is not an appropriate business for them.
> In my mind's eye, there are two things to observe. First is the
> CA/Browser Standards ("what we do"), and second is the CA Operating
> Procedures ("how we do it").
I guess that is a way that these things could have evolved in a parallel
universe, but you have perhaps noticed that the BRs already have many
directions as to how things must be done. The BRs are in fact growing more
such directions over time as it becomes increasingly clear that not all CAs
can be trusted to do the things that are best for the health of the WebPKI;
see the active discussion about linting practices in the SCWG, for example.
Mike
--
You received this message because you are subscribed to the Google Groups
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqsht5cWiudPMaV6VMDvp8jgO6qPnvr_U-KoXVfp%2BfWwGQ%40mail.gmail.com.
Re: Financial incentive against security ( was Re: [EXTERNAL] Recent Entrust Compliance Incidents)
On Sat, Jun 8, 2024 at 9:48 PM Jeffrey Walton wrote:
> I would caution against that. Effectively, Mozilla would be fiddling
> with the market. The market should be the one to punish (or reward)
> Entrust for the premiums on manual issuance, not Mozilla. When
> subscribers get tired of paying too much for the service, the customer
> will go elsewhere.
Hey, uh, yeah…Mozilla sort of exists to “fiddle with the market” in ways
that it feels protect the web’s users from the direction that The Market
might otherwise take. It’s sort of “their thing”.
But that rather jarring dissonance aside, nobody is objecting to premiums
on manual issuance. It is precisely the opposite: it is an objection to
charging Subscribers *extra* for using *automated* tools that make the web
safer (and which indeed should be cheaper for the CA to operate than a
manual process, but you know how it is with rent seeking).
The CA’s primary responsibility is to the web’s users, not to its
customers. They all know this. It can require that they not always optimize
for short-term business outcomes, but if they are not comfortable with that
*very* explicit tension, then this is not an appropriate business for them.
In my mind's eye, there are two things to observe. First is the
> CA/Browser Standards ("what we do"), and second is the CA Operating
> Procedures ("how we do it").
I guess that is a way that these things could have evolved in a parallel
universe, but you have perhaps noticed that the BRs already have many
directions as to how things must be done. The BRs are in fact growing more
such directions over time as it becomes increasingly clear that not all CAs
can be trusted to do the things that are best for the health of the WebPKI;
see the active discussion about linting practices in the SCWG, for example.
Mike
--
You received this message because you are subscribed to the Google Groups
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqvO%3DtCg3E0BGm-D%2Bo6AMnbuaEH0ZatG9PPmfdoYUjMKjQ%40mail.gmail.com.
Re: Financial incentive against security ( was Re: [EXTERNAL] Recent Entrust Compliance Incidents)
On Sat, Jun 8, 2024 at 6:15 PM Watson Ladd wrote:
>
> On Sat, Jun 8, 2024 at 2:15 PM Mike Shaver wrote:
> >"It would mean that revenue from the financial disincentive that Entrust
> >puts in place against Subscriber automation (I believe it's called
> >"SUB-PKI-CEG-ACME")"
>
> So for four years, while Entrust told us it was working to get its
> subscribers to automate, it was using this as a revenue opportunity
> thus continuing manual processes? There is no way to reconcile this
> with any sort of commitment here on Entrusts part to getting
> subscribers to automate.
>
> Could Mozilla update the root store policy to make clear that
> improvements like ACME shouldn't be extra cost items but instead
> considered part of the service provided to customers.
I would caution against that. Effectively, Mozilla would be fiddling
with the market. The market should be the one to punish (or reward)
Entrust for the premiums on manual issuance, not Mozilla. When
subscribers get tired of paying too much for the service, the customer
will go elsewhere.
In my mind's eye, there are two things to observe. First is the
CA/Browser Standards ("what we do"), and second is the CA Operating
Procedures ("how we do it"). The Browsers and collective CA's should
focus on the standard (what should be done), and each individual CA
should focus on the implementation (how it is done). The Forum should
not meddle in everyday affairs of a particular CA.
I understand the community wishes to punish Entrust for its chronic
problems. The CA/Browser Forum do not have tools for that, sans
delisting a particular CA. Maybe the CA/Browser Forum needs to adopt
some punishments, like forbidding a CA from issuing OV certificates or
EV certificates for a specified period of time, like a year. Or forbid
the CA from issuing other types of certificates, like S/MIME and code
signing certificates. The year embargo and lost revenue should be
enough of a haircut to get the CA to comply. If a CA continues to defy
the Forum, then delist the CA. There is plenty of competition in the
marketplace, so any particular CA will not be missed.
And remember, there are three parties in the ecosystem. The Browsers
and CA's are only two of them. There are also 5.35 billion relying
parties who use the internet. If the Forum wishes to acknowledge the
interests of the 5.35 billion internet users, then maybe removing
Entrust would be the best course of action. That's because Entrust
only seems to care about itself and its subscribers. It does not seem
to care about the the Forum, the standards produced by the Forum, or
the relying parties. Entrust has lost the trust of the community, and
that is the only commodity that matters to the relying parties.
Jeff
--
You received this message because you are subscribed to the Google Groups
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAH8yC8%3DEqbCxtp8yc5GRS6kxBPrnxy0J3mMZUg3cX1tSjhZ%3DRQ%40mail.gmail.com.
Re: Financial incentive against security ( was Re: [EXTERNAL] Recent Entrust Compliance Incidents)
On Sat, Jun 8, 2024 at 6:29 PM Paul Wouters wrote: > > > On Jun 8, 2024, at 18:16, Watson Ladd wrote: > > > > > > Could Mozilla update the root store policy to make clear that > > improvements like ACME shouldn't be extra cost items but instead > > considered part of the service provided to customers. > > I don’t have an opinion on this but as someone who at $dayjob has been > forced to request non-acme certificates manually, let me assure you that > any vendor requiring me to do that quickly gets pulled in the “vendors to > migrate away from” list. Any CA preferring manual issuance over automated > issuance is going to find itself out of business soon (as are vendors > providing web services requiring their customers to send them certs once a > year manually while promising to support acme “soon”) I guess that’s a nice assurance, but what does “soon” mean? July? Are you buying enough certs to swing the economics of a major CA? The problem right now is Subscribers who *don’t* want to adopt automation, perhaps in part because Entrust would charge them extra for it. They are the excuse being used too frequently for the dereliction of duty. Mike -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqu0gZvsUZhbh4rnRHdKEuK3FqenSZ-D-Tyu0wQHp3aB7g%40mail.gmail.com.
Re: Financial incentive against security ( was Re: [EXTERNAL] Recent Entrust Compliance Incidents)
On Sat, Jun 8, 2024 at 6:15 PM Watson Ladd wrote: > On Sat, Jun 8, 2024 at 2:15 PM Mike Shaver wrote: > >"It would mean that revenue from the financial disincentive that Entrust > puts in place against Subscriber automation (I believe it's called > "SUB-PKI-CEG-ACME")" > > So for four years, while Entrust told us it was working to get its > subscribers to automate, it was using this as a revenue opportunity > thus continuing manual processes? There is no way to reconcile this > with any sort of commitment here on Entrusts part to getting > subscribers to automate. I find it hard to come to any other interpretation of the facts. Could Mozilla update the root store policy to make clear that > improvements like ACME shouldn't be extra cost items but instead > considered part of the service provided to customers. I think that would be an exceedingly reasonable change for Mozilla to make to its root store policy, personally. Mike -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqvHZ31h%2BYBbUAK8yJ69TX7E02M%2Bz_DTyxp-%2BFP_K9nS%3Dw%40mail.gmail.com.
Financial incentive against security ( was Re: [EXTERNAL] Recent Entrust Compliance Incidents)
On Sat, Jun 8, 2024 at 2:15 PM Mike Shaver wrote: >"It would mean that revenue from the financial disincentive that Entrust puts >in place against Subscriber automation (I believe it's called >"SUB-PKI-CEG-ACME")" So for four years, while Entrust told us it was working to get its subscribers to automate, it was using this as a revenue opportunity thus continuing manual processes? There is no way to reconcile this with any sort of commitment here on Entrusts part to getting subscribers to automate. Could Mozilla update the root store policy to make clear that improvements like ACME shouldn't be extra cost items but instead considered part of the service provided to customers. Sincerely, Watson Ladd -- Astra mortemque praestare gradatim -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CACsn0c%3Dgnj7kRRsacN5u%3D%2BGpX2cBTxcEtY8mNRJEV5rmcUxYZw%40mail.gmail.com.
Re: [EXTERNAL] Recent Entrust Compliance Incidents
On Sat, 11 May 2024 at 15:04, 'Chris Bailey' via dev-security-policy@mozilla.org wrote: > To that end, I want to confirm our intent to provide a full written > response to you and the community prior to June 7. > > o_o > a full written response to you and the community prior to June 7. > > o_O > prior to June 7 > O___O Date: Fri, 7 Jun 2024 12:53:10 -0700 (PDT) From: "'Bruce Morton' via dev-security-policy@mozilla.org" To: "dev-security-policy@mozilla.org" Cc: Ben Wilson Subject: Re: Recent Entrust Compliance Incidents In another context, I would think this to not even be worth joking about, but here it's just the cherry on the top of this whole process. I have time booked this week to go through the report in more detail (every time I start I turn over another thing that is wrong? it's fractal) but I have to say, now that we've reached the end of this part of the process, that I find Entrust's response--in specific and in general--to be well beneath not only the expectations but indeed the mere *dignity* of the Mozilla root program process, the CA/BF commitments, and the trusted role that Entrust seems to so arrogantly believe cannot be lost. I am generally known as a pretty charitable person, and in the mists of time when I was responsible for the Mozilla root CA process I very often advocated or outright decided in favour of using incidents as a tool for learning far beyond being a tool for culling underperforming CAs from our root store. Even at the point at which Ben posted the (extremely understated) message beginning this thread, I had hoped that we would see Entrust wake up from its long operational-quality slumber. I had hoped, sincerely, that Entrust would provide plans that were transparent, concrete, thorough, and sufficiently evident of meaningful reflection that the response would be celebrated as an improvement in the health of the WebPKI. It would mean that revenue from the financial disincentive that Entrust puts in place against Subscriber automation (I believe it's called "SUB-PKI-CEG-ACME") might in some small way be put towards strengthening the integrity of the web's security. I was bewildered by the non-responses that kept appearing in the bugs, but honestly I'm a sucker so I remained hopeful. There were VPs involved, Entrust values its security brand so much, their history is so long (I was doing infosec in the Ottawa area in the early 90s)--they were going to come through now that it had been made so abundantly clear that things were structurally broken. Sadly, I then opened the response posted by Bruce. When I first read the CPS URI incident, it seemed that Entrust thought that the Mozilla root community wasn't watching them. (To be sure, there had been some evidence in the preceding 4 years that this was the case.) When the demeanour of Entrust's responses changed immediately after Ryan Dickson of the Chrome Root Program entered the bug, it made me feel that Entrust thought that the Mozilla root program and community didn't matter, and that their commitments to that program were not meaningful. When the third spokesperson, of increasing seniority, restated Entrust's earnestness and pedigree without any actual concrete, measurable commitments, I started to suspect that Entrust thought that they could just "post through it", as the kids say. But when I read this report, and especially when I compare it to the exceptionally clear request from Ben in his original message, I can only conclude that Entrust believes that this community and its participants are in fact medically-grade stupid. I honestly hope that someone there is ashamed of this. Mike -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqtWvCAGMv97b5eJK_XqajGuAbhVFq_AUX85CxAZXyDWkg%40mail.gmail.com.
Re: [EXTERNAL] Recent Entrust Compliance Incidents
To Ben Wilson and the Mozilla Community: I want to acknowledge your letter and the input from you and the community. We agree that we have go-forward opportunities to improve. To that end, I want to confirm our intent to provide a full written response to you and the community prior to June 7. Until then, please contact me directly with additional questions or feedback. Sincerely, Chris Bailey VP-Digital Certificates Entrust From: 'Ben Wilson' via dev-security-policy@mozilla.org Date: Tuesday, May 7, 2024 at 10:59 AM To: dev-secur...@mozilla.org Subject: [EXTERNAL] Recent Entrust Compliance Incidents Dear Mozilla Community, Over the past couple of months, a substantial number of compliance incidents have arisen in relation to Entrust. We have summarized these recent incidents in a dedicated wiki page: https: //wiki. mozilla. org/CA/Entrust_Issues. Dear Mozilla Community, Over the past couple of months, a substantial number of compliance incidents have arisen in relation to Entrust. We have summarized these recent incidents in a dedicated wiki page: https://wiki.mozilla.org/CA/Entrust_Issues<https://urldefense.com/v3/__https:/wiki.mozilla.org/CA/Entrust_Issues__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmM8uUFZ84$>. In brief, these incidents arose out of certificate mis-issuance due to a misunderstanding of the EV Guidelines, followed by numerous mistakes in incident handling (including a deliberate decision to continue mis-issuance), which have been compounded by a failure to remediate the issues in a timely fashion in line with well-established norms and root store requirements. Our preliminary assessment of these incidents is that while they were relatively minor initially, the poor incident response has substantially aggravated them and the progress towards full remediation remains unacceptably slow. This is particularly disappointing in light of previous incidents in 2020 (#1651481<https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1651481__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMYStPTzU$> and #1648472<https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1648472__;!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMQsOKu7I$>), which arose out of similar misunderstandings of the requirements, similar poor decision-making in the initial response, and lengthy remediation periods that fell well below expectations. Entrust gave commitments<https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1651481*c17__;Iw!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMgQVGatQ$> in those bugs to address the root problems through process improvements, and it is concerning to see so little improvement 4 years later. In light of these recent incidents, we are requesting that Entrust produce a detailed report of them. This report should cover in detail: * The factors and root causes that lead to the initial incidents, highlighting commonalities among the incidents and any systemic failures; * Entrust’s initial incident handling and decision-making in response to these incidents, including any internal policies or protocols used by Entrust to guide their response and an evaluation of whether their decisions and overall response complied with Entrust’s policies, their practice statement, and the requirements of the Mozilla Root Program; * A detailed timeline of the remediation process and an apportionment of delays to root causes; and * An evaluation of how these recent issues compare to the historical issues referenced above and Entrust’s compliance with its previously stated commitments. Finally, Entrust’s report should include a detailed proposal on how it plans to address the root causes of these issues. In light of previous guarantees<https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1651481*c17__;Iw!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywte2Ejft_WUF1bIuBSaVRS-KbyuhYwD5le7_FmgsDNT5i-TVUk08mKmMgQVGatQ$> given by Entrust in 2020 to ensure speedy remediation in future incidents, this proposal should include: * Clear and concrete steps that Entrust proposes to take to address the root causes of these incidents and delayed remediation; * Measurable and objective criteria for Mozilla and the community to evaluate Entrust’s progress in deploying these solutions; and * A timeline for which Entrust will commit to meeting these criteria. We strongly recommend that Entrust go beyond their existing commitment<https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1886532*c0__;Iw!!FJ-Y8qCqXTj2!YIVy3FMEgzSPV2Nu5hQyEdywVIGxKU-_4IcqNMzywt
