Re: Recent Entrust Compliance Incidents

[Wayne]

Hi Matt,

You answered my thoughts on BR applicability in your last paragraph. I 
don't mean to say there's a direct element as written being broken, but the 
combination of revocation misuse & misleading certificate lifespan makes it 
hard to take a certificate at face-value.

- Wayne

On Monday, August 5, 2024 at 3:31:50 AM UTC+1 Matt Palmer wrote:

> On Fri, Aug 02, 2024 at 05:43:35AM -0700, Wayne wrote:
> > So in summary: the allegations are true, and there's a direct business
> > model created to allow this to exist alongside the traditional 
> certificates
> > system?
> >
> > Are any other CAs going to be forthcoming on a similar approach, as what 
> is
> > being described is renting certificate lifespan, with hidden cancellation
> > fees. I don't see how this is compatible with the baseline requirements,
>
> I'd appreciate it if you could expand on this point further, as I'm not
> seeing any conflict with the BRs here -- nor do I think that the BRs
> *should* make any stipulations on business models (for both legal and
> practical reasons). As far as revocation reasons go, I believe the BRs
> are a list of "circumstances in which you *must* revoke", they don't
> mandate that certificates *not* be revoked for other reasons.
>
> It appears that there is a level of misunderstanding between what
> Entrust was selling and what customers *thought* they were buying. To
> the degree that the problem was Entrust misrepresenting its products and
> services, then that will (presumably) be ironed out between Entrust and
> its customers, through legal action or otherwise. To the extent that
> the problem was, instead, customers failing to comprehend what Entrust
> was saying, well there's plenty of precedent for *that* in the WebPKI
> (amongst other places).
>
> We've recently seen, with the DigiCert TRO, an ugly consequence of
> customers misunderstanding what was being sold, and I believe that the
> customer in that instance has been generally considered (by the WebPKI
> community) at least partially responsible for not taking the time to
> understand what they were buying. It's difficult, therefore, to
> simultaneously put the blame entirely on Entrust for their customers'
> misunderstanding of the ramifications of what they were buying while
> criticising Alegeus for their similar misunderstanding.
>
> > It is disconcerting that this is phrased as standard operating procedure,
> > and nothing to worry about.
>
> On a personal level, I don't like Entrust's business model here, but
> there are *lots* of things I don't like, and not everything I dislike is
> something that has to be banned (much as I might like it to be).
>
> I will, however, amplify Watson Ladd's comment elsewhere in this thread,
> which I believe is extremely pertinent:
>
> "Let me get this straight: you will not revoke on time when presented
> with a BR violation, making the excuse customers will be
> inconvenienced, run criticial systems yadda yadda. You will revoke
> gratuitously come contract renewal time, and none of the reasons
> listed before matter."
>
> This, to me, is an important thing to bear in mind. It may not be a BR
> violation to revoke for business reasons, but using it as a sales tool
> against potentially the same category of system that was used as a
> defence against the consequences of Entrust's own actions is... not
> great, at the very least.
>
> - Matt
>
>

-- 
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/94a76d41-7cff-45ab-a236-6ac349bf00a6n%40mozilla.org.

Re: Recent Entrust Compliance Incidents

[Matt Palmer]

On Fri, Aug 02, 2024 at 05:43:35AM -0700, Wayne wrote:
> So in summary: the allegations are true, and there's a direct business
> model created to allow this to exist alongside the traditional certificates
> system?
>
> Are any other CAs going to be forthcoming on a similar approach, as what is
> being described is renting certificate lifespan, with hidden cancellation
> fees. I don't see how this is compatible with the baseline requirements,

I'd appreciate it if you could expand on this point further, as I'm not
seeing any conflict with the BRs here -- nor do I think that the BRs
*should* make any stipulations on business models (for both legal and
practical reasons).  As far as revocation reasons go, I believe the BRs
are a list of "circumstances in which you *must* revoke", they don't
mandate that certificates *not* be revoked for other reasons.

It appears that there is a level of misunderstanding between what
Entrust was selling and what customers *thought* they were buying.  To
the degree that the problem was Entrust misrepresenting its products and
services, then that will (presumably) be ironed out between Entrust and
its customers, through legal action or otherwise.  To the extent that
the problem was, instead, customers failing to comprehend what Entrust
was saying, well there's plenty of precedent for *that* in the WebPKI
(amongst other places).

We've recently seen, with the DigiCert TRO, an ugly consequence of
customers misunderstanding what was being sold, and I believe that the
customer in that instance has been generally considered (by the WebPKI
community) at least partially responsible for not taking the time to
understand what they were buying.  It's difficult, therefore, to
simultaneously put the blame entirely on Entrust for their customers'
misunderstanding of the ramifications of what they were buying while
criticising Alegeus for their similar misunderstanding.

> It is disconcerting that this is phrased as standard operating procedure,
> and nothing to worry about.

On a personal level, I don't like Entrust's business model here, but
there are *lots* of things I don't like, and not everything I dislike is
something that has to be banned (much as I might like it to be).

I will, however, amplify Watson Ladd's comment elsewhere in this thread,
which I believe is extremely pertinent:

"Let me get this straight: you will not revoke on time when presented
with a BR violation, making the excuse customers will be
inconvenienced, run criticial systems yadda yadda. You will revoke
gratuitously come contract renewal time, and none of the reasons
listed before matter."

This, to me, is an important thing to bear in mind.  It may not be a BR
violation to revoke for business reasons, but using it as a sales tool
against potentially the same category of system that was used as a
defence against the consequences of Entrust's own actions is... not
great, at the very least.

- Matt

-- 
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/6ad3348e-065b-4753-9e64-7916e73df609%40mtasv.net.

Re: Recent Entrust Compliance Incidents

['Amir Omidi' via dev-security-policy@mozilla.org]

Now that this is being more openly discussed, can someone post a copy of
the letter here? While redacting whatever PII

On Fri, Aug 2, 2024 at 14:05 Watson Ladd  wrote:

> On Fri, Aug 2, 2024 at 5:33 AM 'Bruce Morton' via
> dev-security-policy@mozilla.org 
> wrote:
> >
> > Hi Nick,
> >
> > Thanks for passing on the customer email, we’re following up directly
> there, and as always, we’d recommend that customers directly reach out to
> their account team to discuss their specific needs.
> >
> > That said, we think it would be helpful to share the different
> certificate licensing models we offer and the details of each. Entrust
> broadly offers two models for certificate purchase. The handling of active
> certificates, including revocation, differs based on the model chosen by
> the customer.
> >
> > The first model is what we call “unit based” and is what most would
> consider the historically traditional approach for certificate offers,
> where a customer purchases a certificate for a specific term, that
> certificate is paid for up front, and their license is valid through the
> expiration date of the certificate. After initial issuance only limited
> changes are permitted to the details of the certificate.
> >
> > The second model is what we call “subscription” or “pooling”, and this
> approach allows a customer to have up to a pre-defined number of
> certificates issued and active at any given time during the period of the
> subscription. This approach allows customers the flexibility to issue and
> change certificates as often as necessary as their needs change, including,
> for example, revoking a no-longer needed certificate and issuing a new one
> with new organization information or domains, with no additional charges.
> At the time of renewal, customers can increase or decrease the number of
> certificates that are available under their subscription. If at any time a
> customer chooses to fully stop their subscription, then the license period
> ends, and under the terms of the agreement we reserve the right to revoke
> any unexpired certificates.
> >
> > So, depending on the model selected by the customer up front, the
> approach differs on how unexpired certificates are handled upon
> termination, and both are addressed in our Certificate and Signing Services
> Terms of Use. In addition, it is common that terms may be custom
> negotiated, so the best course of action, for any individual customer with
> questions, is to contact their account representatives directly to discuss.
> >
> > We hope this provides some more context to the question here on what our
> standard options and practices are. And we have an extensive customer
> communications and outreach program underway to ensure that customers
> understand their options and to provide uninterrupted support for their
> publicly trusted TLS certificates.
>
> Let me get this straight: you will not revoke on time when presented
> with a BR violation, making the excuse customers will be
> inconvenienced, run criticial systems yadda yadda. You will revoke
> gratuitously come contract renewal time, and none of the reasons
> listed before matter.
>
> Sincerely,
> Watson Ladd
>
> --
> 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/CACsn0cnU6nDKQ%3DyEONsACzZi9LCgjdgQdXdO2AM%2BxTS51utUwA%40mail.gmail.com
> .
>

-- 
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/CAOG%3DJUKSgRw-h5%3DUzMFxc%3DDPOxQCaTcJUtRehZswmHGkT08gHg%40mail.gmail.com.

Re: Recent Entrust Compliance Incidents

[Watson Ladd]

On Fri, Aug 2, 2024 at 5:33 AM 'Bruce Morton' via
dev-security-policy@mozilla.org 
wrote:
>
> Hi Nick,
>
> Thanks for passing on the customer email, we’re following up directly there, 
> and as always, we’d recommend that customers directly reach out to their 
> account team to discuss their specific needs.
>
> That said, we think it would be helpful to share the different certificate 
> licensing models we offer and the details of each. Entrust broadly offers two 
> models for certificate purchase. The handling of active certificates, 
> including revocation, differs based on the model chosen by the customer.
>
> The first model is what we call “unit based” and is what most would consider 
> the historically traditional approach for certificate offers, where a 
> customer purchases a certificate for a specific term, that certificate is 
> paid for up front, and their license is valid through the expiration date of 
> the certificate. After initial issuance only limited changes are permitted to 
> the details of the certificate.
>
> The second model is what we call “subscription” or “pooling”, and this 
> approach allows a customer to have up to a pre-defined number of certificates 
> issued and active at any given time during the period of the subscription. 
> This approach allows customers the flexibility to issue and change 
> certificates as often as necessary as their needs change, including, for 
> example, revoking a no-longer needed certificate and issuing a new one with 
> new organization information or domains, with no additional charges. At the 
> time of renewal, customers can increase or decrease the number of 
> certificates that are available under their subscription. If at any time a 
> customer chooses to fully stop their subscription, then the license period 
> ends, and under the terms of the agreement we reserve the right to revoke any 
> unexpired certificates.
>
> So, depending on the model selected by the customer up front, the approach 
> differs on how unexpired certificates are handled upon termination, and both 
> are addressed in our Certificate and Signing Services Terms of Use. In 
> addition, it is common that terms may be custom negotiated, so the best 
> course of action, for any individual customer with questions, is to contact 
> their account representatives directly to discuss.
>
> We hope this provides some more context to the question here on what our 
> standard options and practices are. And we have an extensive customer 
> communications and outreach program underway to ensure that customers 
> understand their options and to provide uninterrupted support for their 
> publicly trusted TLS certificates.

Let me get this straight: you will not revoke on time when presented
with a BR violation, making the excuse customers will be
inconvenienced, run criticial systems yadda yadda. You will revoke
gratuitously come contract renewal time, and none of the reasons
listed before matter.

Sincerely,
Watson Ladd

-- 
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/CACsn0cnU6nDKQ%3DyEONsACzZi9LCgjdgQdXdO2AM%2BxTS51utUwA%40mail.gmail.com.

Re: Recent Entrust Compliance Incidents

[Mike Shaver]

I don’t think this is an inherently inappropriate model, as long as the
consequences of contract non-renewal are spelled out to the customer
clearly enough. When you stop paying Splunk, they sure do delete your stuff
with enthusiasm (not that Splunk is necessarily the highest bar for
treating customers well).

It seems like it may not have been sufficiently clear to some of the
subscriber representatives that this is the case, but that’s a customer
management issue and Entrust will deal with the consequences of it. I don’t
think it’s bad for the web for these sorts of arrangements to exist, or
having pretty much any sort of contractual limitation on certificate
lifetimes — normal notAfter expiry, a temporary intermediate, a cert issued
to a CA employee for personal use that gets revoked when they leave, etc.
After all, these subscribers are supposed to be able to get a new cert
deployed in 24 hours anyway, right? :P

I would *prefer* that it were done by issuing short-lived certificates,
since it’s not super clear to other participants in the ecosystem that
there is a “non-emergency” circumstance in which notAfter might be
misleading, and revocation checking is not really in a great state
generally, but…

Mike

On Fri, Aug 2, 2024 at 8:43 AM Wayne  wrote:

> So in summary: the allegations are true, and there's a direct business
> model created to allow this to exist alongside the traditional certificates
> system?
>
> Are any other CAs going to be forthcoming on a similar approach, as what
> is being described is renting certificate lifespan, with hidden
> cancellation fees. I don't see how this is compatible with the baseline
> requirements, and seems to reflect a CA further inserting themselves into
> the chain to confuse subscribers on what precisely they are purchasing with
> a certificate. A flexible-volume license approach is different than what
> has been described, to be clear.
>
> It is disconcerting that this is phrased as standard operating procedure,
> and nothing to worry about.
>
> - Wayne
>
> On Friday, August 2, 2024 at 1:33:10 PM UTC+1 Bruce Morton wrote:
>
>> Hi Nick,
>>
>> Thanks for passing on the customer email, we’re following up directly
>> there, and as always, we’d recommend that customers directly reach out to
>> their account team to discuss their specific needs.
>>
>> That said, we think it would be helpful to share the different
>> certificate licensing models we offer and the details of each. Entrust
>> broadly offers two models for certificate purchase. The handling of active
>> certificates, including revocation, differs based on the model chosen by
>> the customer.
>>
>> The first model is what we call “unit based” and is what most would
>> consider the historically traditional approach for certificate offers,
>> where a customer purchases a certificate for a specific term, that
>> certificate is paid for up front, and their license is valid through the
>> expiration date of the certificate. After initial issuance only limited
>> changes are permitted to the details of the certificate.
>>
>> The second model is what we call “subscription” or “pooling”, and this
>> approach allows a customer to have up to a pre-defined number of
>> certificates issued and active at any given time during the period of the
>> subscription. This approach allows customers the flexibility to issue and
>> change certificates as often as necessary as their needs change, including,
>> for example, revoking a no-longer needed certificate and issuing a new one
>> with new organization information or domains, with no additional charges.
>> At the time of renewal, customers can increase or decrease the number of
>> certificates that are available under their subscription. If at any time a
>> customer chooses to fully stop their subscription, then the license period
>> ends, and under the terms of the agreement we reserve the right to revoke
>> any unexpired certificates.
>>
>> So, depending on the model selected by the customer up front, the
>> approach differs on how unexpired certificates are handled upon
>> termination, and both are addressed in our Certificate and Signing Services
>> Terms of Use. In addition, it is common that terms may be custom
>> negotiated, so the best course of action, for any individual customer with
>> questions, is to contact their account representatives directly to discuss.
>>
>> We hope this provides some more context to the question here on what our
>> standard options and practices are. And we have an extensive customer
>> communications and outreach program underway to ensure that customers
>> understand their options and to provide uninterrupted support for their
>> publicly trusted TLS certificates.
>>
>> On Thursday, August 1, 2024 at 2:04:05 PM UTC-4 Nick France wrote:
>>
>>> Last time this happened (see the thread Jonathan Doe linked to), we did
>>> see this with customers looking to move to Sectigo - but it was quickly
>>> remedied with Jeremy and Tim H's help. 

Re: Recent Entrust Compliance Incidents

[Wayne]

So in summary: the allegations are true, and there's a direct business 
model created to allow this to exist alongside the traditional certificates 
system?

Are any other CAs going to be forthcoming on a similar approach, as what is 
being described is renting certificate lifespan, with hidden cancellation 
fees. I don't see how this is compatible with the baseline requirements, 
and seems to reflect a CA further inserting themselves into the chain to 
confuse subscribers on what precisely they are purchasing with a 
certificate. A flexible-volume license approach is different than what has 
been described, to be clear.

It is disconcerting that this is phrased as standard operating procedure, 
and nothing to worry about.

- Wayne 

On Friday, August 2, 2024 at 1:33:10 PM UTC+1 Bruce Morton wrote:

> Hi Nick,
>
> Thanks for passing on the customer email, we’re following up directly 
> there, and as always, we’d recommend that customers directly reach out to 
> their account team to discuss their specific needs.
>
> That said, we think it would be helpful to share the different certificate 
> licensing models we offer and the details of each. Entrust broadly offers 
> two models for certificate purchase. The handling of active certificates, 
> including revocation, differs based on the model chosen by the customer.
>
> The first model is what we call “unit based” and is what most would 
> consider the historically traditional approach for certificate offers, 
> where a customer purchases a certificate for a specific term, that 
> certificate is paid for up front, and their license is valid through the 
> expiration date of the certificate. After initial issuance only limited 
> changes are permitted to the details of the certificate.
>
> The second model is what we call “subscription” or “pooling”, and this 
> approach allows a customer to have up to a pre-defined number of 
> certificates issued and active at any given time during the period of the 
> subscription. This approach allows customers the flexibility to issue and 
> change certificates as often as necessary as their needs change, including, 
> for example, revoking a no-longer needed certificate and issuing a new one 
> with new organization information or domains, with no additional charges. 
> At the time of renewal, customers can increase or decrease the number of 
> certificates that are available under their subscription. If at any time a 
> customer chooses to fully stop their subscription, then the license period 
> ends, and under the terms of the agreement we reserve the right to revoke 
> any unexpired certificates.
>
> So, depending on the model selected by the customer up front, the approach 
> differs on how unexpired certificates are handled upon termination, and 
> both are addressed in our Certificate and Signing Services Terms of Use. In 
> addition, it is common that terms may be custom negotiated, so the best 
> course of action, for any individual customer with questions, is to contact 
> their account representatives directly to discuss.
>
> We hope this provides some more context to the question here on what our 
> standard options and practices are. And we have an extensive customer 
> communications and outreach program underway to ensure that customers 
> understand their options and to provide uninterrupted support for their 
> publicly trusted TLS certificates.
>
> On Thursday, August 1, 2024 at 2:04:05 PM UTC-4 Nick France wrote:
>
>> Last time this happened (see the thread Jonathan Doe linked to), we did 
>> see this with customers looking to move to Sectigo - but it was quickly 
>> remedied with Jeremy and Tim H's help. We haven't seen a problem with 
>> DigiCert again since.
>>
>> I will say that we are now seeing the same with Entrust customers who are 
>> being told that active certificates will be revoked if contracts are not 
>> renewed, in clear language.
>>
>> I have privately sent the details of at least one customer to Bruce, and 
>> hopefully he can confirm this was an error on the part of the Entrust 
>> employee, or that it is indeed Entrust's policy.
>>
>>
>> Nick
>>
>> On Thursday, August 1, 2024 at 1:21:58 AM UTC+1 Mike Shaver wrote:
>>
>>> On Wed, Jul 31, 2024 at 8:19 PM Matt Palmer  wrote:
>>>
 On Wed, Jul 31, 2024 at 04:02:50PM -0700, 'Bruce Morton' via 
 dev-secur...@mozilla.org wrote:
 > Without more details about your specific situation, it’s difficult to
 > address your concern effectively. Please reach out to me personally, 
 and I
 > will do my best to assist you.

 Given Entrust's perceived past (lack of) transparency in communications,
 it might be better if as much of this issue could be resolved in public.

 Can you provide any insight into why any Entrust subscriber may have
 gained the impression that "if we did not renew the contract, all active
 certificates would be revoked"?  Even if that is not Entrust's
 intention, the fact 

Re: Recent Entrust Compliance Incidents

['Bruce Morton' via dev-security-policy@mozilla.org]

Hi Nick,

Thanks for passing on the customer email, we’re following up directly 
there, and as always, we’d recommend that customers directly reach out to 
their account team to discuss their specific needs.

That said, we think it would be helpful to share the different certificate 
licensing models we offer and the details of each. Entrust broadly offers 
two models for certificate purchase. The handling of active certificates, 
including revocation, differs based on the model chosen by the customer.

The first model is what we call “unit based” and is what most would 
consider the historically traditional approach for certificate offers, 
where a customer purchases a certificate for a specific term, that 
certificate is paid for up front, and their license is valid through the 
expiration date of the certificate. After initial issuance only limited 
changes are permitted to the details of the certificate.

The second model is what we call “subscription” or “pooling”, and this 
approach allows a customer to have up to a pre-defined number of 
certificates issued and active at any given time during the period of the 
subscription. This approach allows customers the flexibility to issue and 
change certificates as often as necessary as their needs change, including, 
for example, revoking a no-longer needed certificate and issuing a new one 
with new organization information or domains, with no additional charges. 
At the time of renewal, customers can increase or decrease the number of 
certificates that are available under their subscription. If at any time a 
customer chooses to fully stop their subscription, then the license period 
ends, and under the terms of the agreement we reserve the right to revoke 
any unexpired certificates.

So, depending on the model selected by the customer up front, the approach 
differs on how unexpired certificates are handled upon termination, and 
both are addressed in our Certificate and Signing Services Terms of Use. In 
addition, it is common that terms may be custom negotiated, so the best 
course of action, for any individual customer with questions, is to contact 
their account representatives directly to discuss.

We hope this provides some more context to the question here on what our 
standard options and practices are. And we have an extensive customer 
communications and outreach program underway to ensure that customers 
understand their options and to provide uninterrupted support for their 
publicly trusted TLS certificates.

On Thursday, August 1, 2024 at 2:04:05 PM UTC-4 Nick France wrote:

> Last time this happened (see the thread Jonathan Doe linked to), we did 
> see this with customers looking to move to Sectigo - but it was quickly 
> remedied with Jeremy and Tim H's help. We haven't seen a problem with 
> DigiCert again since.
>
> I will say that we are now seeing the same with Entrust customers who are 
> being told that active certificates will be revoked if contracts are not 
> renewed, in clear language.
>
> I have privately sent the details of at least one customer to Bruce, and 
> hopefully he can confirm this was an error on the part of the Entrust 
> employee, or that it is indeed Entrust's policy.
>
>
> Nick
>
> On Thursday, August 1, 2024 at 1:21:58 AM UTC+1 Mike Shaver wrote:
>
>> On Wed, Jul 31, 2024 at 8:19 PM Matt Palmer  wrote:
>>
>>> On Wed, Jul 31, 2024 at 04:02:50PM -0700, 'Bruce Morton' via 
>>> dev-secur...@mozilla.org wrote:
>>> > Without more details about your specific situation, it’s difficult to
>>> > address your concern effectively. Please reach out to me personally, 
>>> and I
>>> > will do my best to assist you.
>>>
>>> Given Entrust's perceived past (lack of) transparency in communications,
>>> it might be better if as much of this issue could be resolved in public.
>>>
>>> Can you provide any insight into why any Entrust subscriber may have
>>> gained the impression that "if we did not renew the contract, all active
>>> certificates would be revoked"?  Even if that is not Entrust's
>>> intention, the fact that a subscriber may have gotten that impression
>>> from, say, an over-zealous salesperson or poorly-worded email is very
>>> troubling.
>>
>>
>> Have to disagree here, Matt. I don’t think it will be as effective for 
>> this discussion to be redacted as it would need to be in order to be 
>> public, and still protect J Doe, and I think that we can take Bruce’s offer 
>> to investigate in good faith.
>>
>> If it becomes a pattern that’s reported more widely—and I think it would 
>> spread quickly, given the visibility of Entrust’s difficulties of late—then 
>> we might get to the point of “very troubling”. Let’s not use up all our 
>> strong language on the earliest wisps of concern. :)
>>
>> 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-sec

Re: Recent Entrust Compliance Incidents

['Nick France' via dev-security-policy@mozilla.org]

Last time this happened (see the thread Jonathan Doe linked to), we did see 
this with customers looking to move to Sectigo - but it was quickly 
remedied with Jeremy and Tim H's help. We haven't seen a problem with 
DigiCert again since.

I will say that we are now seeing the same with Entrust customers who are 
being told that active certificates will be revoked if contracts are not 
renewed, in clear language.

I have privately sent the details of at least one customer to Bruce, and 
hopefully he can confirm this was an error on the part of the Entrust 
employee, or that it is indeed Entrust's policy.


Nick

On Thursday, August 1, 2024 at 1:21:58 AM UTC+1 Mike Shaver wrote:

> On Wed, Jul 31, 2024 at 8:19 PM Matt Palmer  wrote:
>
>> On Wed, Jul 31, 2024 at 04:02:50PM -0700, 'Bruce Morton' via 
>> dev-secur...@mozilla.org wrote:
>> > Without more details about your specific situation, it’s difficult to
>> > address your concern effectively. Please reach out to me personally, 
>> and I
>> > will do my best to assist you.
>>
>> Given Entrust's perceived past (lack of) transparency in communications,
>> it might be better if as much of this issue could be resolved in public.
>>
>> Can you provide any insight into why any Entrust subscriber may have
>> gained the impression that "if we did not renew the contract, all active
>> certificates would be revoked"?  Even if that is not Entrust's
>> intention, the fact that a subscriber may have gotten that impression
>> from, say, an over-zealous salesperson or poorly-worded email is very
>> troubling.
>
>
> Have to disagree here, Matt. I don’t think it will be as effective for 
> this discussion to be redacted as it would need to be in order to be 
> public, and still protect J Doe, and I think that we can take Bruce’s offer 
> to investigate in good faith.
>
> If it becomes a pattern that’s reported more widely—and I think it would 
> spread quickly, given the visibility of Entrust’s difficulties of late—then 
> we might get to the point of “very troubling”. Let’s not use up all our 
> strong language on the earliest wisps of concern. :)
>
> 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/ba349e3d-2667-4d90-a841-0747e79a113fn%40mozilla.org.

Re: Recent Entrust Compliance Incidents

[Mike Shaver]

On Wed, Jul 31, 2024 at 8:19 PM Matt Palmer  wrote:

> On Wed, Jul 31, 2024 at 04:02:50PM -0700, 'Bruce Morton' via
> dev-security-policy@mozilla.org wrote:
> > Without more details about your specific situation, it’s difficult to
> > address your concern effectively. Please reach out to me personally, and
> I
> > will do my best to assist you.
>
> Given Entrust's perceived past (lack of) transparency in communications,
> it might be better if as much of this issue could be resolved in public.
>
> Can you provide any insight into why any Entrust subscriber may have
> gained the impression that "if we did not renew the contract, all active
> certificates would be revoked"?  Even if that is not Entrust's
> intention, the fact that a subscriber may have gotten that impression
> from, say, an over-zealous salesperson or poorly-worded email is very
> troubling.


Have to disagree here, Matt. I don’t think it will be as effective for this
discussion to be redacted as it would need to be in order to be public, and
still protect J Doe, and I think that we can take Bruce’s offer to
investigate in good faith.

If it becomes a pattern that’s reported more widely—and I think it would
spread quickly, given the visibility of Entrust’s difficulties of late—then
we might get to the point of “very troubling”. Let’s not use up all our
strong language on the earliest wisps of concern. :)

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/CADQzZqvNwCowrUVnc2ksjaj5nOU%3DMZ1-hkyi7eyeAfiRnxiogQ%40mail.gmail.com.

Re: Recent Entrust Compliance Incidents

[Matt Palmer]

On Wed, Jul 31, 2024 at 04:02:50PM -0700, 'Bruce Morton' via 
dev-security-policy@mozilla.org wrote:
> Without more details about your specific situation, it’s difficult to
> address your concern effectively. Please reach out to me personally, and I
> will do my best to assist you.

Given Entrust's perceived past (lack of) transparency in communications,
it might be better if as much of this issue could be resolved in public.

Can you provide any insight into why any Entrust subscriber may have
gained the impression that "if we did not renew the contract, all active
certificates would be revoked"?  Even if that is not Entrust's
intention, the fact that a subscriber may have gotten that impression
from, say, an over-zealous salesperson or poorly-worded email is very
troubling.

- Matt

-- 
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/2cc79482-cb70-4c07-ad15-8713f163184c%40mtasv.net.

Re: Recent Entrust Compliance Incidents

[Mike Shaver]

Thanks, Bruce. There are a lot of moving parts right now for Entrust’s
subscribers, and I can think of many different things that could be
misinterpreted as a threat or holding of certs as “hostages”. I appreciate
you offering to connect directly with “Mr Doe” to explore his concerns!

Mike


On Wed, Jul 31, 2024 at 7:02 PM 'Bruce Morton' via
dev-security-policy@mozilla.org  wrote:

> Without more details about your specific situation, it’s difficult to
> address your concern effectively. Please reach out to me personally, and I
> will do my best to assist you.
>
> For others reading this, I want to clarify that this post does not reflect
> our renewal policies. We are executing a plan to address Chrome's and now
> Mozilla's announced changes and working closely with our customers to
> ensure they all have uninterrupted issuance, support, and service of
> publicly trusted TLS certificates.  For more information on these plans,
> please visit: https://www.entrust.com/tls-certificate-information-center.
>
> On Tuesday, July 30, 2024 at 10:14:17 AM UTC-4 Jonathan Doe wrote:
>
>> (Posting anonymously to protect my employer).
>>
>> Entrust appear to be threatening existing customers with revocation of
>> still-valid certs if contracts are not renewed.
>>
>> I have seen with our own discussions with Entrust as well as those from
>> others in my network. We were told we could not get a short-term extension
>> to the Entrust contract while these issues are ongoing, and if we did not
>> renew the contract, all active certificates would be revoked.
>>
>> I know this isn't a direct violation of any guideline, but it has been
>> discussed before and was frowned upon by the Chrome team (
>> https://www.mail-archive.com/dev-secur...@lists.mozilla.org/msg13151.html
>> 
>> ).
>>
> I cannot imagine Mozilla, Microsoft or Apple would support this.
>>
>> Can Entrust comment on why they are holding customers hostage? Especially
>> with recent webinars telling customers to replace/renew in advance of the
>> distrust, but now threatening revocation if contracts are not renewed?
>>
>> On Thursday, July 25, 2024 at 3:04:43 PM UTC+1 Claves Nostrum wrote:
>>
>>> How would that work from an auditing perspective?
>>>
>>> Given the minimally accepted period-under-audit for period-over-time
>>> audits is 3 months it sounds overly ambitious to get all the systemic
>>> issues that lead to the distrust remediated, execute all controls in an
>>> orderly fashion, and obtain an unqualified WebTrust for RA period-over-time
>>> report prior to October 31st 2024. Or are you suggesting that SSL.COM
>>> would be willing to accept you as an External RA without being able to
>>> present an unqualified WebTrust for RA period-over-time report?
>>>
>>> Would be good to get transparency on the plans and their feasibility,
>>> and also the acceptance criteria from SSL.COM for Entrust to be an
>>> external RA.
>>>
>>> Op do 25 jul 2024 om 00:10 schreef 'Bruce Morton' via
>>> dev-secur...@mozilla.org :
>>>
 Claves, thank you for the question, as I re-read the blog post it seems
 we could have been clearer.


- We are not yet providing certificates issued from SSL.com. Our
intent was to announce the partnership with SSL.com and communicate our
plan for how we will provide continuity to our customers for public TLS
certificates after October 31. Our next step is to do the work 
 necessary to
have this capability in place before that time.
- Our plan is to serve as an external RA, with SSL.com as the CA,
as provided for in the Baseline Requirements, section 1.3.2. 
 Beforehand, we
will complete the required reviews and approval from SSL.com, as 
 outlined
in the BRs section 1.3.2, 5.3.1, and 5.5.2. As part of this process, we
will undergo a WebTrust Audit for RAs.

 We are committed to operating under the CA/Browser Forum Baseline
 Requirements, and completing the improvement plans we’ve communicated to
 this community. We hope this demonstrates that we are approaching this
 arrangement with due rigor, and our commitment to improve our compliance
 and incident handling.

 On Tuesday, July 23, 2024 at 10:58:27 AM UTC-4 Claves Nostrum wrote:

 It appears that Entrust is now providing its customers with
 certificates from SSL.COM:
 https://www.entrust.com/blog/2024/07/announcing-our-new-tls-solution-offering/
 Given the type of customers that Entrust was serving it must imply they
 are at least acting as a Delegated Third Party or External RA for those
 certificates
 The blogpost also seems to suggest they are acting as an External RA
 for SSL.COM
 Could Entrust and SSL.COM provide insights in which construct they are
 working together (reseller, Delegated Third Party or External RA)?
 If it is an

Re: Recent Entrust Compliance Incidents

['Bruce Morton' via dev-security-policy@mozilla.org]

Without more details about your specific situation, it’s difficult to 
address your concern effectively. Please reach out to me personally, and I 
will do my best to assist you.
 
For others reading this, I want to clarify that this post does not reflect 
our renewal policies. We are executing a plan to address Chrome's and now 
Mozilla's announced changes and working closely with our customers to 
ensure they all have uninterrupted issuance, support, and service of 
publicly trusted TLS certificates.  For more information on these plans, 
please visit: https://www.entrust.com/tls-certificate-information-center.

On Tuesday, July 30, 2024 at 10:14:17 AM UTC-4 Jonathan Doe wrote:

> (Posting anonymously to protect my employer).
>
> Entrust appear to be threatening existing customers with revocation of 
> still-valid certs if contracts are not renewed.
>
> I have seen with our own discussions with Entrust as well as those from 
> others in my network. We were told we could not get a short-term extension 
> to the Entrust contract while these issues are ongoing, and if we did not 
> renew the contract, all active certificates would be revoked.
>
> I know this isn't a direct violation of any guideline, but it has been 
> discussed before and was frowned upon by the Chrome team (
> https://www.mail-archive.com/dev-secur...@lists.mozilla.org/msg13151.html 
> 
> ).
> I cannot imagine Mozilla, Microsoft or Apple would support this.
>
> Can Entrust comment on why they are holding customers hostage? Especially 
> with recent webinars telling customers to replace/renew in advance of the 
> distrust, but now threatening revocation if contracts are not renewed?
>
> On Thursday, July 25, 2024 at 3:04:43 PM UTC+1 Claves Nostrum wrote:
>
>> How would that work from an auditing perspective? 
>>
>> Given the minimally accepted period-under-audit for period-over-time 
>> audits is 3 months it sounds overly ambitious to get all the systemic 
>> issues that lead to the distrust remediated, execute all controls in an 
>> orderly fashion, and obtain an unqualified WebTrust for RA period-over-time 
>> report prior to October 31st 2024. Or are you suggesting that SSL.COM 
>> would be willing to accept you as an External RA without being able to 
>> present an unqualified WebTrust for RA period-over-time report? 
>>
>> Would be good to get transparency on the plans and their feasibility, and 
>> also the acceptance criteria from SSL.COM for Entrust to be an external 
>> RA. 
>>
>> Op do 25 jul 2024 om 00:10 schreef 'Bruce Morton' via 
>> dev-secur...@mozilla.org :
>>
>>> Claves, thank you for the question, as I re-read the blog post it seems 
>>> we could have been clearer.
>>>
>>>
>>>- We are not yet providing certificates issued from SSL.com. Our 
>>>intent was to announce the partnership with SSL.com and communicate our 
>>>plan for how we will provide continuity to our customers for public TLS 
>>>certificates after October 31. Our next step is to do the work necessary 
>>> to 
>>>have this capability in place before that time.
>>>- Our plan is to serve as an external RA, with SSL.com as the CA, as 
>>>provided for in the Baseline Requirements, section 1.3.2. Beforehand, we 
>>>will complete the required reviews and approval from SSL.com, as 
>>> outlined 
>>>in the BRs section 1.3.2, 5.3.1, and 5.5.2. As part of this process, we 
>>>will undergo a WebTrust Audit for RAs.
>>>
>>> We are committed to operating under the CA/Browser Forum Baseline 
>>> Requirements, and completing the improvement plans we’ve communicated to 
>>> this community. We hope this demonstrates that we are approaching this 
>>> arrangement with due rigor, and our commitment to improve our compliance 
>>> and incident handling.
>>>
>>> On Tuesday, July 23, 2024 at 10:58:27 AM UTC-4 Claves Nostrum wrote:
>>>
>>> It appears that Entrust is now providing its customers with certificates 
>>> from SSL.COM: 
>>> https://www.entrust.com/blog/2024/07/announcing-our-new-tls-solution-offering/
>>> Given the type of customers that Entrust was serving it must imply they 
>>> are at least acting as a Delegated Third Party or External RA for those 
>>> certificates
>>> The blogpost also seems to suggest they are acting as an External RA for 
>>> SSL.COM
>>> Could Entrust and SSL.COM provide insights in which construct they are 
>>> working together (reseller, Delegated Third Party or External RA)?
>>> If it is an External RA how did SSL.COM evaluate and accept the risk 
>>> given the numerous (vetting) compliance incidents Entrust has recently had 
>>> and their failure to timely replace the certificates?
>>>
>>> Op do 4 jul 2024 om 18:39 schreef Watson Ladd :
>>>
>>>
>>>
>>> On Thu, Jul 4, 2024, 11:49 AM 'Bruce Morton' via 
>>> dev-secur...@mozilla.org  wrote:
>>>
>>>
>>>
>>> On Tuesday, June 25, 2024 at 5:19:22 PM UTC-4 Mike Shaver wrote:
>>>
>>> W

Re: Recent Entrust Compliance Incidents

[Arabella Barks]

Hi @Jonathan Doe,

Entrust appear to be threatening existing customers with revocation of 
still-valid certs if contracts are not renewed.
> Can you share communication here? Please redact censored informations.
> Dev-security-policy is a free spoken community but we must verify whether 
it is not a fictitious impeachment.

Best wishes,
A. Barks.
On Tuesday, July 30, 2024 at 10:14:17 PM UTC+8 Jonathan Doe wrote:

> (Posting anonymously to protect my employer).
>
> Entrust appear to be threatening existing customers with revocation of 
> still-valid certs if contracts are not renewed.
>
> I have seen with our own discussions with Entrust as well as those from 
> others in my network. We were told we could not get a short-term extension 
> to the Entrust contract while these issues are ongoing, and if we did not 
> renew the contract, all active certificates would be revoked.
>
> I know this isn't a direct violation of any guideline, but it has been 
> discussed before and was frowned upon by the Chrome team (
> https://www.mail-archive.com/dev-secur...@lists.mozilla.org/msg13151.html 
> 
> ).
> I cannot imagine Mozilla, Microsoft or Apple would support this.
>
> Can Entrust comment on why they are holding customers hostage? Especially 
> with recent webinars telling customers to replace/renew in advance of the 
> distrust, but now threatening revocation if contracts are not renewed?
>
> On Thursday, July 25, 2024 at 3:04:43 PM UTC+1 Claves Nostrum wrote:
>
>> How would that work from an auditing perspective? 
>>
>> Given the minimally accepted period-under-audit for period-over-time 
>> audits is 3 months it sounds overly ambitious to get all the systemic 
>> issues that lead to the distrust remediated, execute all controls in an 
>> orderly fashion, and obtain an unqualified WebTrust for RA period-over-time 
>> report prior to October 31st 2024. Or are you suggesting that SSL.COM 
>> would be willing to accept you as an External RA without being able to 
>> present an unqualified WebTrust for RA period-over-time report? 
>>
>> Would be good to get transparency on the plans and their feasibility, and 
>> also the acceptance criteria from SSL.COM for Entrust to be an external 
>> RA. 
>>
>> Op do 25 jul 2024 om 00:10 schreef 'Bruce Morton' via 
>> dev-secur...@mozilla.org :
>>
>>> Claves, thank you for the question, as I re-read the blog post it seems 
>>> we could have been clearer.
>>>
>>>
>>>- We are not yet providing certificates issued from SSL.com. Our 
>>>intent was to announce the partnership with SSL.com and communicate our 
>>>plan for how we will provide continuity to our customers for public TLS 
>>>certificates after October 31. Our next step is to do the work necessary 
>>> to 
>>>have this capability in place before that time.
>>>- Our plan is to serve as an external RA, with SSL.com as the CA, as 
>>>provided for in the Baseline Requirements, section 1.3.2. Beforehand, we 
>>>will complete the required reviews and approval from SSL.com, as 
>>> outlined 
>>>in the BRs section 1.3.2, 5.3.1, and 5.5.2. As part of this process, we 
>>>will undergo a WebTrust Audit for RAs.
>>>
>>> We are committed to operating under the CA/Browser Forum Baseline 
>>> Requirements, and completing the improvement plans we’ve communicated to 
>>> this community. We hope this demonstrates that we are approaching this 
>>> arrangement with due rigor, and our commitment to improve our compliance 
>>> and incident handling.
>>>
>>> On Tuesday, July 23, 2024 at 10:58:27 AM UTC-4 Claves Nostrum wrote:
>>>
>>> It appears that Entrust is now providing its customers with certificates 
>>> from SSL.COM: 
>>> https://www.entrust.com/blog/2024/07/announcing-our-new-tls-solution-offering/
>>> Given the type of customers that Entrust was serving it must imply they 
>>> are at least acting as a Delegated Third Party or External RA for those 
>>> certificates
>>> The blogpost also seems to suggest they are acting as an External RA for 
>>> SSL.COM
>>> Could Entrust and SSL.COM provide insights in which construct they are 
>>> working together (reseller, Delegated Third Party or External RA)?
>>> If it is an External RA how did SSL.COM evaluate and accept the risk 
>>> given the numerous (vetting) compliance incidents Entrust has recently had 
>>> and their failure to timely replace the certificates?
>>>
>>> Op do 4 jul 2024 om 18:39 schreef Watson Ladd :
>>>
>>>
>>>
>>> On Thu, Jul 4, 2024, 11:49 AM 'Bruce Morton' via 
>>> dev-secur...@mozilla.org  wrote:
>>>
>>>
>>>
>>> On Tuesday, June 25, 2024 at 5:19:22 PM UTC-4 Mike Shaver wrote:
>>>
>>> While you’re addressing comments, I’d appreciate an answer to my 
>>> question here: what was the motivation behind redacting that portion of the 
>>> email to customers, if not to conceal information related to redaction 
>>> procedures?
>>>
>>> You want to make it clear 

Re: Recent Entrust Compliance Incidents

['Bruce Morton' via dev-security-policy@mozilla.org]

Thanks for the question.

We understand that external audits can help provide confidence to the 
community and relying parties that necessary and expected controls are in 
place. Given the issues this year, we want to ensure that the community can 
have confidence that the improvements we’ve shared here already have been 
executed and are in place. 

To that end, we have engaged our auditor, Deloitte, to conduct, for the 
foreseeable future, all required WebTrust for CA period-of-time audits on a 
more frequent basis—at least semi-annually.

Regarding the plan to operate as an RA with SSL.com, prior to going live we 
will be completing a point-in-time WebTrust for RA audit that will focus 
specifically on alignment with SSL.com’s CP/CPS. After this initial 
point-in-time audit, period-of-time WebTrust for RA audits will be 
conducted concurrently with our more comprehensive WebTrust for CA audits. 
We believe that this approach will provide relying parties with greater 
visibility and confidence into all our ongoing CA operations and meet the 
up-front needs of relying parties and SSL.com when we add the RA-only 
operations as part of our partnership with them.

On Thursday, July 25, 2024 at 10:04:43 AM UTC-4 Claves Nostrum wrote:

How would that work from an auditing perspective? 

Given the minimally accepted period-under-audit for period-over-time audits 
is 3 months it sounds overly ambitious to get all the systemic issues that 
lead to the distrust remediated, execute all controls in an orderly 
fashion, and obtain an unqualified WebTrust for RA period-over-time report 
prior to October 31st 2024. Or are you suggesting that SSL.COM would be 
willing to accept you as an External RA without being able to present an 
unqualified WebTrust for RA period-over-time report? 

Would be good to get transparency on the plans and their feasibility, and 
also the acceptance criteria from SSL.COM for Entrust to be an external RA. 

Op do 25 jul 2024 om 00:10 schreef 'Bruce Morton' via 
dev-secur...@mozilla.org :

Claves, thank you for the question, as I re-read the blog post it seems we 
could have been clearer.


   - We are not yet providing certificates issued from SSL.com. Our intent 
   was to announce the partnership with SSL.com and communicate our plan for 
   how we will provide continuity to our customers for public TLS certificates 
   after October 31. Our next step is to do the work necessary to have this 
   capability in place before that time.
   - Our plan is to serve as an external RA, with SSL.com as the CA, as 
   provided for in the Baseline Requirements, section 1.3.2. Beforehand, we 
   will complete the required reviews and approval from SSL.com, as outlined 
   in the BRs section 1.3.2, 5.3.1, and 5.5.2. As part of this process, we 
   will undergo a WebTrust Audit for RAs.

We are committed to operating under the CA/Browser Forum Baseline 
Requirements, and completing the improvement plans we’ve communicated to 
this community. We hope this demonstrates that we are approaching this 
arrangement with due rigor, and our commitment to improve our compliance 
and incident handling.

On Tuesday, July 23, 2024 at 10:58:27 AM UTC-4 Claves Nostrum wrote:

It appears that Entrust is now providing its customers with certificates 
from SSL.COM: 
https://www.entrust.com/blog/2024/07/announcing-our-new-tls-solution-offering/
Given the type of customers that Entrust was serving it must imply they are 
at least acting as a Delegated Third Party or External RA for those 
certificates
The blogpost also seems to suggest they are acting as an External RA for 
SSL.COM
Could Entrust and SSL.COM provide insights in which construct they are 
working together (reseller, Delegated Third Party or External RA)?
If it is an External RA how did SSL.COM evaluate and accept the risk given 
the numerous (vetting) compliance incidents Entrust has recently had and 
their failure to timely replace the certificates?

Op do 4 jul 2024 om 18:39 schreef Watson Ladd :



On Thu, Jul 4, 2024, 11:49 AM 'Bruce Morton' via dev-secur...@mozilla.org <
dev-secur...@mozilla.org> wrote:



On Tuesday, June 25, 2024 at 5:19:22 PM UTC-4 Mike Shaver wrote:

While you’re addressing comments, I’d appreciate an answer to my question 
here: what was the motivation behind redacting that portion of the email to 
customers, if not to conceal information related to redaction procedures?

You want to make it clear that you aren’t concealing anything, but you 
haven’t given us any reason to believe otherwise.

Mike


The letter was shared as an example of what was sent from us directly to a 
subscriber. The question posed was “what was the contents of the email sent 
to providers asking for revocation to begin with?”. We posted the 
communication’s contents in the thread and removed the step-by-step 
instructions and the contact information for support as we didn’t feel that 
was the request’s focus. It was not redacted to conceal the specific 
instr

Re: Recent Entrust Compliance Incidents

[Matt Palmer]

On Tue, Jul 30, 2024 at 12:40:44AM -0700, Jonathan Doe wrote:
> Entrust appear to be threatening existing customers with revocation of
> still-valid certs if contracts are not renewed.

Is there any possibility of sharing (redacted where necessary)
communications that support this appearance?

> I have seen with our own discussions with Entrust as well as those from
> others in my network. We were told we could not get a short-term extension
> to the Entrust contract while these issues are ongoing, and if we did not
> renew the contract, all active certificates would be revoked.

I would like to thank Entrust for this apparent further demonstration of
why certificate lifecycle automation is so important.  In an
organisation that had lifecycle automation in place, it would be much
easier to switch to a new CA, by adjusting some configuration (ACME
directory and possibly credentials) and pressing "reissue".  You could
be completely switched off those hostage certificates before anyone
knew, making any threatened revocation a non-issue.

- Matt

-- 
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/390601c5-7ad6-44ad-bf41-d3ba4fa0078e%40mtasv.net.

Re: Recent Entrust Compliance Incidents

[Jonathan Doe]

(Posting anonymously to protect my employer).

Entrust appear to be threatening existing customers with revocation of 
still-valid certs if contracts are not renewed.

I have seen with our own discussions with Entrust as well as those from 
others in my network. We were told we could not get a short-term extension 
to the Entrust contract while these issues are ongoing, and if we did not 
renew the contract, all active certificates would be revoked.

I know this isn't a direct violation of any guideline, but it has been 
discussed before and was frowned upon by the Chrome team 
(https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13151.html).
I cannot imagine Mozilla, Microsoft or Apple would support this.

Can Entrust comment on why they are holding customers hostage? Especially 
with recent webinars telling customers to replace/renew in advance of the 
distrust, but now threatening revocation if contracts are not renewed?

On Thursday, July 25, 2024 at 3:04:43 PM UTC+1 Claves Nostrum wrote:

> How would that work from an auditing perspective? 
>
> Given the minimally accepted period-under-audit for period-over-time 
> audits is 3 months it sounds overly ambitious to get all the systemic 
> issues that lead to the distrust remediated, execute all controls in an 
> orderly fashion, and obtain an unqualified WebTrust for RA period-over-time 
> report prior to October 31st 2024. Or are you suggesting that SSL.COM 
> would be willing to accept you as an External RA without being able to 
> present an unqualified WebTrust for RA period-over-time report? 
>
> Would be good to get transparency on the plans and their feasibility, and 
> also the acceptance criteria from SSL.COM for Entrust to be an external 
> RA. 
>
> Op do 25 jul 2024 om 00:10 schreef 'Bruce Morton' via 
> dev-secur...@mozilla.org :
>
>> Claves, thank you for the question, as I re-read the blog post it seems 
>> we could have been clearer.
>>
>>
>>- We are not yet providing certificates issued from SSL.com. Our 
>>intent was to announce the partnership with SSL.com and communicate our 
>>plan for how we will provide continuity to our customers for public TLS 
>>certificates after October 31. Our next step is to do the work necessary 
>> to 
>>have this capability in place before that time.
>>- Our plan is to serve as an external RA, with SSL.com as the CA, as 
>>provided for in the Baseline Requirements, section 1.3.2. Beforehand, we 
>>will complete the required reviews and approval from SSL.com, as outlined 
>>in the BRs section 1.3.2, 5.3.1, and 5.5.2. As part of this process, we 
>>will undergo a WebTrust Audit for RAs.
>>
>> We are committed to operating under the CA/Browser Forum Baseline 
>> Requirements, and completing the improvement plans we’ve communicated to 
>> this community. We hope this demonstrates that we are approaching this 
>> arrangement with due rigor, and our commitment to improve our compliance 
>> and incident handling.
>>
>> On Tuesday, July 23, 2024 at 10:58:27 AM UTC-4 Claves Nostrum wrote:
>>
>> It appears that Entrust is now providing its customers with certificates 
>> from SSL.COM: 
>> https://www.entrust.com/blog/2024/07/announcing-our-new-tls-solution-offering/
>> Given the type of customers that Entrust was serving it must imply they 
>> are at least acting as a Delegated Third Party or External RA for those 
>> certificates
>> The blogpost also seems to suggest they are acting as an External RA for 
>> SSL.COM
>> Could Entrust and SSL.COM provide insights in which construct they are 
>> working together (reseller, Delegated Third Party or External RA)?
>> If it is an External RA how did SSL.COM evaluate and accept the risk 
>> given the numerous (vetting) compliance incidents Entrust has recently had 
>> and their failure to timely replace the certificates?
>>
>> Op do 4 jul 2024 om 18:39 schreef Watson Ladd :
>>
>>
>>
>> On Thu, Jul 4, 2024, 11:49 AM 'Bruce Morton' via dev-secur...@mozilla.org 
>>  wrote:
>>
>>
>>
>> On Tuesday, June 25, 2024 at 5:19:22 PM UTC-4 Mike Shaver wrote:
>>
>> While you’re addressing comments, I’d appreciate an answer to my question 
>> here: what was the motivation behind redacting that portion of the email to 
>> customers, if not to conceal information related to redaction procedures?
>>
>> You want to make it clear that you aren’t concealing anything, but you 
>> haven’t given us any reason to believe otherwise.
>>
>> Mike
>>
>>
>> The letter was shared as an example of what was sent from us directly to 
>> a subscriber. The question posed was “what was the contents of the email 
>> sent to providers asking for revocation to begin with?”. We posted the 
>> communication’s contents in the thread and removed the step-by-step 
>> instructions and the contact information for support as we didn’t feel that 
>> was the request’s focus. It was not redacted to conceal the specific 
>> instructions provided and the full letter w

Re: Recent Entrust Compliance Incidents

[Claves Nostrum]

How would that work from an auditing perspective?

Given the minimally accepted period-under-audit for period-over-time audits
is 3 months it sounds overly ambitious to get all the systemic issues that
lead to the distrust remediated, execute all controls in an orderly
fashion, and obtain an unqualified WebTrust for RA period-over-time report
prior to October 31st 2024. Or are you suggesting that SSL.COM would be
willing to accept you as an External RA without being able to present an
unqualified WebTrust for RA period-over-time report?

Would be good to get transparency on the plans and their feasibility, and
also the acceptance criteria from SSL.COM for Entrust to be an external RA.

Op do 25 jul 2024 om 00:10 schreef 'Bruce Morton' via
dev-security-policy@mozilla.org :

> Claves, thank you for the question, as I re-read the blog post it seems we
> could have been clearer.
>
>
>- We are not yet providing certificates issued from SSL.com. Our
>intent was to announce the partnership with SSL.com and communicate our
>plan for how we will provide continuity to our customers for public TLS
>certificates after October 31. Our next step is to do the work necessary to
>have this capability in place before that time.
>- Our plan is to serve as an external RA, with SSL.com as the CA, as
>provided for in the Baseline Requirements, section 1.3.2. Beforehand, we
>will complete the required reviews and approval from SSL.com, as outlined
>in the BRs section 1.3.2, 5.3.1, and 5.5.2. As part of this process, we
>will undergo a WebTrust Audit for RAs.
>
> We are committed to operating under the CA/Browser Forum Baseline
> Requirements, and completing the improvement plans we’ve communicated to
> this community. We hope this demonstrates that we are approaching this
> arrangement with due rigor, and our commitment to improve our compliance
> and incident handling.
>
> On Tuesday, July 23, 2024 at 10:58:27 AM UTC-4 Claves Nostrum wrote:
>
> It appears that Entrust is now providing its customers with certificates
> from SSL.COM:
> https://www.entrust.com/blog/2024/07/announcing-our-new-tls-solution-offering/
> Given the type of customers that Entrust was serving it must imply they
> are at least acting as a Delegated Third Party or External RA for those
> certificates
> The blogpost also seems to suggest they are acting as an External RA for
> SSL.COM
> Could Entrust and SSL.COM provide insights in which construct they are
> working together (reseller, Delegated Third Party or External RA)?
> If it is an External RA how did SSL.COM evaluate and accept the risk
> given the numerous (vetting) compliance incidents Entrust has recently had
> and their failure to timely replace the certificates?
>
> Op do 4 jul 2024 om 18:39 schreef Watson Ladd :
>
>
>
> On Thu, Jul 4, 2024, 11:49 AM 'Bruce Morton' via dev-secur...@mozilla.org
>  wrote:
>
>
>
> On Tuesday, June 25, 2024 at 5:19:22 PM UTC-4 Mike Shaver wrote:
>
> While you’re addressing comments, I’d appreciate an answer to my question
> here: what was the motivation behind redacting that portion of the email to
> customers, if not to conceal information related to redaction procedures?
>
> You want to make it clear that you aren’t concealing anything, but you
> haven’t given us any reason to believe otherwise.
>
> Mike
>
>
> The letter was shared as an example of what was sent from us directly to a
> subscriber. The question posed was “what was the contents of the email sent
> to providers asking for revocation to begin with?”. We posted the
> communication’s contents in the thread and removed the step-by-step
> instructions and the contact information for support as we didn’t feel that
> was the request’s focus. It was not redacted to conceal the specific
> instructions provided and the full letter was shared in its entirety
> quickly after it was requested.
>
>
> The fact that you literally wrote that you "removed the step by step
> instructions" than say it wasn't "redacted to conceal the instructions" you
> removed literally 13 words later demonstrates an astonishing predilection
> for casuistry.
>
> The only interpretation I can come up with is that these words were
> removed accidentally, showing a profound lack of care in communications
> with DSP.
>
> Sincerely,
> Watson Ladd
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "
> dev-secur...@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dev-security-po...@mozilla.org.
> To view this discussion on the web visit
> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b4dcb651-aec5-4f2e-8325-9aafa2f9ea58n%40mozilla.org
> 
> .
>
> --
> You received this message because you are subscribed to the Google Groups "
> dev-secur..

Re: Recent Entrust Compliance Incidents

[Watson Ladd]

On Wed, Jul 24, 2024 at 3:10 PM 'Bruce Morton' via
dev-security-policy@mozilla.org 
wrote:
>
> Claves, thank you for the question, as I re-read the blog post it seems we 
> could have been clearer.
>
> We are not yet providing certificates issued from SSL.com. Our intent was to 
> announce the partnership with SSL.com and communicate our plan for how we 
> will provide continuity to our customers for public TLS certificates after 
> October 31. Our next step is to do the work necessary to have this capability 
> in place before that time.
> Our plan is to serve as an external RA, with SSL.com as the CA, as provided 
> for in the Baseline Requirements, section 1.3.2. Beforehand, we will complete 
> the required reviews and approval from SSL.com, as outlined in the BRs 
> section 1.3.2, 5.3.1, and 5.5.2. As part of this process, we will undergo a 
> WebTrust Audit for RAs.
>
> We are committed to operating under the CA/Browser Forum Baseline 
> Requirements, and completing the improvement plans we’ve communicated to this 
> community. We hope this demonstrates that we are approaching this arrangement 
> with due rigor, and our commitment to improve our compliance and incident 
> handling.

Several of the incidents where Entrust failed involve functions that
1.3.2 permits delegation of. I'd like to see more clarity about how
these risks are managed, and what precisely is being delegated.

To StartSSL: Responsibility is a unique concept. You may share it but
your portion is not diminished.

Sincerely,
Watson Ladd

-- 
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/CACsn0cky6GQ3bnoObN49A68KDWDr4fQPBwMF2kjiqwYfD3rE1w%40mail.gmail.com.

Re: Recent Entrust Compliance Incidents

['Bruce Morton' via dev-security-policy@mozilla.org]

Claves, thank you for the question, as I re-read the blog post it seems we 
could have been clearer.


   - We are not yet providing certificates issued from SSL.com. Our intent 
   was to announce the partnership with SSL.com and communicate our plan for 
   how we will provide continuity to our customers for public TLS certificates 
   after October 31. Our next step is to do the work necessary to have this 
   capability in place before that time.
   - Our plan is to serve as an external RA, with SSL.com as the CA, as 
   provided for in the Baseline Requirements, section 1.3.2. Beforehand, we 
   will complete the required reviews and approval from SSL.com, as outlined 
   in the BRs section 1.3.2, 5.3.1, and 5.5.2. As part of this process, we 
   will undergo a WebTrust Audit for RAs.

We are committed to operating under the CA/Browser Forum Baseline 
Requirements, and completing the improvement plans we’ve communicated to 
this community. We hope this demonstrates that we are approaching this 
arrangement with due rigor, and our commitment to improve our compliance 
and incident handling.

On Tuesday, July 23, 2024 at 10:58:27 AM UTC-4 Claves Nostrum wrote:

It appears that Entrust is now providing its customers with certificates 
from SSL.COM: 
https://www.entrust.com/blog/2024/07/announcing-our-new-tls-solution-offering/
Given the type of customers that Entrust was serving it must imply they are 
at least acting as a Delegated Third Party or External RA for those 
certificates
The blogpost also seems to suggest they are acting as an External RA for 
SSL.COM
Could Entrust and SSL.COM provide insights in which construct they are 
working together (reseller, Delegated Third Party or External RA)?
If it is an External RA how did SSL.COM evaluate and accept the risk given 
the numerous (vetting) compliance incidents Entrust has recently had and 
their failure to timely replace the certificates?

Op do 4 jul 2024 om 18:39 schreef Watson Ladd :



On Thu, Jul 4, 2024, 11:49 AM 'Bruce Morton' via dev-secur...@mozilla.org <
dev-secur...@mozilla.org> wrote:



On Tuesday, June 25, 2024 at 5:19:22 PM UTC-4 Mike Shaver wrote:

While you’re addressing comments, I’d appreciate an answer to my question 
here: what was the motivation behind redacting that portion of the email to 
customers, if not to conceal information related to redaction procedures?

You want to make it clear that you aren’t concealing anything, but you 
haven’t given us any reason to believe otherwise.

Mike


The letter was shared as an example of what was sent from us directly to a 
subscriber. The question posed was “what was the contents of the email sent 
to providers asking for revocation to begin with?”. We posted the 
communication’s contents in the thread and removed the step-by-step 
instructions and the contact information for support as we didn’t feel that 
was the request’s focus. It was not redacted to conceal the specific 
instructions provided and the full letter was shared in its entirety 
quickly after it was requested.  


The fact that you literally wrote that you "removed the step by step 
instructions" than say it wasn't "redacted to conceal the instructions" you 
removed literally 13 words later demonstrates an astonishing predilection 
for casuistry.

The only interpretation I can come up with is that these words were removed 
accidentally, showing a profound lack of care in communications with DSP.

Sincerely,
Watson Ladd

 

-- 
You received this message because you are subscribed to the Google Groups "
dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an 
email to dev-security-po...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b4dcb651-aec5-4f2e-8325-9aafa2f9ea58n%40mozilla.org
 

.

-- 
You received this message because you are subscribed to the Google Groups "
dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an 
email to dev-security-po...@mozilla.org.

To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CACsn0cnV%2B3b3XM8Xi8r8b5w%2BP3oQ%2BAer_vt8HmZdLyw7QMV5Pw%40mail.gmail.com
 

.

-- 
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/8b89eed0

Re: Recent Entrust Compliance Incidents

[Claves Nostrum]

It appears that Entrust is now providing its customers with certificates
from SSL.COM:
https://www.entrust.com/blog/2024/07/announcing-our-new-tls-solution-offering/
Given the type of customers that Entrust was serving it must imply they are
at least acting as a Delegated Third Party or External RA for those
certificates
The blogpost also seems to suggest they are acting as an External RA for
SSL.COM
Could Entrust and SSL.COM provide insights in which construct they are
working together (reseller, Delegated Third Party or External RA)?
If it is an External RA how did SSL.COM evaluate and accept the risk given
the numerous (vetting) compliance incidents Entrust has recently had and
their failure to timely replace the certificates?

Op do 4 jul 2024 om 18:39 schreef Watson Ladd :

>
>
> On Thu, Jul 4, 2024, 11:49 AM 'Bruce Morton' via
> dev-security-policy@mozilla.org  wrote:
>
>>
>>
>> On Tuesday, June 25, 2024 at 5:19:22 PM UTC-4 Mike Shaver wrote:
>>
>> While you’re addressing comments, I’d appreciate an answer to my question
>> here: what was the motivation behind redacting that portion of the email to
>> customers, if not to conceal information related to redaction procedures?
>>
>> You want to make it clear that you aren’t concealing anything, but you
>> haven’t given us any reason to believe otherwise.
>>
>> Mike
>>
>>
>> The letter was shared as an example of what was sent from us directly to
>> a subscriber. The question posed was “what was the contents of the email
>> sent to providers asking for revocation to begin with?”. We posted the
>> communication’s contents in the thread and removed the step-by-step
>> instructions and the contact information for support as we didn’t feel that
>> was the request’s focus. It was not redacted to conceal the specific
>> instructions provided and the full letter was shared in its entirety
>> quickly after it was requested.
>>
>
> The fact that you literally wrote that you "removed the step by step
> instructions" than say it wasn't "redacted to conceal the instructions" you
> removed literally 13 words later demonstrates an astonishing predilection
> for casuistry.
>
> The only interpretation I can come up with is that these words were
> removed accidentally, showing a profound lack of care in communications
> with DSP.
>
> Sincerely,
> Watson Ladd
>
>
>>
>> --
>> 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/b4dcb651-aec5-4f2e-8325-9aafa2f9ea58n%40mozilla.org
>> 
>> .
>>
> --
> 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/CACsn0cnV%2B3b3XM8Xi8r8b5w%2BP3oQ%2BAer_vt8HmZdLyw7QMV5Pw%40mail.gmail.com
> 
> .
>

-- 
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/CAOY5%3DRBkecUG_5XrpNrxQR1CvOMmXbAnsVM-pXiXhMrec978fQ%40mail.gmail.com.

Re: Recent Entrust Compliance Incidents

[Watson Ladd]

On Thu, Jul 4, 2024, 11:49 AM 'Bruce Morton' via
dev-security-policy@mozilla.org  wrote:

>
>
> On Tuesday, June 25, 2024 at 5:19:22 PM UTC-4 Mike Shaver wrote:
>
> While you’re addressing comments, I’d appreciate an answer to my question
> here: what was the motivation behind redacting that portion of the email to
> customers, if not to conceal information related to redaction procedures?
>
> You want to make it clear that you aren’t concealing anything, but you
> haven’t given us any reason to believe otherwise.
>
> Mike
>
>
> The letter was shared as an example of what was sent from us directly to a
> subscriber. The question posed was “what was the contents of the email sent
> to providers asking for revocation to begin with?”. We posted the
> communication’s contents in the thread and removed the step-by-step
> instructions and the contact information for support as we didn’t feel that
> was the request’s focus. It was not redacted to conceal the specific
> instructions provided and the full letter was shared in its entirety
> quickly after it was requested.
>

The fact that you literally wrote that you "removed the step by step
instructions" than say it wasn't "redacted to conceal the instructions" you
removed literally 13 words later demonstrates an astonishing predilection
for casuistry.

The only interpretation I can come up with is that these words were removed
accidentally, showing a profound lack of care in communications with DSP.

Sincerely,
Watson Ladd


>
> --
> 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/b4dcb651-aec5-4f2e-8325-9aafa2f9ea58n%40mozilla.org
> 
> .
>

-- 
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/CACsn0cnV%2B3b3XM8Xi8r8b5w%2BP3oQ%2BAer_vt8HmZdLyw7QMV5Pw%40mail.gmail.com.

Re: Recent Entrust Compliance Incidents

['Bruce Morton' via dev-security-policy@mozilla.org]

On Tuesday, June 25, 2024 at 5:19:22 PM UTC-4 Mike Shaver wrote:

While you’re addressing comments, I’d appreciate an answer to my question 
here: what was the motivation behind redacting that portion of the email to 
customers, if not to conceal information related to redaction procedures?

You want to make it clear that you aren’t concealing anything, but you 
haven’t given us any reason to believe otherwise.

Mike


The letter was shared as an example of what was sent from us directly to a 
subscriber. The question posed was “what was the contents of the email sent 
to providers asking for revocation to begin with?”. We posted the 
communication’s contents in the thread and removed the step-by-step 
instructions and the contact information for support as we didn’t feel that 
was the request’s focus. It was not redacted to conceal the specific 
instructions provided and the full letter was shared in its entirety 
quickly after it was requested.  
 

-- 
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/b4dcb651-aec5-4f2e-8325-9aafa2f9ea58n%40mozilla.org.

Re: Recent Entrust Compliance Incidents

['Bruce Morton' via dev-security-policy@mozilla.org]

On Tuesday, June 25, 2024 at 5:07:19 PM UTC-4 Wayne wrote:

Further to the latest report making no mention of that incident, in 
#1890898 there is a statement of intent of there being a second amended 
final report:
https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c66
> Yes, we will amend the final incident report to reflect that we did our 
analysis 

Is there any intent on there being a final report or is this cycle going to 
continue? If a judgment on Entrust's ability to make concrete statements 
will be made, there needs to be a final statement at some point.


 This update is the final report. We will address future questions through 
responses.

And in regards to your response my statement let us not turn this into an 
ongoing back-and-forth with individuals. I will only address the last 
question whereby Entrust will not share how their new team will show any 
divergence from previous mistakes. The point of asking for an analysis of 
the 'new team' versus what happened historically is to provide any trust 
that the same mistakes will not be repeated but with a new badge in place. 
The lack of confidence in being able to provide that is distressing at this 
stage.

- Wayne

-- 
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/28a4df3b-d545-4c4a-a4f0-8e5e71c5e9ben%40mozilla.org.

Re: Recent Entrust Compliance Incidents

['Ben Wilson' via dev-security-policy@mozilla.org]

All,

We want to thank everybody who has participated in the discussion for their 
detailed reviews of Entrust's updated report and thoughtful contributions. 
We have not yet made a final decision and are reviewing the community's 
comments and Entrust's updated response closely.

Sincerely yours,

Ben Wilson
Mozilla Root Store Manager

On Thursday, June 27, 2024 at 3:04:03 PM UTC-6 Mike Shaver wrote:

> I don't know what the calculus will be for Google's trust of 
> Entrust-issued BIMI certificates, but I am pretty sure that they won't be 
> announcing that policy on MDSP—you could ask in a Google forum of some 
> kind, but I think most likely you just have to wait for the announcement 
> if/when it comes.
>
> (I personally think Entrust will not keep the BIMI business around by 
> itself even if the root somehow stays trusted, but it's possible they were 
> completely compliant with all BIMI-related requirements!)
>
> Mike
>
>
> On Thu, Jun 27, 2024 at 4:51 PM Kurt Seifried  wrote:
>
>> We've never had a situation like this, partly due to the fact there are 
>> only two VMC sellers, Entrust and Digicert (as I understand it everyone 
>> else selling these is a reseller). But I can't see why the issues at 
>> Entrust would be restricted to their web cert business and not the VMC 
>> business (which are virtually identical products/processes). And thus I 
>> can't imagine why the rest of Google wouldn't remove their trust in Entrust 
>> as well.
>>
>> On Thu, Jun 27, 2024 at 2:47 PM Mike Shaver  
>> wrote:
>>
>>> AFAIK, BIMI certs are not related to the browser root stores in any way, 
>>> and aren’t signed by server certificate roots.
>>>
>>> Mike
>>>
>>> On Thu, Jun 27, 2024 at 4:31 PM 'Kurt Seifried' via 
>>> dev-security-policy@mozilla.org  wrote:
>>>
 Also do we know what is happening with their VMC root cert? CN = 
 Entrust Verified Mark Root Certification Authority - VMCR1 which is used 
 for Verified Mark Certificates aka BIMI logos, and is currently supported 
 in Gmail? Do we know if Gmail be removing support for Entrust based VMC 
 certificates and thus BIMI logos done via Entrust? Seeing as how your 
 choices for buying a BIMI/VMC cert are Entrust (or a reseller) and 
 Digicert 
 the removal of trust in CN = Entrust Verified Mark Root Certification 
 Authority - VMCR1 will basically break most BIMI logos in any email 
 platform that supports BIMI and decides to remove Entrust..

 Example:

 $ wget https://bimi.entrust.net/cloudsecurityalliance.org/certchain.pem
 $ while openssl x509 -noout -text; do :; done < certchain.pem

 And for additional context on who uses Entrust: 
 https://bimiradar.com/glob#logos

 -- 
 Kurt Seifried (He/Him)
 k...@seifried.org

 -- 
 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/CABqVa39KCFVyaMWOfMR%3Dc%3DskCK8byzjmX6unva0RCLe8Z_5uWA%40mail.gmail.com
  
 
 .

>>>
>>
>> -- 
>> Kurt Seifried (He/Him)
>> k...@seifried.org
>>
>

-- 
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/47aaa5ec-9309-4406-ba5e-376a4812186bn%40mozilla.org.

Re: Recent Entrust Compliance Incidents

[Mike Shaver]

I don't know what the calculus will be for Google's trust of Entrust-issued
BIMI certificates, but I am pretty sure that they won't be announcing that
policy on MDSP—you could ask in a Google forum of some kind, but I think
most likely you just have to wait for the announcement if/when it comes.

(I personally think Entrust will not keep the BIMI business around by
itself even if the root somehow stays trusted, but it's possible they were
completely compliant with all BIMI-related requirements!)

Mike


On Thu, Jun 27, 2024 at 4:51 PM Kurt Seifried  wrote:

> We've never had a situation like this, partly due to the fact there are
> only two VMC sellers, Entrust and Digicert (as I understand it everyone
> else selling these is a reseller). But I can't see why the issues at
> Entrust would be restricted to their web cert business and not the VMC
> business (which are virtually identical products/processes). And thus I
> can't imagine why the rest of Google wouldn't remove their trust in Entrust
> as well.
>
> On Thu, Jun 27, 2024 at 2:47 PM Mike Shaver  wrote:
>
>> AFAIK, BIMI certs are not related to the browser root stores in any way,
>> and aren’t signed by server certificate roots.
>>
>> Mike
>>
>> On Thu, Jun 27, 2024 at 4:31 PM 'Kurt Seifried' via
>> dev-security-policy@mozilla.org  wrote:
>>
>>> Also do we know what is happening with their VMC root cert? CN = Entrust
>>> Verified Mark Root Certification Authority - VMCR1 which is used for
>>> Verified Mark Certificates aka BIMI logos, and is currently supported in
>>> Gmail? Do we know if Gmail be removing support for Entrust based VMC
>>> certificates and thus BIMI logos done via Entrust? Seeing as how your
>>> choices for buying a BIMI/VMC cert are Entrust (or a reseller) and Digicert
>>> the removal of trust in CN = Entrust Verified Mark Root Certification
>>> Authority - VMCR1 will basically break most BIMI logos in any email
>>> platform that supports BIMI and decides to remove Entrust..
>>>
>>> Example:
>>>
>>> $ wget https://bimi.entrust.net/cloudsecurityalliance.org/certchain.pem
>>> $ while openssl x509 -noout -text; do :; done < certchain.pem
>>>
>>> And for additional context on who uses Entrust:
>>> https://bimiradar.com/glob#logos
>>>
>>> --
>>> Kurt Seifried (He/Him)
>>> k...@seifried.org
>>>
>>> --
>>> 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/CABqVa39KCFVyaMWOfMR%3Dc%3DskCK8byzjmX6unva0RCLe8Z_5uWA%40mail.gmail.com
>>> 
>>> .
>>>
>>
>
> --
> Kurt Seifried (He/Him)
> k...@seifried.org
>

-- 
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/CADQzZqvp-RMEB3QbuydSiEz1-jKY7_TSiuLDj1ntMaB8ALoeGw%40mail.gmail.com.

Re: Recent Entrust Compliance Incidents

['Kurt Seifried' via dev-security-policy@mozilla.org]

We've never had a situation like this, partly due to the fact there are
only two VMC sellers, Entrust and Digicert (as I understand it everyone
else selling these is a reseller). But I can't see why the issues at
Entrust would be restricted to their web cert business and not the VMC
business (which are virtually identical products/processes). And thus I
can't imagine why the rest of Google wouldn't remove their trust in Entrust
as well.

On Thu, Jun 27, 2024 at 2:47 PM Mike Shaver  wrote:

> AFAIK, BIMI certs are not related to the browser root stores in any way,
> and aren’t signed by server certificate roots.
>
> Mike
>
> On Thu, Jun 27, 2024 at 4:31 PM 'Kurt Seifried' via
> dev-security-policy@mozilla.org  wrote:
>
>> Also do we know what is happening with their VMC root cert? CN = Entrust
>> Verified Mark Root Certification Authority - VMCR1 which is used for
>> Verified Mark Certificates aka BIMI logos, and is currently supported in
>> Gmail? Do we know if Gmail be removing support for Entrust based VMC
>> certificates and thus BIMI logos done via Entrust? Seeing as how your
>> choices for buying a BIMI/VMC cert are Entrust (or a reseller) and Digicert
>> the removal of trust in CN = Entrust Verified Mark Root Certification
>> Authority - VMCR1 will basically break most BIMI logos in any email
>> platform that supports BIMI and decides to remove Entrust..
>>
>> Example:
>>
>> $ wget https://bimi.entrust.net/cloudsecurityalliance.org/certchain.pem
>> $ while openssl x509 -noout -text; do :; done < certchain.pem
>>
>> And for additional context on who uses Entrust:
>> https://bimiradar.com/glob#logos
>>
>> --
>> Kurt Seifried (He/Him)
>> k...@seifried.org
>>
>> --
>> 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/CABqVa39KCFVyaMWOfMR%3Dc%3DskCK8byzjmX6unva0RCLe8Z_5uWA%40mail.gmail.com
>> 
>> .
>>
>

-- 
Kurt Seifried (He/Him)
k...@seifried.org

-- 
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/CABqVa38gVQP%2BO%2BL11G%2BrObdYWbMFcV_bkT%3DAVGAMNnkXyFtiAQ%40mail.gmail.com.

Re: Recent Entrust Compliance Incidents

[Mike Shaver]

AFAIK, BIMI certs are not related to the browser root stores in any way,
and aren’t signed by server certificate roots.

Mike

On Thu, Jun 27, 2024 at 4:31 PM 'Kurt Seifried' via
dev-security-policy@mozilla.org  wrote:

> Also do we know what is happening with their VMC root cert? CN = Entrust
> Verified Mark Root Certification Authority - VMCR1 which is used for
> Verified Mark Certificates aka BIMI logos, and is currently supported in
> Gmail? Do we know if Gmail be removing support for Entrust based VMC
> certificates and thus BIMI logos done via Entrust? Seeing as how your
> choices for buying a BIMI/VMC cert are Entrust (or a reseller) and Digicert
> the removal of trust in CN = Entrust Verified Mark Root Certification
> Authority - VMCR1 will basically break most BIMI logos in any email
> platform that supports BIMI and decides to remove Entrust..
>
> Example:
>
> $ wget https://bimi.entrust.net/cloudsecurityalliance.org/certchain.pem
> $ while openssl x509 -noout -text; do :; done < certchain.pem
>
> And for additional context on who uses Entrust:
> https://bimiradar.com/glob#logos
>
> --
> Kurt Seifried (He/Him)
> k...@seifried.org
>
> --
> 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/CABqVa39KCFVyaMWOfMR%3Dc%3DskCK8byzjmX6unva0RCLe8Z_5uWA%40mail.gmail.com
> 
> .
>

-- 
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/CADQzZqv%2B1gUHKEKcCMDX1M6XOGntVeJ2fZD6pr0HUM%3D_KnZYuQ%40mail.gmail.com.

Re: Recent Entrust Compliance Incidents

['Kurt Seifried' via dev-security-policy@mozilla.org]

Also do we know what is happening with their VMC root cert? CN = Entrust
Verified Mark Root Certification Authority - VMCR1 which is used for
Verified Mark Certificates aka BIMI logos, and is currently supported in
Gmail? Do we know if Gmail be removing support for Entrust based VMC
certificates and thus BIMI logos done via Entrust? Seeing as how your
choices for buying a BIMI/VMC cert are Entrust (or a reseller) and Digicert
the removal of trust in CN = Entrust Verified Mark Root Certification
Authority - VMCR1 will basically break most BIMI logos in any email
platform that supports BIMI and decides to remove Entrust..

Example:

$ wget https://bimi.entrust.net/cloudsecurityalliance.org/certchain.pem
$ while openssl x509 -noout -text; do :; done < certchain.pem

And for additional context on who uses Entrust:
https://bimiradar.com/glob#logos

-- 
Kurt Seifried (He/Him)
k...@seifried.org

-- 
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/CABqVa39KCFVyaMWOfMR%3Dc%3DskCK8byzjmX6unva0RCLe8Z_5uWA%40mail.gmail.com.

Re: Recent Entrust Compliance Incidents

[Tyrel]

While this revised report and letter from leadership is a substantial 
improvement compared to what was submitted on June 7th, I share a number of 
the concerns raised by others here:

1) Swaroop's letter contains the line "As a global CA we must walk a 
tightrope in balancing the requirements of the root programs and subscriber 
needs, especially for critical infrastructure." There is no tightrope to 
walk here. As a custodian of public trust, a CA must transparently and 
strictly enforce the rules under which they operate. Subscribers will then 
take appropriate actions to reach an acceptable level of risk for their 
operations, which, for critical infrastructure subscribers, could mean 
anything from having hot spare certificates from an alternate CA ready to 
go, to migration to a privatePKI. That nearly the highest level of 
Entrust's leadership still does not recognize this has me worried that this 
is lipstick on a pig rather than actual meaningful change.

2) Though very pretty in language, these documents are shockingly light on 
quantitative, externally measurable, metrics on which to define 
improvement. I would have at a minimum expected Entrust to commit to almost 
never delay revocation again (e.g. "we commit to delaying revocation of no 
more than one certificate per thousand in future incidents"), to commit to 
not knowingly issue certificates to subscribers for whom revocation in 24 
hr/5 days would cause significant harm, and to commit to other actions that 
help meaningfully move the webPKI ecosystem towards agility and resilience 
(such as issuing certificates with lifetimes of no more than 1/2 year 
starting "now", and 1/4 year starting January 2025). Even the commitments 
to automation and ARI are shallow, missing, e.g., a commitment to not 
charge customers more for using them, and missing quantitative targets for 
the fraction of subscribers to be on fully automated certificate pipelines 
by particular dates. Instead this report commits to almost nothing that is 
publicly measurable, and comments from Entrust representatives on various 
open bugs, even after June 21st, make clear that they are unwilling to 
commit to a quantitative limit on revocation delays, and all but state they 
will continue to issue certs to subscribers who cannot tolerate a 24 hr / 5 
day revocation timeline. I think that the lack of concrete metrics is a 
serious deficiency. 

3) It is impossible to tell given the shifting language, but it seems to me 
that, as of this report, Entrust still disagrees 
with https://bugzilla.mozilla.org/show_bug.cgi?id=1890898 
and https://bugzilla.mozilla.org/show_bug.cgi?id=1890685 being misissuance 
events. This I think also speaks volumes about the proposed changes in 
operation not being changes that meaningfully alter the outcomes of how 
Entrust behaves as a CA.

Based on these observations, and those of others on this thread, I highly 
encourage mozilla and other root store operators to distrust Entrust as 
soon as practicable, e.g. to immediately distrust all Entrust certificates 
with a not-before of July 1, 2024 or later, and rapidly phasing out the 
roots. And if Entrust believes they have made meaningful changes that make 
them again deserving of public trust, that they reapply for inclusion at a 
later date.

Tyrel

PS: For the Entrust business leadership: this is not the end of the world 
in providing certificates for your customers. Nothing prevents you from 
becoming a reseller (even a branded reseller) of certificates from another 
public CA.
On Friday, June 21, 2024 at 2:59:25 PM UTC-4 Bruce Morton wrote:

> Attached is a letter from Bhagwat Swaroop, President of Entrust Digital 
> Security Solutions, along with an updated response to address questions 
> from the community.
>
> Thanks, Bruce.
>
> On Tuesday, June 18, 2024 at 1:35:48 PM UTC-4 Amir Omidi (aaomidi) wrote:
>
>> I am not going to say with certainty that Entrust is definitely putting 
>> Chrome over Mozilla. However, I hope they know that most Linux systems out 
>> there use the Mozilla root store directly.
>> On Tuesday, June 18, 2024 at 1:12:19 PM UTC-4 Mike Shaver wrote:
>>
>>> On Tue, Jun 18, 2024 at 12:49 PM Walt  wrote:
>>>
 I'd just like to point out that we now have a situation where Entrust 
 is in the position of seemingly valuing the opinion of other Root Programs 
 over Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c42

 In Comment #37, it was hinted at (and made slightly more explicit in 
 #39) that the opinion of the Mozilla RP is that the attempt to 
 re-characterize these certs was not going to be looked kindly upon, and 
 only once a Google RP member explicitly said that it was the Google RP 
 opinion that the certs remained mis-issued was any movement made on 
 re-confirming the mis-issuance and taking action to revoke them.

 Also, if we're in a position where Entrust is finally able to commit to 
 revoking cer

Re: Recent Entrust Compliance Incidents

[Mike Shaver]

I apologize for the length, but I didn't find places where I could remove
things that were not IMO material to Mozilla's evaluation of Entrust as a
root, or constructive advice that I genuinely wish Entrust to incorporate
into their plans.
Thoughts on Entrust’s revised report

I'm not going to quote and cite individual missteps extensively, but if I'm
misrepresenting something I'm happy to dig up the things that I used as
inputs, and make corrections. Instead, I'm trying to summarize some themes
that continue to concern me even after Entrust's updated report and
responses.

In summary, while I think Entrust was wise to reuse the Navex guide to
Compliance Program assessment, I don't feel they have done so in a way that
sufficiently allays concerns about their willingness and indeed ability to
operate within the BRs and MRSP, consistently and in good faith. Looking
critically at how Entrust has described its actions and decisions shows, in
my opinion, not only a company that has been unable to meet the
expectations to which CAs must be held, but indeed a company that either
doesn't understand or doesn't accept what those expectations are.
Apportionment of Risk and Responsibility

Entrust continues to be mistaken about their responsibilities in the WebPKI
and MRSP. They say that the subscriber cannot be held responsible for
operational limitations on certificate deployment. On the contrary, only
the subscriber can be responsible for their own operations, within the
CA/root-program/Subscriber/relying-party dynamic of WebPKI. Only the
subscriber can ultimately make changes to their own operations, and they
will bear the cost. Entrust as a security vendor can take on some
responsibility for enabling better Subscriber operations, but their degree
of success with that should not bear positively or negatively on the
evaluation of Entrust as a CA.

They also describe being in "tension" between WebPKI and critical systems
but omit that this tension is entirely of their own continuous creation,
versus reducing, since 2020, the cases in which they encourage or permit
subscribers to use web PKI certificates in circumstances incompatible with
the operational properties of the web PKI.

Entrust's action items for delayed revocation often have elements of
encouraging subscribers to adopt automation. I think that is a fine thing
for them to do, but IMO it should not be considered to be a remediation for
a delayed revocation incident, because it's not up to subscribers to decide
on delayed revocation. To treat it as remediation is to say that subscriber
choices to invest (or not) in improvements to their certificate management
operations are allowed to prevent a CA from upholding the requirements. The
message needs to be "you might want to improve your operations so you don't
have an outage the next time we need to revoke one of your certificates,
which we will do on time", not "please improve your operations so that we
are able to revoke the certificate we chose to issue you".

The Improvement Plan says that they will "work with our subscribers to
ensure awareness and minimize delayed revocation requests". This language
echoes the 2020 commitments, but does not give any meaningful description
of a future state they’re seeking. I don't care how many delayed revocation
requests they get. That's a function of whether they choose to issue and
reissue Web PKI certificates into environments that they know "cannot"
actually tolerate immediate revocation in spite of the subscriber's legal
commitment to the contrary. Entrust can't solve this problem by reducing
the number of times they get asked for exceptions. They have to ensure that
they have appropriately narrow exception criteria regardless of how many
requests they get . Are we to believe that if Entrust gets more requests in
the future, they will permit more exceptions? It's hard to understand why
that is relevant to their improvement except that it might cause fewer
customers to be disappointed or frustrated; that would be an improvement to
Entrust's experience as a vendor, but not material to how Entrust or its
Subscribers interact with the web PKI.

When Entrust decides that it must delay revocation due to intolerable
impact on the web ecosystem (paging the Definitions & Glossary WG), proper
remediation actions would include an enforced timeline for the subscriber
being able to tolerate prompt revocation, possibly by being moved off of
web PKI certificates. After that timeline, delayed revocation should no
longer be permitted; if Entrust doesn't want to be in that situation, then
they should not re-issue to that subscriber.

As recently as June 21, presumably with the knowledge that Entrust was
admitting that its practices had been deficient in the updated report, a
representative of Entrust was still defending their previous decisions to
delay revocation. "If the strict enforcement of rules begins to take
priority over the facilitation of safe and smooth internet transact

Re: Recent Entrust Compliance Incidents

[Mike Shaver]

While you’re addressing comments, I’d appreciate an answer to my question
here: what was the motivation behind redacting that portion of the email to
customers, if not to conceal information related to redaction procedures?

You want to make it clear that you aren’t concealing anything, but you
haven’t given us any reason to believe otherwise.

Mike

On Fri, Jun 14, 2024 at 5:01 PM Mike Shaver  wrote:

> On Fri, Jun 14, 2024 at 4:55 PM 'Bruce Morton' via
> dev-security-policy@mozilla.org  wrote:
>
>> Amir, we will respond to the comments from the community, but I want to
>> make it clear that Entrust was absolutely NOT trying to "conceal" anything
>> related to how we do revocation
>>
> You redacted a part of the email about how customers were to go about
> reissuing and revoking, which is *literally* concealing something related
> to revocation. That’s what redacting is. It’s the only reason that anything
> is ever redacted. What are you even trying to say here?
>
> The redacted section provides specific instructions to our subscribers on
>> how to revoke and reissue certificates.
>>
> cool, cool
>
> Why was it important to redact that section? It has no confidential
> information in it as far as I can tell.
>
> I exhort you, for your own sake, to seriously read my guidance in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1886532#c64 as to how to
> properly communicate the reasons for, and details of, the changes that are
> being listed as things that will improve Entrust’s operations.
>
> 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/CADQzZqsBGFtYXejenwaiMTm9NSBgHtY-hkTu6CNtC7GOQ1Shvg%40mail.gmail.com.

Re: Recent Entrust Compliance Incidents

['Bruce Morton' via dev-security-policy@mozilla.org]

On Monday, June 24, 2024 at 1:25:47 PM UTC-4 Walt wrote:

Some final thoughts on this after re-reading the updated report: 

*First*, a deliverable due date is a deliverable due date. If I was asked 
to answer 7 questions by my management team by a given deliverable date, 
and provided a report that barely answered two of them, I'd be thinking 
long and hard about what got me to that point (and the future of my 
continued employment), and why an updated report took an additional two 
weeks to create. I would argue that Entrust should be judged based on the 
initial report primarily, as the due date was very clear, as well as the 
guidelines for assembling the report. The second report *should* have been 
what we saw the first time, but this theme of "Entrust doing closer to the 
right thing late" seems to be a recurring trend with this series of events. 
This even goes as far back as 2020, when there was allegedly a promise that 
this wouldn't happen again (or at least not at the scale it did in 2020) 
and yet here we are. 

*Two*, as Amir noted, there's numerous inconsistencies with the report(s) 
compared to incidents. 

This issue has been prioritized at the highest levels within Entrust. We 
have hundreds of people across Entrust working on remediation—including our 
senior leadership as well as teams from Customer Support, Operations, 
Sales, Legal, Compliance, and Product Management, and we have been working 
hand in hand with executives at Global 2000 companies who are impacted. Our 
colleagues are working around the clock to support our customers, meet CA/B 
Forum expectations, and expedite revocation and re-issuance of affected

followed by saying [paraphrased]: "The work we were doing previously wasn't 
good enough so we tossed it all out". Is the goal in this updated response 
simply to make it seem like enough changes have been made to kick the can 
down the road again for a few more years until Entrust makes some 
relatively simple mistake that could have been caught by linting and then 
we end up in this same boat again?


 The updated report included additional details based on comments and 
feedback that helped us understand the level of detail the community wants 
to have visibility to. 


*Third*, I'll reiterate the fact that Entrust seemingly doesn't take the 
opinion of Mozilla RP and the associated community seriously. The incident 
(#1883843)  that 
started this *all*, was only taken seriously (12 days after posting) when 
the original reporter (who happened to be with Google RP) came in and said 
that the response did not meet Google RP's standards. Only *then* did 
mis-issuance stop. 

*Fourth*, I'll re-iterate as well that pre and post issuance linting feels 
like a pretty table stakes feature to prevent giving customers certificates 
that are mis-issued, avoiding the awkward conversations you seem to 
continually be having with your subscribers. Instead you knowingly issue 
certificates that might be mis-issued to subscribers, don't pause issuance, 
and wind up digging a bigger hole which could have been avoided if Entrust 
team members were empowered to pull the circuit breaker at any time.

*Fifth*, there's very little in this report that's measurable in terms of 
improvement. It digs deeper into what happened sure, but most of these 
metrics require trust in Entrust to be sharing these metrics correctly to 
evaluate their compliance with the report. To put it bluntly, I trust 
Entrust about as much as I could throw Entrust, which is not very far. 
Given that, I see no reason to trust these metrics given by Entrust, and as 
such I see no objective way of measuring these commitments.

In conclusion, I would second Amir's suggestion that Entrust be distrusted, 
and re-apply for inclusion once the organizational deficiencies have been 
resolved.

Walter

-- 
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/4d29a015-5a05-4b3a-81da-5ee99865fe44n%40mozilla.org.

Re: Recent Entrust Compliance Incidents

['Bruce Morton' via dev-security-policy@mozilla.org]

On Monday, June 24, 2024 at 12:43:52 PM UTC-4 Amir Omidi (aaomidi) wrote:

Let's take a step back from this report. I don't think this report deserves 
to be taken seriously for one reason alone: You've historically proven to 
the community that we should not trust any statements made by Entrust. 
Let's look at how you've proven this:

First - Four years ago, you made a couple of promises in comment 6 of 
1651481 :


   

   - 
   
   We will not the make the decision not to revoke.
   

   - 
   
   We will plan to revoke within the 24 hours or 5 days as applicable for 
   the incident.
   
None of these promises have been realized in the past four years. Why is 
this time going to be different? How are we even supposed to measure your 
commitment to your current action items?


Our updated report addresses this. What will be different is addressed in 
the overview section. Action items and metrics are in Appendices 2 & 3. Per 
Bhagwat Swaroop’s letter to the community, we will provide regular progress 
reports to the community. If we receive additional comments that should be 
incorporated into our action plan, we will do that. 


Second - In this report, you're claiming that a lot of these issues stem 
from organizational structure. Meanwhile, 3 months ago, Entrust was 
claiming that: 

This issue has been prioritized at the highest levels within Entrust. We 
have hundreds of people across Entrust working on remediation—including our 
senior leadership as well as teams from Customer Support, Operations, 
Sales, Legal, Compliance, and Product Management, and we have been working 
hand in hand with executives at Global 2000 companies who are impacted. Our 
colleagues are working around the clock to support our customers, meet CA/B 
Forum expectations, and expedite revocation and re-issuance of affected

So putting these two together, what Entrust seems to be doing is pressing 
shuffle on the same playlist that's led to all of this.

Third - As you were sending out this Entrust Report 
Final-ForRealThisTime.pdf, we had Entrust continue to make nonsensical 
arguments . Even 
after it was pointed out by both Chrome 
, and Mozilla 
, that what 
you're doing is not okay.

To be very clear here, this comment by Entrust was made on 2024-06-19 while 
we received this new report from Entrust on 2024-06-21. Entrust has not 
even bothered covering this incident in this report.

Fourth - As evidenced in your recent incident responses, you don't really 
care about 1) what the community says 2) what Mozilla says. Time and time 
again, I've only seen Entrust change their tune on matters when Ryan 
Dickson (Specifically, Chrome Root Program) chimes in.

Fifth - Some of your action items make absolutely no sense for a 
well-established CA:


   - 
   
   Expand use of linters post-issuance for all certificate types
   - 
   
   Expand use of linters pre-issuance for all certificate types
   - 
   
   Implement process during incident review to stop issuing certificates 
   when a mis-issuance event has been confirmed
   

Are you claiming you didn't have the linting in place already? Did we learn 
nothing from all these previous incidents:

   - 
   
   https://bugzilla.mozilla.org/show_bug.cgi?id=1635096#c14
   - 
   
   https://bugzilla.mozilla.org/show_bug.cgi?id=1667448#c7
   - 
   
   https://bugzilla.mozilla.org/show_bug.cgi?id=1648472#c9
   - 
   
   https://bugzilla.mozilla.org/show_bug.cgi?id=1448986#c7
   

You've had issues with, arguably one of the easiest parts of being a CA, 
linting. Your issues with linting go back at least six years. Seriously, 
how do you have so much difficulty with properly implementing pre, and post 
issuance linting? 


Linting has been standard operating process at Entrust since March 2018 for 
post-linting and May 2019 for pre-linting. We use zlint, and it was in use 
for pre and post linting during this incident. We plan to expand our 
linting capability by adding pkilint. With the next platform release (July 
30, 2024), we will have linting coverage from both tools pre and post 
issuance."   


Beyond that, "Implement process during incident review to stop issuing 
certificates when a mis-issuance event has been confirmed"

At Let's Encrypt, and Google Trust Services we used the wording of 
"suspected". As a CA Engineer, I was empowered to stop issuance at any time 
if I suspected mis-issuance was happening. I've used that power both 
correctly, and incorrectly in the past in those CAs and it wasn't a big 
deal. Why are you waiting until a mis-issuance event has been confirmed? 
Which seems to take at least 24 hours at Entrust.

Beyond the language used there being problematic, I'm extremely shock

Re: Recent Entrust Compliance Incidents

['Bruce Morton' via dev-security-policy@mozilla.org]

On Sunday, June 23, 2024 at 3:39:35 PM UTC-4 Zacharias Björngren wrote:

Missing the point
> As a global CA we must walk a tightrope in balancing the requirements of 
the root programs and subscriber needs, especially for critical 
infrastructure.

This is a very worrying sentence. It seems that both Entrust and many of 
their subscribers (even more worryingly subscribers responsible for 
critical infrastructure) completely misunderstand what the purpose of the 
requirements of the root programs are. These rules, requirements, 
guidelines, policies, &c are here to keep us safe. And I don't mean us as 
in relying parties, I mean us as in everyone. That there is a need to 
balance these requirements against the needs of Entrust subscribers makes 
me worry about what those subscribers are doing. Why are so many 
organizations running critical infrastructure not prioritizing following 
safety regulation?


We serve many of the world’s largest banks, governments, and enterprises 
and are confident that they do prioritize safety and compliance 
requirements from a wide variety of regulatory bodies. We are working with 
them to ensure they are clear on WebPKI compliance requirements moving 
forward.  If there are use cases in which a privately-rooted environment 
would be more suitable, we will have those discussions. 

Refusal to learn, bug 1890898

It's important to seize the opportunity to learn from your incidents. Why 
is Entrust so stubbornly clinging to their analysis in #1890898 that the 
certificates weren't miss-issued? 


 That is not the case. Please see 
https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c61 where this has 
been addressed. 

I don't understand this explanation, are senior leadership the ones making 
the decision to delay revocation or not revoke? 


 With the process changes described in our updated response, these 
decisions are now made through a cross-functional compliance review process 
with senior leadership. This will provide more proactive oversight.   

But those decisions are communicated to the community via Bugzilla, and is 
that not done through the business unit employees that have knowledge of 
the 2020 commitments? It's the same person posting: "We will not the make 
the decision not to revoke." in 1651481, that this year posted: "we decided 
to not revoke due to exceptional conditions listed in this report." in 
1890898. 


 Yes, the business unit employees who made the posts knew of our 2020 
commitments. They have been moved into our corporate compliance 
organization for increased communication and governance. 


-- 
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/af8ebd8d-a379-4244-bb64-fc3d3696e0e6n%40mozilla.org.

Re: Recent Entrust Compliance Incidents

[Wayne]

 Further to the latest report making no mention of that incident, in 
#1890898 there is a statement of intent of there being a second amended 
final report:
https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c66
> Yes, we will amend the final incident report to reflect that we did our 
analysis 

Is there any intent on there being a final report or is this cycle going to 
continue? If a judgment on Entrust's ability to make concrete statements 
will be made, there needs to be a final statement at some point.

And in regards to your response my statement let us not turn this into an 
ongoing back-and-forth with individuals. I will only address the last 
question whereby Entrust will not share how their new team will show any 
divergence from previous mistakes. The point of asking for an analysis of 
the 'new team' versus what happened historically is to provide any trust 
that the same mistakes will not be repeated but with a new badge in place. 
The lack of confidence in being able to provide that is distressing at this 
stage.

- Wayne

On Tuesday, June 25, 2024 at 10:01:47 PM UTC+1 Bruce Morton wrote:

> On Friday, June 21, 2024 at 5:17:30 PM UTC-4 Wayne wrote:
>
> >>Note: During our investigation of this issue, we noted that a subset of 
> 1,975 EV certificates were also issued without the Entrust EV policy 
> identifier (OID), based on our interpretation of the ballot update.
> >This is also a miscount, presumably due to the original figure being 1963 
> + 6 certs on a test site that are being double-counted.
>
> On reading further in 2.1.1 Entrust have outright stated they still stand 
> by their incorrect analysis as previously noted in this reply. This speaks 
> volumes as to the decisions that will occur going forward. Within 2.1.3 
> there is a mention of Entrust continuing to issue certificates and advocate 
> their position, but I am seeing no reflection as to the root cause of what 
> causes them to advocate for their incorrect positions to this day. Not a 
> single line of 2.1.4 addresses this either.
>
> We have clarified our position on this bug 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c61.
>  
>
> Regarding ACME, I previously stated this question and will repeat it now: 
> Can you make any guarantees that ACME will be a requirement for subscribers 
> going forward, and that they will not be charged extra for using these 
> systems?
>
>
>  We are offering ACME free of charge now and are adding support for ARI. 
> We will increase efforts to educate and promote adoption, but we cannot 
> guarantee it as not all subscriber environments support ACME.   
>
>
> Looking into 4.3 Appendix 3: Success Measures I won't address each 
> individually. I am curious how you intend to get the WebTrust annual audit 
> results to result in 0 qualifications in the space of a year. I would 
> suggest an element for Communication is added to address how often a 
> question has to be restated or followed up on due to a lack of clarity and 
> transparency. Otherwise the list presents a minimal standard for any 
> complying CA, if this is not kept by any CA it would be further cause for 
> concern.
>
>
> Entrust will have qualifications which have already been reported in our 
> current incident reports. These qualifications are being addressed and will 
> be closed in this audit period. Our goal moving forward is to have 0 new 
> qualifications in our current audit period.
>
> Once again in evaluating against what was requested I am struck at how the 
> systemic failures are not being addressed. We have commitments to 
> committees and boards, but the decisions are what truly matter. There is no 
> mention of what policies caused these initial issues and how they were not 
> adhered to. The 2020 commitments are only highlighted due to every comment 
> noting it specifically, no attempt seems to exist to evaluate against 
> historical issues.
>
> On the 2020 commitments I am deeply troubled about this statement in 
> particular:
> "Knowledge of 2020 commitments was similarly confined to a small number of 
> business unit employees, without broader leadership team/organizational 
> awareness."
> This should have came up in audits which cover incidents on bugzilla. What 
> happened? Did the auditor only address this with the same small number of 
> business unit employees and somehow no note of these commitments made it 
> into any report that went further up the chain? What confidence can we have 
> in any bugzilla-specific commitments outside of this report going forward?
>
>
> Yes, that is correct. The issues were addressed with a small number of 
> business unit employees. We have made significant changes (as described in 
> our response) to ensure that Bugzilla commitments are tracked and met 
> moving forward through our corporate compliance governance process. It's a 
> process we use effectively today for other Entrust business units. 
>  
>
> As a final note I will highlight this section:
> 

Re: Recent Entrust Compliance Incidents

['Bruce Morton' via dev-security-policy@mozilla.org]

On Friday, June 21, 2024 at 5:17:30 PM UTC-4 Wayne wrote:

>>Note: During our investigation of this issue, we noted that a subset of 
1,975 EV certificates were also issued without the Entrust EV policy 
identifier (OID), based on our interpretation of the ballot update.
>This is also a miscount, presumably due to the original figure being 1963 
+ 6 certs on a test site that are being double-counted.

On reading further in 2.1.1 Entrust have outright stated they still stand 
by their incorrect analysis as previously noted in this reply. This speaks 
volumes as to the decisions that will occur going forward. Within 2.1.3 
there is a mention of Entrust continuing to issue certificates and advocate 
their position, but I am seeing no reflection as to the root cause of what 
causes them to advocate for their incorrect positions to this day. Not a 
single line of 2.1.4 addresses this either.

We have clarified our position on this bug 
https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c61.
 

Regarding ACME, I previously stated this question and will repeat it now: 
Can you make any guarantees that ACME will be a requirement for subscribers 
going forward, and that they will not be charged extra for using these 
systems?


 We are offering ACME free of charge now and are adding support for ARI. We 
will increase efforts to educate and promote adoption, but we cannot 
guarantee it as not all subscriber environments support ACME.   


Looking into 4.3 Appendix 3: Success Measures I won't address each 
individually. I am curious how you intend to get the WebTrust annual audit 
results to result in 0 qualifications in the space of a year. I would 
suggest an element for Communication is added to address how often a 
question has to be restated or followed up on due to a lack of clarity and 
transparency. Otherwise the list presents a minimal standard for any 
complying CA, if this is not kept by any CA it would be further cause for 
concern.


Entrust will have qualifications which have already been reported in our 
current incident reports. These qualifications are being addressed and will 
be closed in this audit period. Our goal moving forward is to have 0 new 
qualifications in our current audit period.

Once again in evaluating against what was requested I am struck at how the 
systemic failures are not being addressed. We have commitments to 
committees and boards, but the decisions are what truly matter. There is no 
mention of what policies caused these initial issues and how they were not 
adhered to. The 2020 commitments are only highlighted due to every comment 
noting it specifically, no attempt seems to exist to evaluate against 
historical issues.

On the 2020 commitments I am deeply troubled about this statement in 
particular:
"Knowledge of 2020 commitments was similarly confined to a small number of 
business unit employees, without broader leadership team/organizational 
awareness."
This should have came up in audits which cover incidents on bugzilla. What 
happened? Did the auditor only address this with the same small number of 
business unit employees and somehow no note of these commitments made it 
into any report that went further up the chain? What confidence can we have 
in any bugzilla-specific commitments outside of this report going forward?


Yes, that is correct. The issues were addressed with a small number of 
business unit employees. We have made significant changes (as described in 
our response) to ensure that Bugzilla commitments are tracked and met 
moving forward through our corporate compliance governance process. It's a 
process we use effectively today for other Entrust business units. 
 

As a final note I will highlight this section:
"As part of our response process to the Mozilla community, Entrust assigned 
a group of three senior leaders, as well as an external consultant, to 
review each incident to validate and expand root cause analysis."

Can we please have a breakdown on Entrust's end of what their original 
opinion was at the start of each incident, and how these personnel would 
evaluate the situation if it were to happen today? I sincerely hope that 
#1890898 is not an example going forward.


Each of these issues had a different set of circumstances, but the common 
element was that they all were decided by a small number of business unit 
employees without broader cross-functional review and alignment on 
requirements and the process for decision making. Moving forward, we will 
initiate our incident response process (outlined in our response), to 
ensure swift action consistent with CA/B requirements.  


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

Re: Recent Entrust Compliance Incidents

['Amir Omidi (aaomidi)' via dev-security-policy@mozilla.org]

> As outlined in our report, in the event of a future issue, we will follow 
our incident response process to ensure swift cross-functional review, 
decision making and action consistent with CA/B requirements.  

Your report makes no mention of that incident. 

On Tuesday, June 25, 2024 at 4:55:01 PM UTC-4 Bruce Morton wrote:

> On Friday, June 21, 2024 at 3:31:07 PM UTC-4 Amir Omidi (aaomidi) wrote:
>
> Quick preliminary question:
>
> Is this now the final report? The final report that was due two weeks ago.
>
>
> This is an update to the final report we issued on June 7. The updates are 
> based on comments and questions from this community over the past two 
> weeks. 
>  
>
> Can you explain how this document is going to reconcile the recent 
> response we got from Entrust over this bug? 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1890685#c46
>
>
> As outlined in our report, in the event of a future issue, we will follow 
> our incident response process to ensure swift cross-functional review, 
> decision making and action consistent with CA/B requirements.  
>  
>

-- 
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/6d2d9059-2652-412f-b4f5-d64eecd4f61dn%40mozilla.org.

Re: Recent Entrust Compliance Incidents

['Bruce Morton' via dev-security-policy@mozilla.org]

On Friday, June 21, 2024 at 3:31:07 PM UTC-4 Amir Omidi (aaomidi) wrote:

Quick preliminary question:

Is this now the final report? The final report that was due two weeks ago.


This is an update to the final report we issued on June 7. The updates are 
based on comments and questions from this community over the past two 
weeks. 
 

Can you explain how this document is going to reconcile the recent response 
we got from Entrust over this bug? 
https://bugzilla.mozilla.org/show_bug.cgi?id=1890685#c46


As outlined in our report, in the event of a future issue, we will follow 
our incident response process to ensure swift cross-functional review, 
decision making and action consistent with CA/B requirements.  
 

-- 
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/189a1f42-0a42-4690-b60f-6b93b1de9071n%40mozilla.org.

Re: Recent Entrust Compliance Incidents

[Suchan Seo]

while tethically out of scope for this thread, is there reason for browsers 
to include offendgind certificates into CRLlite/CRLset without waiting for 
CA to agree about that?

2024년 6월 25일 화요일 오전 7시 7분 30초 UTC+9에 Watson Ladd님이 작성:

> So I've finally gotten around to reading it. I was a little confused
> by the lack of real introduction but it is much more detailed.
>
> However, you're still missing one of the 2020 bugs, namely
> https://bugzilla.mozilla.org/show_bug.cgi?id=1658792. And when I look
> at that against https://bugzilla.mozilla.org/show_bug.cgi?id=1897630 I
> see the answer to what confused me about the organization of the bugs:
> Entrust is overly reliant on humans doing things. It's been organized
> in a way where a single human can err and create a missiuance by not
> seeing an email, or filling out a form in a natural way. It's a
> systemic weakness that this second report only sort of covered, and
> never really dug into. The answer to the geography issues wasn't
> automated checking: it was changing the UI, enabling a different kind
> of error to still happen.
>
> Some CAs would have used additional automation as a solution:
> validating geographical information against available lists (as
> promised in that bug). Those CAs would likely also have implemented
> monitoring themselves of their OCSP responders, mapped from the CAB
> forum requirements. Culturally they would have been more oriented to
> creating tickets on emails and using the ticket tracking system to
> help ensure that response times were being met and reported on.
>
> Sincerely,
> Watson Ladd
>
>
>
> On Fri, Jun 21, 2024 at 11:59 AM 'Bruce Morton' via
> dev-secur...@mozilla.org 
> wrote:
> >
> > Attached is a letter from Bhagwat Swaroop, President of Entrust Digital 
> Security Solutions, along with an updated response to address questions 
> from the community.
> >
> > Thanks, Bruce.
> >
> > On Tuesday, June 18, 2024 at 1:35:48 PM UTC-4 Amir Omidi (aaomidi) wrote:
> >>
> >> I am not going to say with certainty that Entrust is definitely putting 
> Chrome over Mozilla. However, I hope they know that most Linux systems out 
> there use the Mozilla root store directly.
> >> On Tuesday, June 18, 2024 at 1:12:19 PM UTC-4 Mike Shaver wrote:
> >>>
> >>> On Tue, Jun 18, 2024 at 12:49 PM Walt  wrote:
> 
>  I'd just like to point out that we now have a situation where Entrust 
> is in the position of seemingly valuing the opinion of other Root Programs 
> over Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c42
> 
>  In Comment #37, it was hinted at (and made slightly more explicit in 
> #39) that the opinion of the Mozilla RP is that the attempt to 
> re-characterize these certs was not going to be looked kindly upon, and 
> only once a Google RP member explicitly said that it was the Google RP 
> opinion that the certs remained mis-issued was any movement made on 
> re-confirming the mis-issuance and taking action to revoke them.
> 
>  Also, if we're in a position where Entrust is finally able to commit 
> to revoking certs within a 5 day period (setting aside that these certs 
> technically need a delayed revocation bug as the mis-issuance was known as 
> far back as 2024-04-10), why are other incidents not able to be resolved in 
> this amount of time? Is it because Google showed up?
> >>>
> >>>
> >>> We’ve seen this behaviour in other incidents as well, I believe 
> including the cpsURI one that has turned into a magnet for evidence of poor 
> operation and lack of transparency and responsiveness. I remarked on it in 
> my initial snarky reply to the Entrust Report, in fact.
> >>>
> >>> From a realpolitik perspective their behaviour could indeed be 
> rational, especially when the only tool root programs have is distrust. 
> Firefox would suffer substantial market disadvantage if it stopped trusting 
> Entrust certificates when other browsers didn’t. I think people generally 
> underestimate how much Mozilla would be willing to take near-term pain to 
> protect users, but it’s also possible that I am overestimating it.
> >>>
> >>> Related to that, I think Chrome’s root program representatives have 
> generally been more willing to take a concrete position quickly, so Mozilla 
> might be waiting for more explanation when Chrome decides that there’s no 
> explanation that could suffice, or similar. The root programs tend to be in 
> agreement more often than not (virtually always with Chrome and Mozilla, I 
> would say, excepting some slightly different root store populations), so it 
> may be somewhat irrelevant whose opinion spurs motion.
> >>>
> >>> Realpolitik analysis aside, I do agree that Entrust has created the 
> impression that they care much more about Chrome’s opinion than Mozilla’s, 
> which IMO might not be the best posture to take given that Mozilla and its 
> community are the locus for the processing and evaluation of the incidents 
> in question.
> >>>
> >>> Mike
> >>>
> >

Re: Recent Entrust Compliance Incidents

[Watson Ladd]

So I've finally gotten around to reading it. I was a little confused
by the lack of real introduction but it is much more detailed.

However, you're still missing one of the 2020 bugs, namely
https://bugzilla.mozilla.org/show_bug.cgi?id=1658792. And when I look
at that against https://bugzilla.mozilla.org/show_bug.cgi?id=1897630 I
see the answer to what confused me about the organization of the bugs:
Entrust is overly reliant on humans doing things. It's been organized
in a way where a single human can err and create a missiuance by not
seeing an email, or filling out a form in a natural way. It's a
systemic weakness that this second report only sort of covered, and
never really dug into. The answer to the geography issues wasn't
automated checking: it was changing the UI, enabling a different kind
of error to still happen.

Some CAs would have used additional automation as a solution:
validating geographical information against available lists (as
promised in that bug). Those CAs would likely also have implemented
monitoring themselves of their OCSP responders, mapped from the CAB
forum requirements. Culturally they would have been more oriented to
creating tickets on emails and using the ticket tracking system to
help ensure that response times were being met and reported on.

Sincerely,
Watson Ladd



On Fri, Jun 21, 2024 at 11:59 AM 'Bruce Morton' via
dev-security-policy@mozilla.org 
wrote:
>
> Attached is a letter from Bhagwat Swaroop, President of Entrust Digital 
> Security Solutions, along with an updated response to address questions from 
> the community.
>
> Thanks, Bruce.
>
> On Tuesday, June 18, 2024 at 1:35:48 PM UTC-4 Amir Omidi (aaomidi) wrote:
>>
>> I am not going to say with certainty that Entrust is definitely putting 
>> Chrome over Mozilla. However, I hope they know that most Linux systems out 
>> there use the Mozilla root store directly.
>> On Tuesday, June 18, 2024 at 1:12:19 PM UTC-4 Mike Shaver wrote:
>>>
>>> On Tue, Jun 18, 2024 at 12:49 PM Walt  wrote:

 I'd just like to point out that we now have a situation where Entrust is 
 in the position of seemingly valuing the opinion of other Root Programs 
 over Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c42

 In Comment #37, it was hinted at (and made slightly more explicit in #39) 
 that the opinion of the Mozilla RP is that the attempt to re-characterize 
 these certs was not going to be looked kindly upon, and only once a Google 
 RP member explicitly said that it was the Google RP opinion that the certs 
 remained mis-issued was any movement made on re-confirming the 
 mis-issuance and taking action to revoke them.

 Also, if we're in a position where Entrust is finally able to commit to 
 revoking certs within a 5 day period (setting aside that these certs 
 technically need a delayed revocation bug as the mis-issuance was known as 
 far back as 2024-04-10), why are other incidents not able to be resolved 
 in this amount of time? Is it because Google showed up?
>>>
>>>
>>> We’ve seen this behaviour in other incidents as well, I believe including 
>>> the cpsURI one that has turned into a magnet for evidence of poor operation 
>>> and lack of transparency and responsiveness. I remarked on it in my initial 
>>> snarky reply to the Entrust Report, in fact.
>>>
>>> From a realpolitik perspective their behaviour could indeed be rational, 
>>> especially when the only tool root programs have is distrust. Firefox would 
>>> suffer substantial market disadvantage if it stopped trusting Entrust 
>>> certificates when other browsers didn’t. I think people generally 
>>> underestimate how much Mozilla would be willing to take near-term pain to 
>>> protect users, but it’s also possible that I am overestimating it.
>>>
>>> Related to that, I think Chrome’s root program representatives have 
>>> generally been more willing to take a concrete position quickly, so Mozilla 
>>> might be waiting for more explanation when Chrome decides that there’s no 
>>> explanation that could suffice, or similar. The root programs tend to be in 
>>> agreement more often than not (virtually always with Chrome and Mozilla, I 
>>> would say, excepting some slightly different root store populations), so it 
>>> may be somewhat irrelevant whose opinion spurs motion.
>>>
>>> Realpolitik analysis aside, I do agree that Entrust has created the 
>>> impression that they care much more about Chrome’s opinion than Mozilla’s, 
>>> which IMO might not be the best posture to take given that Mozilla and its 
>>> community are the locus for the processing and evaluation of the incidents 
>>> in question.
>>>
>>> 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 vi

Re: Recent Entrust Compliance Incidents

[Walt]

Some final thoughts on this after re-reading the updated report: 

*First*, a deliverable due date is a deliverable due date. If I was asked 
to answer 7 questions by my management team by a given deliverable date, 
and provided a report that barely answered two of them, I'd be thinking 
long and hard about what got me to that point (and the future of my 
continued employment), and why an updated report took an additional two 
weeks to create. I would argue that Entrust should be judged based on the 
initial report primarily, as the due date was very clear, as well as the 
guidelines for assembling the report. The second report *should* have been 
what we saw the first time, but this theme of "Entrust doing closer to the 
right thing late" seems to be a recurring trend with this series of events. 
This even goes as far back as 2020, when there was allegedly a promise that 
this wouldn't happen again (or at least not at the scale it did in 2020) 
and yet here we are. 

*Two*, as Amir noted, there's numerous inconsistencies with the report(s) 
compared to incidents. 

This issue has been prioritized at the highest levels within Entrust. We 
have hundreds of people across Entrust working on remediation—including our 
senior leadership as well as teams from Customer Support, Operations, 
Sales, Legal, Compliance, and Product Management, and we have been working 
hand in hand with executives at Global 2000 companies who are impacted. Our 
colleagues are working around the clock to support our customers, meet CA/B 
Forum expectations, and expedite revocation and re-issuance of affected

followed by saying [paraphrased]: "The work we were doing previously wasn't 
good enough so we tossed it all out". Is the goal in this updated response 
simply to make it seem like enough changes have been made to kick the can 
down the road again for a few more years until Entrust makes some 
relatively simple mistake that could have been caught by linting and then 
we end up in this same boat again? 

*Third*, I'll reiterate the fact that Entrust seemingly doesn't take the 
opinion of Mozilla RP and the associated community seriously. The incident 
(#1883843)  that 
started this *all*, was only taken seriously (12 days after posting) when 
the original reporter (who happened to be with Google RP) came in and said 
that the response did not meet Google RP's standards. Only *then* did 
mis-issuance stop. 

*Fourth*, I'll re-iterate as well that pre and post issuance linting feels 
like a pretty table stakes feature to prevent giving customers certificates 
that are mis-issued, avoiding the awkward conversations you seem to 
continually be having with your subscribers. Instead you knowingly issue 
certificates that might be mis-issued to subscribers, don't pause issuance, 
and wind up digging a bigger hole which could have been avoided if Entrust 
team members were empowered to pull the circuit breaker at any time.

*Fifth*, there's very little in this report that's measurable in terms of 
improvement. It digs deeper into what happened sure, but most of these 
metrics require trust in Entrust to be sharing these metrics correctly to 
evaluate their compliance with the report. To put it bluntly, I trust 
Entrust about as much as I could throw Entrust, which is not very far. 
Given that, I see no reason to trust these metrics given by Entrust, and as 
such I see no objective way of measuring these commitments.

In conclusion, I would second Amir's suggestion that Entrust be distrusted, 
and re-apply for inclusion once the organizational deficiencies have been 
resolved.

Walter


On Monday, June 24, 2024 at 9:43:52 AM UTC-7 Amir Omidi (aaomidi) wrote:

> Let's take a step back from this report. I don't think this report 
> deserves to be taken seriously for one reason alone: You've historically 
> proven to the community that we should not trust any statements made by 
> Entrust. Let's look at how you've proven this:
>
> First - Four years ago, you made a couple of promises in comment 6 of 
> 1651481 :
>
>
>
>
>- 
>
>We will not the make the decision not to revoke.
>
>
>- 
>
>We will plan to revoke within the 24 hours or 5 days as applicable for 
>the incident.
>
> None of these promises have been realized in the past four years. Why is 
> this time going to be different? How are we even supposed to measure your 
> commitment to your current action items?
>
> Second - In this report, you're claiming that a lot of these issues stem 
> from organizational structure. Meanwhile, 3 months ago, Entrust was 
> claiming that: 
>
> This issue has been prioritized at the highest levels within Entrust. We 
> have hundreds of people across Entrust working on remediation—including our 
> senior leadership as well as teams from Customer Suppo

Re: Recent Entrust Compliance Incidents

['Amir Omidi (aaomidi)' via dev-security-policy@mozilla.org]

Let's take a step back from this report. I don't think this report deserves 
to be taken seriously for one reason alone: You've historically proven to 
the community that we should not trust any statements made by Entrust. 
Let's look at how you've proven this:

First - Four years ago, you made a couple of promises in comment 6 of 
1651481 :


   - 
   
   We will not the make the decision not to revoke.
   - 
   
   We will plan to revoke within the 24 hours or 5 days as applicable for 
   the incident.
   
None of these promises have been realized in the past four years. Why is 
this time going to be different? How are we even supposed to measure your 
commitment to your current action items?

Second - In this report, you're claiming that a lot of these issues stem 
from organizational structure. Meanwhile, 3 months ago, Entrust was 
claiming that: 

This issue has been prioritized at the highest levels within Entrust. We 
have hundreds of people across Entrust working on remediation—including our 
senior leadership as well as teams from Customer Support, Operations, 
Sales, Legal, Compliance, and Product Management, and we have been working 
hand in hand with executives at Global 2000 companies who are impacted. Our 
colleagues are working around the clock to support our customers, meet CA/B 
Forum expectations, and expedite revocation and re-issuance of affected

So putting these two together, what Entrust seems to be doing is pressing 
shuffle on the same playlist that's led to all of this.

Third - As you were sending out this Entrust Report 
Final-ForRealThisTime.pdf, we had Entrust continue to make nonsensical 
arguments . Even 
after it was pointed out by both Chrome 
, and Mozilla 
, that what 
you're doing is not okay.

To be very clear here, this comment by Entrust was made on 2024-06-19 while 
we received this new report from Entrust on 2024-06-21. Entrust has not 
even bothered covering this incident in this report.

Fourth - As evidenced in your recent incident responses, you don't really 
care about 1) what the community says 2) what Mozilla says. Time and time 
again, I've only seen Entrust change their tune on matters when Ryan 
Dickson (Specifically, Chrome Root Program) chimes in.

Fifth - Some of your action items make absolutely no sense for a 
well-established CA:


   - 
   
   Expand use of linters post-issuance for all certificate types
   - 
   
   Expand use of linters pre-issuance for all certificate types
   - 
   
   Implement process during incident review to stop issuing certificates 
   when a mis-issuance event has been confirmed
   

Are you claiming you didn't have the linting in place already? Did we learn 
nothing from all these previous incidents:

   - 
   
   https://bugzilla.mozilla.org/show_bug.cgi?id=1635096#c14
   - 
   
   https://bugzilla.mozilla.org/show_bug.cgi?id=1667448#c7
   - 
   
   https://bugzilla.mozilla.org/show_bug.cgi?id=1648472#c9
   - 
   
   https://bugzilla.mozilla.org/show_bug.cgi?id=1448986#c7
   

You've had issues with, arguably one of the easiest parts of being a CA, 
linting. Your issues with linting go back at least six years. Seriously, 
how do you have so much difficulty with properly implementing pre, and post 
issuance linting? 

Beyond that, "Implement process during incident review to stop issuing 
certificates when a mis-issuance event has been confirmed"

At Let's Encrypt, and Google Trust Services we used the wording of 
"suspected". As a CA Engineer, I was empowered to stop issuance at any time 
if I suspected mis-issuance was happening. I've used that power both 
correctly, and incorrectly in the past in those CAs and it wasn't a big 
deal. Why are you waiting until a mis-issuance event has been confirmed? 
Which seems to take at least 24 hours at Entrust.

Beyond the language used there being problematic, I'm extremely shocked 
that this isn't done yet? This was one of the main problems in Entrust's 
response to the cpsUri incident 
. How has it taken 
you nearly five months to address this?

Sixth - Is this report now happening under the new leadership of compliance? 
How about the report prior to this? The tone of these two reports are so 
significantly different that it seems like something changed between these 
two. What changed between these two incident reports that caused such a 
significant change in the tone of the report? 

Moving beyond the tone of these reports - does the new leadership of 
compliance see the substance of this current report as a satisfactory 
response to how much Entrust has dropped the ball recently?

In conclusion - there were so many things you could've

Re: Recent Entrust Compliance Incidents

[Zacharias Björngren]

Missing the point
> As a global CA we must walk a tightrope in balancing the requirements of 
the root programs and subscriber needs, especially for critical 
infrastructure.

This is a very worrying sentence. It seems that both Entrust and many of 
their subscribers (even more worryingly subscribers responsible for 
critical infrastructure) completely misunderstand what the purpose of the 
requirements of the root programs are. These rules, requirements, 
guidelines, policies, &c are here to keep us safe. And I don't mean us as 
in relying parties, I mean us as in everyone. That there is a need to 
balance these requirements against the needs of Entrust subscribers makes 
me worry about what those subscribers are doing. Why are so many 
organizations running critical infrastructure not prioritizing following 
safety regulation? 

> Many of our customers represent critical infrastructure due to their 
roles in the financial system, government, transportation, and other 
industries and there are real challenges in meeting the guidelines. We 
recognize that it is not the responsibility of our subscribers to resolve 
these conflicts. It is our responsibility as part of our commitment to 
meeting the CA/Browser Forum requirements and protecting the WebPKI. 

It's a CAs responsibility to revoke certificates when required. When this 
cannot be done without causing significant harm because of subscribers lack 
of capability to handle such a revocation event, then ensuring that a 
future revocation event can be handled without causing significant harm is 
a shared responsibility between the CA and their subscribers. In Mozilla's 
Responding to an Incident the final listed point of expectations in the 
case of delayed revocation states:

> * You will perform an analysis to determine the factors that prevented 
timely revocation of the certificates, and include a set of remediation 
actions in the final incident report that aim to prevent future revocation 
delays.

If the causes that prevents a timely revocation while avoiding significant 
harm are internal to the subscribers, then remediation actions must involve 
them those subscribers. I understand that many of Entrust customers are 
enormous corporations that can need time to implement the necessary 
changes. But once a CA becomes aware that one of their subscribers aren't 
capable handling revocation as required by the BRs, then future issuance of 
certificates to that subscribers must be predicated on that subscriber 
making commitments to be able to handle timely revocation. Obviously we 
don't want to risk harm in a future revocation event, but without requiring 
the subscriber to make these commitments you are in fact making it your 
policy to not apply the BR revocation deadlines for that subscriber.

In Comment#82 on bug 1886532 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1886532#c82) Bruce Morton 
writes:

> Although it has been difficult, we now understand that the community 
places priority on strict adherence to the rules, and views revocation as a 
tool to influence subscribers into modifying how they use TLS certificates, 
and is willing to accept much more harm to subscribers and users of the 
internet than Entrust believed was acceptable.

I want to clarify that for me, this isn't golf. I want these stewards of 
critical infrastructure to adhere to the rules because if they don't I 
believe that we risk much greater harm in the future. If a subscriber 
genuinely requires weeks and months reissue their certificates without 
causing significant harm, then I agree that a delay in revocation would be 
prudent. But it is simply unacceptable that for organization controlling 
such critical infrastructure to be so extremely incapable for technological 
or organizational reasons. The statement "and views revocation as a tool to 
influence subscribers into modifying how they use TLS certificates" implies 
that Entrust did not believe that revocation should be used to influence 
how webPKI certificates should be used, but is that not what revocation is? 
If a subscriber is not using a certificate according to the BRs or TLS 
Guidelines it must be revoked, the threat of revocation is literally a tool 
to influence behavior of subscribers.

What I believe that the community is trying to communicate is that we are 
trying to avoid future harm from happening. Assurances from Entrust about 
how they **would** be able to revoke within 24h, I assume without causing 
significant harm, for a security issue ring very hollow when Entrust is 
demonstrably incapable of revocation within weeks or months when the 
problem is "only mississuance". But if we assume that we can trust that 
Entrust and their subscribers can handle a mass revocation event within 24h 
in case of a security breach that still leaves us with this:

> In our conversations with Subscribers, we transparently disclosed that 
there was no security risk to relying parties if the affected certificates

Re: Recent Entrust Compliance Incidents

[Ryan Hurst]

Part of me wants to commend Entrust for this response. If we can believe 
its sincerity—and this is a if given their recent history and how this has 
played out—it took 13 compliance incidents and 107 days for their 
leadership to recognize, at least publicly, the systemic issues that have 
happened under their watch, and that does not even count the fact that this 
has been a problem since at least 2020.


The disappointing thing is that here we are, 30% into the year, and what we 
have is a commitment to restructure a part of Entrust and fund it to do 
better without concrete actions to address the specific issues. Meanwhile, 
they are still trusted and exposing the internet to their continued 
management challenges. I can’t help but think this response is too little, 
too late. With that said, it does indicate some level of recognition of how 
bad things have gotten, which is a step in the right direction.

With all that said, it’s difficult to imagine ISRG or Sectigo, for example, 
showing the same level of disregard for the processes at play or taking 
this long to get to this point. While this organizational change might help 
address that, at the same time as of three days ago, it appears that 
Entrust was still suggesting that EV certs issued in violation of their CPS 
weren’t actually misissued. This raises questions about whether they have 
truly internalized the gravity of the situation or if this public gesture 
is just that—a gesture.

Beyond that, the thing that I can’t help but ask myself is how long is too 
long. I’ve not yet gone back and looked at the average response time for 
other incidents, but just from looking at this thread and the associated 
bugs since March 6th, there are still missing responses/updates that were 
promised, and those that were provided were shallow. In my experience as an 
engineering leader, my first priority in a situation like this would be to 
ensure that we never missed a promised or obligated response, the second 
would be to make sure we had done everything possible to address the 
identified issues immediately. It’s unfortunate that at this point, we are 
not even there yet. Entrust has had every opportunity to do the right 
thing, but even with the world watching, they didn’t seem to prioritize it. 
As a result, today’s response might be better categorized as performative.

Ryan Hurst


On Friday, June 21, 2024 at 2:17:30 PM UTC-7 Wayne wrote:

> This has been written without checking prior replies - there may be 
> overlap.
>
> First off, good work on the new report addressing more matters however 
> this should have been your original report at a minimum. Before I even 
> start I will outright state that I hope that Entrust actually improves 
> throughout this and while this comment will be cleaned up it reflects an 
> ongoing opinion as the report is read.
>
> First looking at the letter I will only note this paragraph:
> "We are disappointed as this does not represent Entrust values and falls 
> short of the standards we set for ourselves. We also want to make sure it 
> is understood that none of these lapses have been malicious or done with 
> ill-intent to make the internet less secure. As a global CA we must walk a 
> tightrope in balancing the requirements of the root programs and subscriber 
> needs, especially for critical infrastructure. In some cases, we did not 
> strike the right balance."
>
> It does trouble me that compliance is seen as a balancing point against 
> issuance for critical infrastructure. There has been a common talking point 
> of Entrust's delayed revocation incidents of the concept of irresponsible 
> revocation. I point it to Entrust that such a scenario only presents itself 
> when a CA is culpable of irresponsible issuance.
>
> As I read through this I keep seeing a repeating pattern of changing the 
> organizational structure and creating committees and board of 
> cross-discipline personnel. While this is all good in theory, I am 
> concerned that this is not addressing the actual root causes of internal 
> decision making and that the outputs will be just the same with a different 
> label on the team providing it.
>
> Before I delve into any minutiae of the report itself I do find it 
> noteworthy that in incident #1890898 (Entrust: Failure to revoke OV TLS - 
> CPS typographical (text placement) error)) 
>  we have a 
> functional example of the new cross-functional team evaluating compliance 
> and coming to a decision. Now this could be a third unspecified team but 
> given the report I presume this is the template going forward, for brevity 
> I'll keep this to the broad strokes:
>
> 2024-04-11: Issue opens, mis-issuance confirmed but no intent to revoke. A 
> long conversation ensues, nothing changes until a day before the June 7th 
> report appears.
>
> 2024-06-06 : 
> "We reviewed and consulted

Re: Recent Entrust Compliance Incidents

[Wayne]

This has been written without checking prior replies - there may be overlap.

First off, good work on the new report addressing more matters however this 
should have been your original report at a minimum. Before I even start I 
will outright state that I hope that Entrust actually improves throughout 
this and while this comment will be cleaned up it reflects an ongoing 
opinion as the report is read.

First looking at the letter I will only note this paragraph:
"We are disappointed as this does not represent Entrust values and falls 
short of the standards we set for ourselves. We also want to make sure it 
is understood that none of these lapses have been malicious or done with 
ill-intent to make the internet less secure. As a global CA we must walk a 
tightrope in balancing the requirements of the root programs and subscriber 
needs, especially for critical infrastructure. In some cases, we did not 
strike the right balance."

It does trouble me that compliance is seen as a balancing point against 
issuance for critical infrastructure. There has been a common talking point 
of Entrust's delayed revocation incidents of the concept of irresponsible 
revocation. I point it to Entrust that such a scenario only presents itself 
when a CA is culpable of irresponsible issuance.

As I read through this I keep seeing a repeating pattern of changing the 
organizational structure and creating committees and board of 
cross-discipline personnel. While this is all good in theory, I am 
concerned that this is not addressing the actual root causes of internal 
decision making and that the outputs will be just the same with a different 
label on the team providing it.

Before I delve into any minutiae of the report itself I do find it 
noteworthy that in incident #1890898 (Entrust: Failure to revoke OV TLS - 
CPS typographical (text placement) error)) 
 we have a functional 
example of the new cross-functional team evaluating compliance and coming 
to a decision. Now this could be a third unspecified team but given the 
report I presume this is the template going forward, for brevity I'll keep 
this to the broad strokes:

2024-04-11: Issue opens, mis-issuance confirmed but no intent to revoke. A 
long conversation ensues, nothing changes until a day before the June 7th 
report appears.

2024-06-06 : "We 
reviewed and consulted with independent external experts on this revised 
analysis, and based on this broader consultation, we now believe there was 
no mis-issuance and thus no need to revoke the affected certificates. A 
detailed analysis is below."

Following that analysis Mozilla and Chrome's Root Programs give a different 
opinion.

2024-06-18 : "On 
this basis, we will treat this as a mis-issuance, and intend to complete 
revocation by end of day Saturday, June 22."

2024-06-19 : "On 
the last question, our position is that there was no mis-issuance—not that 
there was a mis-issuance and we decided not to revoke which is the 
situation that recommends discussion with affected root stores."

Now, using the 06-06 opinion as a basis we have an example of this new 
cross-functional team. They reviewed the original incident and came to a 
conclusion that a) was not the same as Entrust in April, but crucially b) 
was not compatible with the viewpoints of the Root Programs who spoke up. I 
am of the strong belief of evaluating institutional changes not on their 
stated internal changes, but on their outputs. The decisions are all we 
will see, they are all that will matter in practice.

I will not detail line by line but I do notice that some factual 
discrepancies in the original report have been addressed. It would be good 
to find out how those came to be in the first case. There are still 
outstanding ones that I already stated previously.

>>Note: During our investigation of this issue, we noted that a subset of 
1,975 EV certificates were also issued without the Entrust EV policy 
identifier (OID), based on our interpretation of the ballot update.
>This is also a miscount, presumably due to the original figure being 1963 
+ 6 certs on a test site that are being double-counted.

On reading further in 2.1.1 Entrust have outright stated they still stand 
by their incorrect analysis as previously noted in this reply. This speaks 
volumes as to the decisions that will occur going forward. Within 2.1.3 
there is a mention of Entrust continuing to issue certificates and advocate 
their position, but I am seeing no reflection as to the root cause of what 
causes them to advocate for their incorrect positions to this day. Not a 
single line of 2.1.4 addresses this either.

Oddly 2.2.3 does not mention that on April 3rd "The issue was escalated to 
our verification team for further investigation."

Re: Recent Entrust Compliance Incidents

['Ben Wilson' via dev-security-policy@mozilla.org]

Thanks.
I think the best way to respond is for each person to gather all of their
comments into a single email with a list of remaining issues found and then
submit it to this thread.
Thanks,
Ben

On Fri, Jun 21, 2024 at 1:21 PM Mike Shaver  wrote:

> Thanks, Bruce.
>
> On first quick read of the response, I have some concerns about specific
> elements but the level of detail and specificity is much more appropriate,
> IMO, than with the first response. Thank you for those additions.
>
> What is the best way to provide feedback on this improved response? I
> think there are a few important questions still open.
>
> Mike
>
> On Fri, Jun 21, 2024 at 2:59 PM 'Bruce Morton' via
> dev-security-policy@mozilla.org  wrote:
>
>> Attached is a letter from Bhagwat Swaroop, President of Entrust Digital
>> Security Solutions, along with an updated response to address questions
>> from the community.
>>
>> Thanks, Bruce.
>>
>> On Tuesday, June 18, 2024 at 1:35:48 PM UTC-4 Amir Omidi (aaomidi) wrote:
>>
>>> I am not going to say with certainty that Entrust is definitely putting
>>> Chrome over Mozilla. However, I hope they know that most Linux systems out
>>> there use the Mozilla root store directly.
>>> On Tuesday, June 18, 2024 at 1:12:19 PM UTC-4 Mike Shaver wrote:
>>>
 On Tue, Jun 18, 2024 at 12:49 PM Walt  wrote:

> I'd just like to point out that we now have a situation where Entrust
> is in the position of seemingly valuing the opinion of other Root Programs
> over Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c42
>
> In Comment #37, it was hinted at (and made slightly more explicit in
> #39) that the opinion of the Mozilla RP is that the attempt to
> re-characterize these certs was not going to be looked kindly upon, and
> only once a Google RP member explicitly said that it was the Google RP
> opinion that the certs remained mis-issued was any movement made on
> re-confirming the mis-issuance and taking action to revoke them.
>
> Also, if we're in a position where Entrust is finally able to commit
> to revoking certs within a 5 day period (setting aside that these certs
> technically need a delayed revocation bug as the mis-issuance was known as
> far back as 2024-04-10), why are other incidents not able to be resolved 
> in
> this amount of time? Is it because Google showed up?
>

 We’ve seen this behaviour in other incidents as well, I believe
 including the cpsURI one that has turned into a magnet for evidence of poor
 operation and lack of transparency and responsiveness. I remarked on it in
 my initial snarky reply to the Entrust Report, in fact.

 From a realpolitik perspective their behaviour could indeed be
 rational, especially when the only tool root programs have is distrust.
 Firefox would suffer substantial market disadvantage if it stopped trusting
 Entrust certificates when other browsers didn’t. I think people generally
 underestimate how much Mozilla would be willing to take near-term pain to
 protect users, but it’s also possible that I am overestimating it.

 Related to that, I think Chrome’s root program representatives have
 generally been more willing to take a concrete position quickly, so Mozilla
 might be waiting for more explanation when Chrome decides that there’s no
 explanation that could suffice, or similar. The root programs tend to be in
 agreement more often than not (virtually always with Chrome and Mozilla, I
 would say, excepting some slightly different root store populations), so it
 may be somewhat irrelevant whose opinion spurs motion.

 Realpolitik analysis aside, I do agree that Entrust has created the
 impression that they care much more about Chrome’s opinion than Mozilla’s,
 which IMO might not be the best posture to take given that Mozilla and its
 community are the locus for the processing and evaluation of the incidents
 in question.

 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/f3cebe9b-fa25-4b11-ba3d-b7f3f6e0f719n%40mozilla.org
>> 
>> .
>>
> --
> 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.c

Re: Recent Entrust Compliance Incidents

['Amir Omidi (aaomidi)' via dev-security-policy@mozilla.org]

Quick preliminary question:

Is this now the final report? The final report that was due two weeks ago.

Can you explain how this document is going to reconcile the recent response 
we got from Entrust over this bug? 
https://bugzilla.mozilla.org/show_bug.cgi?id=1890685#c46

Specifically:

> Thanks, Tim. In Comment 29 
 posted on June 
5, 2024, we issued an updated incident report for this bug stating that we 
no longer believe this is a mis-issuance. Given this position, there should 
be no need for further reporting as described in your Question 1.

On Friday, June 21, 2024 at 3:21:08 PM UTC-4 Mike Shaver wrote:

> Thanks, Bruce.
>
> On first quick read of the response, I have some concerns about specific 
> elements but the level of detail and specificity is much more appropriate, 
> IMO, than with the first response. Thank you for those additions.
>
> What is the best way to provide feedback on this improved response? I 
> think there are a few important questions still open.
>
> Mike
>
> On Fri, Jun 21, 2024 at 2:59 PM 'Bruce Morton' via 
> dev-secur...@mozilla.org  wrote:
>
>> Attached is a letter from Bhagwat Swaroop, President of Entrust Digital 
>> Security Solutions, along with an updated response to address questions 
>> from the community.
>>
>> Thanks, Bruce.
>>
>> On Tuesday, June 18, 2024 at 1:35:48 PM UTC-4 Amir Omidi (aaomidi) wrote:
>>
>>> I am not going to say with certainty that Entrust is definitely putting 
>>> Chrome over Mozilla. However, I hope they know that most Linux systems out 
>>> there use the Mozilla root store directly.
>>> On Tuesday, June 18, 2024 at 1:12:19 PM UTC-4 Mike Shaver wrote:
>>>
 On Tue, Jun 18, 2024 at 12:49 PM Walt  wrote:

> I'd just like to point out that we now have a situation where Entrust 
> is in the position of seemingly valuing the opinion of other Root 
> Programs 
> over Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c42
>
> In Comment #37, it was hinted at (and made slightly more explicit in 
> #39) that the opinion of the Mozilla RP is that the attempt to 
> re-characterize these certs was not going to be looked kindly upon, and 
> only once a Google RP member explicitly said that it was the Google RP 
> opinion that the certs remained mis-issued was any movement made on 
> re-confirming the mis-issuance and taking action to revoke them.
>
> Also, if we're in a position where Entrust is finally able to commit 
> to revoking certs within a 5 day period (setting aside that these certs 
> technically need a delayed revocation bug as the mis-issuance was known 
> as 
> far back as 2024-04-10), why are other incidents not able to be resolved 
> in 
> this amount of time? Is it because Google showed up? 
>

 We’ve seen this behaviour in other incidents as well, I believe 
 including the cpsURI one that has turned into a magnet for evidence of 
 poor 
 operation and lack of transparency and responsiveness. I remarked on it in 
 my initial snarky reply to the Entrust Report, in fact.

 From a realpolitik perspective their behaviour could indeed be 
 rational, especially when the only tool root programs have is distrust. 
 Firefox would suffer substantial market disadvantage if it stopped 
 trusting 
 Entrust certificates when other browsers didn’t. I think people generally 
 underestimate how much Mozilla would be willing to take near-term pain to 
 protect users, but it’s also possible that I am overestimating it.

 Related to that, I think Chrome’s root program representatives have 
 generally been more willing to take a concrete position quickly, so 
 Mozilla 
 might be waiting for more explanation when Chrome decides that there’s no 
 explanation that could suffice, or similar. The root programs tend to be 
 in 
 agreement more often than not (virtually always with Chrome and Mozilla, I 
 would say, excepting some slightly different root store populations), so 
 it 
 may be somewhat irrelevant whose opinion spurs motion.

 Realpolitik analysis aside, I do agree that Entrust has created the 
 impression that they care much more about Chrome’s opinion than Mozilla’s, 
 which IMO might not be the best posture to take given that Mozilla and its 
 community are the locus for the processing and evaluation of the incidents 
 in question.

 Mike



 -- 
>> You received this message because you are subscribed to the Google Groups 
>> "dev-secur...@mozilla.org" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to dev-security-po...@mozilla.org.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/f3cebe9b-fa25-4b11-ba3d-b7f3f6e0f719n%40mozilla.org
>

Re: Recent Entrust Compliance Incidents

[Mike Shaver]

Thanks, Bruce.

On first quick read of the response, I have some concerns about specific
elements but the level of detail and specificity is much more appropriate,
IMO, than with the first response. Thank you for those additions.

What is the best way to provide feedback on this improved response? I think
there are a few important questions still open.

Mike

On Fri, Jun 21, 2024 at 2:59 PM 'Bruce Morton' via
dev-security-policy@mozilla.org  wrote:

> Attached is a letter from Bhagwat Swaroop, President of Entrust Digital
> Security Solutions, along with an updated response to address questions
> from the community.
>
> Thanks, Bruce.
>
> On Tuesday, June 18, 2024 at 1:35:48 PM UTC-4 Amir Omidi (aaomidi) wrote:
>
>> I am not going to say with certainty that Entrust is definitely putting
>> Chrome over Mozilla. However, I hope they know that most Linux systems out
>> there use the Mozilla root store directly.
>> On Tuesday, June 18, 2024 at 1:12:19 PM UTC-4 Mike Shaver wrote:
>>
>>> On Tue, Jun 18, 2024 at 12:49 PM Walt  wrote:
>>>
 I'd just like to point out that we now have a situation where Entrust
 is in the position of seemingly valuing the opinion of other Root Programs
 over Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c42

 In Comment #37, it was hinted at (and made slightly more explicit in
 #39) that the opinion of the Mozilla RP is that the attempt to
 re-characterize these certs was not going to be looked kindly upon, and
 only once a Google RP member explicitly said that it was the Google RP
 opinion that the certs remained mis-issued was any movement made on
 re-confirming the mis-issuance and taking action to revoke them.

 Also, if we're in a position where Entrust is finally able to commit to
 revoking certs within a 5 day period (setting aside that these certs
 technically need a delayed revocation bug as the mis-issuance was known as
 far back as 2024-04-10), why are other incidents not able to be resolved in
 this amount of time? Is it because Google showed up?

>>>
>>> We’ve seen this behaviour in other incidents as well, I believe
>>> including the cpsURI one that has turned into a magnet for evidence of poor
>>> operation and lack of transparency and responsiveness. I remarked on it in
>>> my initial snarky reply to the Entrust Report, in fact.
>>>
>>> From a realpolitik perspective their behaviour could indeed be rational,
>>> especially when the only tool root programs have is distrust. Firefox would
>>> suffer substantial market disadvantage if it stopped trusting Entrust
>>> certificates when other browsers didn’t. I think people generally
>>> underestimate how much Mozilla would be willing to take near-term pain to
>>> protect users, but it’s also possible that I am overestimating it.
>>>
>>> Related to that, I think Chrome’s root program representatives have
>>> generally been more willing to take a concrete position quickly, so Mozilla
>>> might be waiting for more explanation when Chrome decides that there’s no
>>> explanation that could suffice, or similar. The root programs tend to be in
>>> agreement more often than not (virtually always with Chrome and Mozilla, I
>>> would say, excepting some slightly different root store populations), so it
>>> may be somewhat irrelevant whose opinion spurs motion.
>>>
>>> Realpolitik analysis aside, I do agree that Entrust has created the
>>> impression that they care much more about Chrome’s opinion than Mozilla’s,
>>> which IMO might not be the best posture to take given that Mozilla and its
>>> community are the locus for the processing and evaluation of the incidents
>>> in question.
>>>
>>> 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/f3cebe9b-fa25-4b11-ba3d-b7f3f6e0f719n%40mozilla.org
> 
> .
>

-- 
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/CADQzZqtK5V6A1_vGBCKFBZFnqx6izBKRcFJF2aVsWnHjWAAjOQ%40mail.gmail.com.

Re: Recent Entrust Compliance Incidents

['Amir Omidi (aaomidi)' via dev-security-policy@mozilla.org]

I am not going to say with certainty that Entrust is definitely putting 
Chrome over Mozilla. However, I hope they know that most Linux systems out 
there use the Mozilla root store directly.
On Tuesday, June 18, 2024 at 1:12:19 PM UTC-4 Mike Shaver wrote:

> On Tue, Jun 18, 2024 at 12:49 PM Walt  wrote:
>
>> I'd just like to point out that we now have a situation where Entrust is 
>> in the position of seemingly valuing the opinion of other Root Programs 
>> over Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c42
>>
>> In Comment #37, it was hinted at (and made slightly more explicit in #39) 
>> that the opinion of the Mozilla RP is that the attempt to re-characterize 
>> these certs was not going to be looked kindly upon, and only once a Google 
>> RP member explicitly said that it was the Google RP opinion that the certs 
>> remained mis-issued was any movement made on re-confirming the mis-issuance 
>> and taking action to revoke them.
>>
>> Also, if we're in a position where Entrust is finally able to commit to 
>> revoking certs within a 5 day period (setting aside that these certs 
>> technically need a delayed revocation bug as the mis-issuance was known as 
>> far back as 2024-04-10), why are other incidents not able to be resolved in 
>> this amount of time? Is it because Google showed up? 
>>
>
> We’ve seen this behaviour in other incidents as well, I believe including 
> the cpsURI one that has turned into a magnet for evidence of poor operation 
> and lack of transparency and responsiveness. I remarked on it in my initial 
> snarky reply to the Entrust Report, in fact.
>
> From a realpolitik perspective their behaviour could indeed be rational, 
> especially when the only tool root programs have is distrust. Firefox would 
> suffer substantial market disadvantage if it stopped trusting Entrust 
> certificates when other browsers didn’t. I think people generally 
> underestimate how much Mozilla would be willing to take near-term pain to 
> protect users, but it’s also possible that I am overestimating it.
>
> Related to that, I think Chrome’s root program representatives have 
> generally been more willing to take a concrete position quickly, so Mozilla 
> might be waiting for more explanation when Chrome decides that there’s no 
> explanation that could suffice, or similar. The root programs tend to be in 
> agreement more often than not (virtually always with Chrome and Mozilla, I 
> would say, excepting some slightly different root store populations), so it 
> may be somewhat irrelevant whose opinion spurs motion.
>
> Realpolitik analysis aside, I do agree that Entrust has created the 
> impression that they care much more about Chrome’s opinion than Mozilla’s, 
> which IMO might not be the best posture to take given that Mozilla and its 
> community are the locus for the processing and evaluation of the incidents 
> in question.
>
> 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/1a27affb-9970-405a-b5ba-884410df511cn%40mozilla.org.

Re: Recent Entrust Compliance Incidents

[Mike Shaver]

On Tue, Jun 18, 2024 at 12:49 PM Walt  wrote:

> I'd just like to point out that we now have a situation where Entrust is
> in the position of seemingly valuing the opinion of other Root Programs
> over Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c42
>
> In Comment #37, it was hinted at (and made slightly more explicit in #39)
> that the opinion of the Mozilla RP is that the attempt to re-characterize
> these certs was not going to be looked kindly upon, and only once a Google
> RP member explicitly said that it was the Google RP opinion that the certs
> remained mis-issued was any movement made on re-confirming the mis-issuance
> and taking action to revoke them.
>
> Also, if we're in a position where Entrust is finally able to commit to
> revoking certs within a 5 day period (setting aside that these certs
> technically need a delayed revocation bug as the mis-issuance was known as
> far back as 2024-04-10), why are other incidents not able to be resolved in
> this amount of time? Is it because Google showed up?
>

We’ve seen this behaviour in other incidents as well, I believe including
the cpsURI one that has turned into a magnet for evidence of poor operation
and lack of transparency and responsiveness. I remarked on it in my initial
snarky reply to the Entrust Report, in fact.

>From a realpolitik perspective their behaviour could indeed be rational,
especially when the only tool root programs have is distrust. Firefox would
suffer substantial market disadvantage if it stopped trusting Entrust
certificates when other browsers didn’t. I think people generally
underestimate how much Mozilla would be willing to take near-term pain to
protect users, but it’s also possible that I am overestimating it.

Related to that, I think Chrome’s root program representatives have
generally been more willing to take a concrete position quickly, so Mozilla
might be waiting for more explanation when Chrome decides that there’s no
explanation that could suffice, or similar. The root programs tend to be in
agreement more often than not (virtually always with Chrome and Mozilla, I
would say, excepting some slightly different root store populations), so it
may be somewhat irrelevant whose opinion spurs motion.

Realpolitik analysis aside, I do agree that Entrust has created the
impression that they care much more about Chrome’s opinion than Mozilla’s,
which IMO might not be the best posture to take given that Mozilla and its
community are the locus for the processing and evaluation of the incidents
in question.

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/CADQzZqst2vaiaum%2BPomUJq7jRQvSn%3Dxhg9khxYwXyKeY9e8f7w%40mail.gmail.com.

Re: Recent Entrust Compliance Incidents

[Walt]

I'd just like to point out that we now have a situation where Entrust is in 
the position of seemingly valuing the opinion of other Root Programs over 
Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c42

In Comment #37, it was hinted at (and made slightly more explicit in #39) 
that the opinion of the Mozilla RP is that the attempt to re-characterize 
these certs was not going to be looked kindly upon, and only once a Google 
RP member explicitly said that it was the Google RP opinion that the certs 
remained mis-issued was any movement made on re-confirming the mis-issuance 
and taking action to revoke them.

Also, if we're in a position where Entrust is finally able to commit to 
revoking certs within a 5 day period (setting aside that these certs 
technically need a delayed revocation bug as the mis-issuance was known as 
far back as 2024-04-10), why are other incidents not able to be resolved in 
this amount of time? Is it because Google showed up?  

On Friday, June 14, 2024 at 2:43:06 PM UTC-7 Wayne wrote:

> Even taking Entrust's statements in the past hour at face value we have an 
> issue. At no point have they communicated this change or even implied it 
> was happening despite questioning over the matter for weeks. There is not a 
> single mention like this in their formal report.
>
> There is a serious culture issue at play internally and it needs to be 
> addressed. I said I gave Entrust every opportunity to explain. Why did it 
> take until now for some semblance of an excuse to appear?
>
> Not only that but we're being told that in incident 1897630 
>  that different 
> incident response processes were being followed. This does match the 
> statements in there that everything was ad-hoc, and emphasizes that 
> incident response processes are not being followed internally even at this 
> stage.
>
> I do however appreciate that Entrust have finally brought in their 
> emergency planning personnel several months late, I wish them the best of 
> luck.
>
> - Wayne
>
> On Friday, June 14, 2024 at 9:55:38 PM UTC+1 Bruce Morton wrote:
>
>> Amir, we will respond to the comments from the community, but I want to 
>> make it clear that Entrust was absolutely NOT trying to "conceal" anything 
>> related to how we do revocation and are disturbed that you would attribute 
>> "malicious" motives to any of our actions.  The "30 day revocation" option 
>> is a standard option for subscribers in our system that allows them to 
>> replace certificates safely before revoking. In normal course, a subscriber 
>> would just leave them in this "bucket”, and they would automatically be 
>> revoked. When we posted the letter originally, we shared it as an example 
>> of what was sent from us directly to a subscriber and was not posted in the 
>> public domain. We were being transparent by sharing the message.  The 
>> redacted section provides specific instructions to our subscribers on how 
>> to revoke and reissue certificates. 
>>
>> “Revoke within 30 days” was one of two options in the tool. Certificates 
>> placed in this status were reissued within 30 days of when they were placed 
>> in this status; we revoked them sooner if their extension time was reached, 
>> or if the subscriber confirmed they had reissued.
>>
>> Prior to April 4, 2024, customer could only select "Revoke immediately" 
>> or "Revoke in 30 days".  The default for use in the instructions on March 
>> 18 2024 was "Revoke in 30 days".  Recognizing, this may have been perceived 
>> by customers that they then had 30 days vs the 5 day timeline that was 
>> communicated, Entrust implemented a change to add "Revoke in 3 days" as the 
>> default moving forward to be called out in the event of future 
>> mis-issuance. 
>>
>> [image: Revoke in 3 days.png]
>>
>> These updated instructions with the use of the ‘3 day’ revocation button 
>> were used when communicating with subscribers for Bug 1897630. 
>>
>> *“Complete the Reissue and select "Revoke in 3 days"* so your production 
>> certificate maintains validity and provides you with sufficient time to 
>> perform the replacement. Note: This does NOT mean your certificate will be 
>> valid for another 3 days. It is just a mechanism to not immediately revoke 
>> your certificate during the replacement process.”
>>
>> The full communication can be review in the attached. 
>>
>> On Friday, June 14, 2024 at 10:11:34 AM UTC-4 Amir Omidi wrote:
>>
>> I missed that they tried to conceal the part of the email where 30 day 
>> revocation was granted. How on earth is this acceptable? 
>>
>> I’ll have to go double check everything in your correspondence here, but 
>> if this is all true then this is deeply unsettling and concerning.
>>
>> Root program, I implore you to expedite the processing of these issues: 
>> If the concealment of the revocation information was willful, then there’s 
>> no reason to believe that Entrust hasn’t also acted mal

Re: Recent Entrust Compliance Incidents

[Wayne]

Even taking Entrust's statements in the past hour at face value we have an 
issue. At no point have they communicated this change or even implied it 
was happening despite questioning over the matter for weeks. There is not a 
single mention like this in their formal report.

There is a serious culture issue at play internally and it needs to be 
addressed. I said I gave Entrust every opportunity to explain. Why did it 
take until now for some semblance of an excuse to appear?

Not only that but we're being told that in incident 1897630 
 that different 
incident response processes were being followed. This does match the 
statements in there that everything was ad-hoc, and emphasizes that 
incident response processes are not being followed internally even at this 
stage.

I do however appreciate that Entrust have finally brought in their 
emergency planning personnel several months late, I wish them the best of 
luck.

- Wayne

On Friday, June 14, 2024 at 9:55:38 PM UTC+1 Bruce Morton wrote:

> Amir, we will respond to the comments from the community, but I want to 
> make it clear that Entrust was absolutely NOT trying to "conceal" anything 
> related to how we do revocation and are disturbed that you would attribute 
> "malicious" motives to any of our actions.  The "30 day revocation" option 
> is a standard option for subscribers in our system that allows them to 
> replace certificates safely before revoking. In normal course, a subscriber 
> would just leave them in this "bucket”, and they would automatically be 
> revoked. When we posted the letter originally, we shared it as an example 
> of what was sent from us directly to a subscriber and was not posted in the 
> public domain. We were being transparent by sharing the message.  The 
> redacted section provides specific instructions to our subscribers on how 
> to revoke and reissue certificates. 
>
> “Revoke within 30 days” was one of two options in the tool. Certificates 
> placed in this status were reissued within 30 days of when they were placed 
> in this status; we revoked them sooner if their extension time was reached, 
> or if the subscriber confirmed they had reissued.
>
> Prior to April 4, 2024, customer could only select "Revoke immediately" or 
> "Revoke in 30 days".  The default for use in the instructions on March 18 
> 2024 was "Revoke in 30 days".  Recognizing, this may have been perceived by 
> customers that they then had 30 days vs the 5 day timeline that was 
> communicated, Entrust implemented a change to add "Revoke in 3 days" as the 
> default moving forward to be called out in the event of future 
> mis-issuance. 
>
> [image: Revoke in 3 days.png]
>
> These updated instructions with the use of the ‘3 day’ revocation button 
> were used when communicating with subscribers for Bug 1897630. 
>
> *“Complete the Reissue and select "Revoke in 3 days"* so your production 
> certificate maintains validity and provides you with sufficient time to 
> perform the replacement. Note: This does NOT mean your certificate will be 
> valid for another 3 days. It is just a mechanism to not immediately revoke 
> your certificate during the replacement process.”
>
> The full communication can be review in the attached. 
>
> On Friday, June 14, 2024 at 10:11:34 AM UTC-4 Amir Omidi wrote:
>
> I missed that they tried to conceal the part of the email where 30 day 
> revocation was granted. How on earth is this acceptable? 
>
> I’ll have to go double check everything in your correspondence here, but 
> if this is all true then this is deeply unsettling and concerning.
>
> Root program, I implore you to expedite the processing of these issues: If 
> the concealment of the revocation information was willful, then there’s no 
> reason to believe that Entrust hasn’t also acted maliciously in other 
> areas. 
>
> Amir Omidi (he/them)
>
>
>

-- 
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/4b46ec7d-77c8-4c38-a170-bdbb5e9f8c0bn%40mozilla.org.

Re: Recent Entrust Compliance Incidents

[Mike Shaver]

On Fri, Jun 14, 2024 at 4:55 PM 'Bruce Morton' via
dev-security-policy@mozilla.org  wrote:

> Amir, we will respond to the comments from the community, but I want to
> make it clear that Entrust was absolutely NOT trying to "conceal" anything
> related to how we do revocation
>
You redacted a part of the email about how customers were to go about
reissuing and revoking, which is *literally* concealing something related
to revocation. That’s what redacting is. It’s the only reason that anything
is ever redacted. What are you even trying to say here?

The redacted section provides specific instructions to our subscribers on
> how to revoke and reissue certificates.
>
cool, cool

Why was it important to redact that section? It has no confidential
information in it as far as I can tell.

I exhort you, for your own sake, to seriously read my guidance in
https://bugzilla.mozilla.org/show_bug.cgi?id=1886532#c64 as to how to
properly communicate the reasons for, and details of, the changes that are
being listed as things that will improve Entrust’s operations.

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/CADQzZqs6YvA9HnXhHftAZOsq75-7gsWDCvuYBaPTdeg-CqFCUA%40mail.gmail.com.

Re: Recent Entrust Compliance Incidents

['Bruce Morton' via dev-security-policy@mozilla.org]

To the Community -

We wanted to let you know that we have been monitoring this conversation. 
We appreciate your feedback here and plan to share a response next week.

Best regards, Bruce.

-- 
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/2b7b227f-7d1c-4743-a861-a57b1a1f5f26n%40mozilla.org.

Re: Recent Entrust Compliance Incidents

[Ryan Hurst]

To me, it seems that Entrust has forgotten why we are all here. The purpose 
of the WebPKI is to enable end-users to trust that they are communicating 
with the correct website. This trust relies on the CAs that make up the 
WebPKI to be transparent and live up to their promises while adhering to 
ecosystem norms, requirements, and best practices. Root programs act as the 
arbitrators of who is worthy of that trust by enforcing these norms, rules, 
and best practices on behalf of the end-users they serve.

As I review the various incidents at hand, the bugs tracking them, the 
incident responses, and the associated timelines, a few key elements stand 
out to me:

   - 
   
   Lack of Transparency and Accountability: Entrust’s incident reports and 
   responses lacked transparency and failed to acknowledge where the fault lay.
   - 
   
   Failure to Meet Previous Commitments: Despite previous commitments made 
   in 2020 to avoid delayed revocations and adhere to BRs, Entrust continued 
   to face similar issues.
   - 
   
   Inadequate Root Cause Analysis: The root cause analyses provided by 
   Entrust were often superficial and did not address systemic failures.
   - 
   
   Insufficient Remediation Plans: Entrust's remediation plans were vague, 
   lacking concrete, measurable steps, and often repeated previous commitments 
   without acknowledging how they had previously failed to live up to these 
   commitments.
   - 
   
   Lack of Organizational Self-awareness: Entrust's responses indicated a 
   lack of self-awareness about the depth of their issues. They did not show a 
   comprehensive understanding of the systemic problems leading to repeated 
   incidents.
   - 
   
   Belief in Exemption from Norms: Entrust has demonstrated through their 
   actions and responses that they believe the norms, policies, and 
   requirements do not equally apply to them.
   - 
   
   Slow Response Times: Looking at similar incidents, the timeline 
   associated with Entrust's responses was slow relative to other 
   similar-sized organizations and smaller CAs.
   
In Entrust’s responses to these incidents, they have leaned on their long 
history in this industry and the impact they have had. In that vein, I 
can't help but see parallels to the recent Microsoft CSRB review of 
STORM-0558, where the reviewers said that “Microsoft’s security culture was 
inadequate and requires an overhaul, particularly in light of the company’s 
centrality in the technology ecosystem and the level of trust customers 
place in the company to protect their data and operations.”

The immediate technical non-conformities we are discussing here, when 
looked at in isolation, are not major issues. I even understand why Entrust 
is hesitant to require their customers, who are largely Enterprise 
customers who are notoriously hard to deal with on such matters, to replace 
their certificates as a result of Entrust’s operational non-compliance. 
However, when we consider them as a body of issues, especially over time, 
and the way Entrust has responded to them, they reach a significant level. 
We need to be asking ourselves: is this the kind of behavior we want to 
establish as the norm for the WebPKI?

More broadly, the pattern of non-compliance demonstrated by Entrust, 
combined with the fact that other, smaller CAs with fewer resources have 
managed to respond significantly faster and more proactively, makes me ask 
the question: when we see systemic issues, do we wait until they are 
catastrophic before we, as the custodians of the WebPKI, respond?

In the end, the answers to these questions will need to be provided by the 
root programs. However, if I were at Entrust, I would have been doing some 
serious soul-searching over the past quarter about the cultural and 
organizational issues that led to this point.

I would also like to encourage other CAs who are watching this transpire to 
review their practices and ensure their incident response procedures are 
transparent, proactive, focused on root cause analysis, and more broadly in 
line with the expected norms of our community.


Ryan Hurst

-- 
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/91a11d66-afc5-440b-bb83-123a665d66e0n%40mozilla.org.

Re: Recent Entrust Compliance Incidents

[Wayne]

Given the topic of the concealed '30 day' step is coming up I do wish to 
clarify my intent. I had been less than subtly telling Entrust for nearly a 
month  that this 
information was known, and was giving them the option to come forward about 
an issue that could look bad if it came to light without context. I had 
been hoping that a mistake was made in March and that it would be 
acknowledged and treated seriously. I attempted every step of the way to 
let Entrust provide the information themselves so that they could explain 
their intentions and clear up any confusion in advance.

That they chose not to is still perplexing to me. I appreciated this could 
be an embarrassing default text string that they never considered in the 4 
years since their prior commitments. However given their actions in 
response, I can only surmise that it was working as intended.

I still hope they clarify this matter at some point, they have had more 
than enough opportunities. On that note what is Mozilla's policy for a CA 
answering questions posed on MDSP and the applicable timeframe? I am sure 
the rest of the community are as puzzled over the report received and would 
appreciate clarifications.

- Wayne

On Friday, June 14, 2024 at 3:22:21 PM UTC+1 Mike Shaver wrote:

> On Fri, 14 Jun 2024 at 10:11, Amir Omidi  wrote:
>
>> I missed that they tried to conceal the part of the email where 30 day 
>> revocation was granted. How on earth is this acceptable? 
>>
>
> I want to be clear here: I don't know that that part of the instructions 
> was meant to convey to affected Subscribers that 30 days would be an 
> acceptable timeline for revocation (though of course many certificates 
> didn't even get replaced that quickly...). It may be, for example, that the 
> software in question is limited such that it only offers "reissue with 
> immediate revocation" and "reissue with 30 day revocation". In that case, 
> the latter would be an appropriate choice even if the revocation was to 
> happen on a shorter timeline.
>
> My concern is that *they chose to conceal *this part of the 
> correspondence, and I cannot come up with a good faith reason for doing so 
> given the information that is already public about the ECS system and how 
> to reissue. Obviously the term "30 day" is weird to see there, but if there 
> was a good reason for it (probably a better reason than the one I imagined 
> above), then they should have provided the reason rather than clumsily 
> attempting to conceal part of it. (And after Wayne had indicated both in 
> mdsp and in the incident itself that the contents were already known to 
> some...)
>  
>
>> I’ll have to go double check everything in your correspondence here, but 
>> if this is all true then this is deeply unsettling and concerning.
>>
>
> Please do so! There have been a lot of comments with a lot of slightly 
> different contents and statements, and it's entirely possible that I 
> mis-referenced something, or made an outright error in my analysis.
>
> 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/6e35dbdf-ad03-428f-a641-67e1a981889cn%40mozilla.org.

Re: Recent Entrust Compliance Incidents

[Mike Shaver]

On Fri, 14 Jun 2024 at 10:11, Amir Omidi  wrote:

> I missed that they tried to conceal the part of the email where 30 day
> revocation was granted. How on earth is this acceptable?
>

I want to be clear here: I don't know that that part of the instructions
was meant to convey to affected Subscribers that 30 days would be an
acceptable timeline for revocation (though of course many certificates
didn't even get replaced that quickly...). It may be, for example, that the
software in question is limited such that it only offers "reissue with
immediate revocation" and "reissue with 30 day revocation". In that case,
the latter would be an appropriate choice even if the revocation was to
happen on a shorter timeline.

My concern is that *they chose to conceal *this part of the correspondence,
and I cannot come up with a good faith reason for doing so given the
information that is already public about the ECS system and how to reissue.
Obviously the term "30 day" is weird to see there, but if there was a good
reason for it (probably a better reason than the one I imagined above),
then they should have provided the reason rather than clumsily attempting
to conceal part of it. (And after Wayne had indicated both in mdsp and in
the incident itself that the contents were already known to some...)


> I’ll have to go double check everything in your correspondence here, but
> if this is all true then this is deeply unsettling and concerning.
>

Please do so! There have been a lot of comments with a lot of slightly
different contents and statements, and it's entirely possible that I
mis-referenced something, or made an outright error in my analysis.

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/CADQzZqt78gEbViukP1TrNs3fJLLdD_MeU9ukm7jJEBm%2Bv9WvbA%40mail.gmail.com.

Re: Recent Entrust Compliance Incidents

['Amir Omidi' via dev-security-policy@mozilla.org]

I missed that they tried to conceal the part of the email where 30 day
revocation was granted. How on earth is this acceptable?

I’ll have to go double check everything in your correspondence here, but if
this is all true then this is deeply unsettling and concerning.

Root program, I implore you to expedite the processing of these issues: If
the concealment of the revocation information was willful, then there’s no
reason to believe that Entrust hasn’t also acted maliciously in other
areas.

Amir Omidi (he/them)


On Fri, Jun 14, 2024 at 13:59 Mike Shaver  wrote:

> Apologies for the delayed response; it took longer than I expected to go
> through the many similar incidents and find the references I wanted, and
> indeed in the end I omitted many others. Thanks to Ben and the Mozilla
> community for their patience.
>
> Entrust Report Comments
> First, I just have to say that given Ben's very explicit expectations in
> the request for a response, the contents of Entrust's report are shockingly
> poor. They failed to address many of the requirements, and the entire
> exercise reads like a rushed homework assignment--not a credible plan by
> one of the most experienced CAs on the web to restore their operations to
> the level of quality and compliance expected by the Mozilla Root Program.
> Shallow Action Item Specifications
>
> The Executive Summary claims that the report provides a “detailed overview
> of concrete, measurable steps”, but the Action Items included in the report
> are often neither detailed, nor measurable.
>
> A single example, from "2.1.4 Improvement Plan": “Establish
> cross-functional change control board: Complete”. There is no detail as to
> what this board will decide, how they will be selected, or how their
> effectiveness can be measured. This Action Item is, as described, basically
> just "we made a list of some people".
> Inadequate Response to Delayed Revocation Incidents
>
> The Mozilla Root Store Policy itself does not itself admit to any option
> for delayed revocation. It references the BRs, which require (SHALL and
> MUST language) revocation within 5 days. Provisions for delayed revocation
> only come from Mozilla's "Responding To An Incident" page at
> https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation .
> Mozilla grants generous latitude to CAs in that CAs are permitted to weigh
> the impact of revocation against the impact of further delaying revocation,
> but it also makes clear what is expected from a CA when it decides that the
> circumstances are "exceptional", such as when used in "critical
> infrastructure".
>
> In https://bugzilla.mozilla.org/show_bug.cgi?id=1886532#c35 , Ngook Kong
> clarifies Entrust's position on these expectations:
>
> Our interpretation is any delayed revocation will comply with the Mozilla
> revocation policy at
> https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation
>
> Unfortunately, Entrust has systematically failed to comply with the policy
> to which they refer.
>
> Requirement: "The decision and rationale for delaying revocation will be
> disclosed in the form of a preliminary incident report immediately;
> preferably before the BR-mandated revocation deadline. The rationale must
> include detailed and substantiated explanations for why the situation is
> exceptional. Responses similar to “we do not deem this non-compliant
> certificate to be a security risk” are not acceptable. When revocation is
> delayed at the request of specific Subscribers, the rationale must be
> provided on a per-Subscriber basis."
>
> Entrust's delayed revocation incidents have consistently failed to meet
> this expectation. In two of the three delayed revocation incidents that
> Entrust chose to include in their report, no per-subscriber information
> whatsoever was provided, with the exception of a comment that listed four
> out of more than 100 affected subscribers. When rationales are provided (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1886532#c32), they are
> insufficiently detailed: they do not contain enough information to
> determine whether the proposed action items are likely to meaningfully
> affect the risk of future delayed-revocation incidents.
>
> This item has been present, in substantially identical form, since 2019,
> so it was well known to Entrust when they made their commitments in 2020 to
> avoid delayed revocation and adhere to the BRs and root program
> expectations. It is alarming that a CA that boasts of its long experience
> in the web PKI and involvement in the community is still consistently
> unable or unwilling to adhere to those requirements.
>
> Requirement: "Your CA will work with your auditor (and supervisory body,
> as appropriate) and the Root Store(s) that your CA participates in to
> ensure your analysis of the risk and plan of remediation is acceptable."
>
> To the best of my ability to determine, no Root Stores were consulted with
> regards to the risk analysis or plan of remediation; Ben W

Re: Recent Entrust Compliance Incidents

[Mike Shaver]

 Apologies for the delayed response; it took longer than I expected to go
through the many similar incidents and find the references I wanted, and
indeed in the end I omitted many others. Thanks to Ben and the Mozilla
community for their patience.

Entrust Report Comments
First, I just have to say that given Ben's very explicit expectations in
the request for a response, the contents of Entrust's report are shockingly
poor. They failed to address many of the requirements, and the entire
exercise reads like a rushed homework assignment--not a credible plan by
one of the most experienced CAs on the web to restore their operations to
the level of quality and compliance expected by the Mozilla Root Program.
Shallow Action Item Specifications

The Executive Summary claims that the report provides a “detailed overview
of concrete, measurable steps”, but the Action Items included in the report
are often neither detailed, nor measurable.

A single example, from "2.1.4 Improvement Plan": “Establish
cross-functional change control board: Complete”. There is no detail as to
what this board will decide, how they will be selected, or how their
effectiveness can be measured. This Action Item is, as described, basically
just "we made a list of some people".
Inadequate Response to Delayed Revocation Incidents

The Mozilla Root Store Policy itself does not itself admit to any option
for delayed revocation. It references the BRs, which require (SHALL and
MUST language) revocation within 5 days. Provisions for delayed revocation
only come from Mozilla's "Responding To An Incident" page at
https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation . Mozilla
grants generous latitude to CAs in that CAs are permitted to weigh the
impact of revocation against the impact of further delaying revocation, but
it also makes clear what is expected from a CA when it decides that the
circumstances are "exceptional", such as when used in "critical
infrastructure".

In https://bugzilla.mozilla.org/show_bug.cgi?id=1886532#c35 , Ngook Kong
clarifies Entrust's position on these expectations:

Our interpretation is any delayed revocation will comply with the Mozilla
revocation policy at
https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation

Unfortunately, Entrust has systematically failed to comply with the policy
to which they refer.

Requirement: "The decision and rationale for delaying revocation will be
disclosed in the form of a preliminary incident report immediately;
preferably before the BR-mandated revocation deadline. The rationale must
include detailed and substantiated explanations for why the situation is
exceptional. Responses similar to “we do not deem this non-compliant
certificate to be a security risk” are not acceptable. When revocation is
delayed at the request of specific Subscribers, the rationale must be
provided on a per-Subscriber basis."

Entrust's delayed revocation incidents have consistently failed to meet
this expectation. In two of the three delayed revocation incidents that
Entrust chose to include in their report, no per-subscriber information
whatsoever was provided, with the exception of a comment that listed four
out of more than 100 affected subscribers. When rationales are provided (
https://bugzilla.mozilla.org/show_bug.cgi?id=1886532#c32), they are
insufficiently detailed: they do not contain enough information to
determine whether the proposed action items are likely to meaningfully
affect the risk of future delayed-revocation incidents.

This item has been present, in substantially identical form, since 2019, so
it was well known to Entrust when they made their commitments in 2020 to
avoid delayed revocation and adhere to the BRs and root program
expectations. It is alarming that a CA that boasts of its long experience
in the web PKI and involvement in the community is still consistently
unable or unwilling to adhere to those requirements.

Requirement: "Your CA will work with your auditor (and supervisory body, as
appropriate) and the Root Store(s) that your CA participates in to ensure
your analysis of the risk and plan of remediation is acceptable."

To the best of my ability to determine, no Root Stores were consulted with
regards to the risk analysis or plan of remediation; Ben Wilson's comment
at https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c19 seems to
indicate that Mozilla's root program representatives were not consulted.
There has also not been any indication of auditor involvement. If indeed
Entrust worked with their auditor with respect to the decisions not to
revoke captured in bugs 1890898 and 1890685, it is difficult to understand
how their later analysis came to a different conclusion.
Investment in Incident Response Capacity

Ngook Kong states in
https://bugzilla.mozilla.org/show_bug.cgi?id=1886532#c51:

"Yes, we are equipped to perform a wide scale revocation if needed and
necessary. [...] We have the technical capability to revoke within the
required timeline

Re: Recent Entrust Compliance Incidents

[Walt]

All,

If we strip away the cover page, table of contents, appendices and 
executive summary, the 17 page report goes down to somewhere in the realm 
of 13 pages. 

If we take a closer look at those 13 pages, there's very little new 
information shared in the report that wasn't already shared in the various 
Bugzilla incidents. I don't see internal policies or procedures used to 
make their decisions on delayed revocation, I see exactly one reference to 
the previous delrev issues in 2020, in which it is offhandedly mentioned 
and again pushed onto Subscribers' responsibility, rather than the CA. I 
see statements that say "we intend to revoke following the BRs, unless a 
subscriber says we don't want to". I see references to IETF drafts and 
adoption of automation, but again, those *are not action items for a 
delayed revocation. *The problem is "we failed to revoke certificates, 
here's what we're doing to fix *that* problem", and the analysis and action 
items should reflect that. 

I also think it is absolutely impossible to judge a report at this point 
for the following reasons: 
1. There are still unresolved delrev / failure to revoke incidents in 
Bugzilla, and this report is now drifting from what exists in Bugzilla. 
2. Entrust is being even more evasive in answering questions in Bugzilla as 
of this report. There are numerous questions I as well as other community 
members, as well as individuals at other CAs have asked of Entrust that 
have either been ignored completely, ignored past the 7 day response period 
and only answered when prompted by another community member, and when 
answers are provided, they are seemingly copied from a internal working 
document on the best applicable answer that appears to have been 
workshopped, rather than the actual answer. Off the top of my head, I have 
multiple questions in 1886532 that remain unsatisfactorily answered, 
questions that should be a relatively easy answer. See Comment 52 


If the report actually had action items and a deep understanding of the 
root causes that led them to this situation of failure to revoking 
certificates after promising it would never happen again, I would look 
differently upon this. Instead I see:
- a report that admits to a policy that was supposed to be implemented 4 
years ago is barely implemented, if at all (as if it were implemented it 
should have been documented in the report)
- a CA who is being combative and evasive (which is just wrong from a 
public trust point of view)
- certificates re-characterized as properly issued after being 
characterized as mis-issued (which is something that should absolutely be 
looked closer at, if the perceived solution by a CA to avoiding delayed 
revocation events is to simply re-characterize the certs as issued 
appropriately and refuse to elaborate further feels like something that is 
*Very 
Bad* for the ecosystem)
- action items that don't seem to understand the organizational dysfunction 
that lead us to this series of misissuance events, and even for the minimal 
action items that exist, most are simply "tell Subscribers to do x" in more 
words 

In my opinion, evaluating the Entrust Report would only be possible given 
the following factors: 
- All delrev / failure to revokes are resolved satisfactorily (either via 
revocation or by an agreement by RPs that the certificates were indeed 
issued correctly, see 1890685)
- All questions asked in all open bugs are answered satisfactorily, with 
meaningful answers that take the question asker in good faith, rather than 
being combative and evasive
- A rewritten version of the report that A. acknowledges the missteps made 
in the submission of the report and the handling of the incident(s) and 
meta-incident around this, and B. answers the bullet points given by Ben W 
that should have been used as a framework to write the report, *including 
but not limited to* a thorough analysis and retrospective of the events of 
2020, and learnings that were documented then, and why they weren't applied 
now. 

With the report as it is though, while I'm just a bystander who has become 
very interested in WebPKI as of the past few months, I feel that there is a 
clear lack of understanding of the responsibilities and duties of a CA due 
to organizational dysfunction at best, and at worst malicious incompetence.


On Wednesday, June 12, 2024 at 9:05:53 PM UTC-7 Macy wrote:

> On Thursday, June 13, 2024 at 3:38:54 AM UTC+10 Ben Wilson wrote:
>
> All,
>
> So far, we have received substantive comments and questions on Entrust’s 
> June 7 Report from Amir, Wayne, and Watson.
>
> Are others planning to submit comments or to request clarification and 
> additional information from Entrust?
> Thanks,
>
> Ben
>
>
> Hi Ben,
>
> I just wanted to register my confusion and disappointment at Entrust's 
> report and general responsiveness to community concerns. You mentioned in 
> your original s

Re: Recent Entrust Compliance Incidents

[Macy]

On Thursday, June 13, 2024 at 3:38:54 AM UTC+10 Ben Wilson wrote:

All,

So far, we have received substantive comments and questions on Entrust’s 
June 7 Report from Amir, Wayne, and Watson.

Are others planning to submit comments or to request clarification and 
additional information from Entrust?
Thanks,

Ben


Hi Ben,

I just wanted to register my confusion and disappointment at Entrust's 
report and general responsiveness to community concerns. You mentioned in 
your original statement that "This is particularly disappointing in light 
of previous incidents in 2020 (#1651481 

 
and #1648472 
),
 
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 

 
in those bugs to address the root problems through process improvements, 
and it is concerning to see so little improvement 4 years later."

A thing that is notably missing from Entrust's report, given your explicit 
prompting, is any retroactive discussion of the events in 2020 or the 
changes they implemented in response to those incidents, or how those 
changes were insufficient to prevent these incidents. I haven't read every 
bugzilla comment so I may have missed other mentions, but in Bug #1890685 
comment 39 it 
appears that the changes Entrust internally identified 4 years ago related 
only to the adoption of automation, with nothing learned about the failures 
in their process or adherence to the BRs.

I find the report worrisome, because this shows that Entrust has not been 
and is still fundamentally not taking delayed (or failed) revocation as 
seriously as a WebPKI CA should.

To that end, some of the action items in 1901270 
 would strongly 
benefit from some explanation to the community as to what happened from the 
2020 commitment to today, specifically:

   - Implement formal incident response process including incident response 
   communication plan to meet mandatory reporting times 
   - Implement specific handling processes for internal as well as external 
   (CPR) reports 
   - Review verification process for all certificate types 
   - Create formal revocation event handling process 
   - Establish delayed revocation criteria 
   - Create revocation event communication plan

How did these seemingly get missed in 2020, and continue to be missed for 4 
years of operation, after making a commitment to always revoke certificates 
in accordance to the BRs? What was the process breakdown that led us to be 
here, watching a CA that predates the formalisation of the BRs just now 
committing to having a formal process for revocation events? What is the 
current process, how has it changed from 2020, and why is it still 
insufficient? What changes will be made to the process to ensure its 
sufficiency in the future? This is the bulk of what I expected to be 
reading in the report (and were explicitly requested in the prompt), but 
instead I saw the level of detail that should have been in the initial bugs 
with no acknowledgement or awareness of the overarching strategic failures 
that got them to this point.

In addition, I'm greatly troubled by the way that bug 1890685 
 was filed as a 
failure to revoke and treated that way by both Entrust and RPs for two 
months, only to have Entrust change interpretations and decide that there 
is no issue there. This entire bug was seemingly unaddressed by their 
report, and the timeline of the changed interpretation is confusing. Do 
other CAs share their understanding expressed in that bug that their CPSes' 
details don't matter if they say "unless the BRs override this"?

I have questions about the status of monitoring Bugzilla to learn from 
events from other CAs, but they're mooted if the CA isn't learning from its 
own incidents either.

I want to reiterate that the problem as I see it is not insufficient 
contrition, but rather insufficient self-awareness. I find it alarming that 
they are not showing recognition of the core problem here; namely, their 
continued retention of subscribers that they are willing to violate the BRs 
for and how that affects the trustwort

Re: Recent Entrust Compliance Incidents

['Ben Wilson' via dev-security-policy@mozilla.org]

;>>>>>>>> to renew your certificates probably every 60 days. Meaning that in 
>>>>>>>>>> the end, 
>>>>>>>>>> you have to replace your certificates four to six times a year, 
>>>>>>>>>> depending 
>>>>>>>>>> on what window you allow to renew that certificate.
>>>>>>>>>>
>>>>>>>>>> 90-day certificates will have a few benefits. So one is that they 
>>>>>>>>>> will drive automation.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2:51-3:30
>>>>>>>>>> That doesn't [mean to] say that there's no problems and that 
>>>>>>>>>> 90-day certificates are actually going to solve this. Crypto agility 
>>>>>>>>>> is 
>>>>>>>>>> important, but that means more than just automating your certificate 
>>>>>>>>>> lifecycle.
>>>>>>>>>>
>>>>>>>>>> For example, if the CA would give you an indication through the 
>>>>>>>>>> automated system that your certificate must be replaced, how does 
>>>>>>>>>> currently 
>>>>>>>>>> the CA know that your system is capable of running a certain 
>>>>>>>>>> algorithm? 
>>>>>>>>>> Have you updated your libraries?
>>>>>>>>>>
>>>>>>>>>> So we still have a long step ahead of us really to make that 
>>>>>>>>>> crypto agility a reality.
>>>>>>>>>>
>>>>>>>>>> 4:41-end
>>>>>>>>>>
>>>>>>>>>> We're working with the Internet Engineering Task Force, where 
>>>>>>>>>> Anthos(?) created a proposal for a sort of auto-discovery based on 
>>>>>>>>>> the most 
>>>>>>>>>> used automation, the ACME Auto Certificate Management Environment.
>>>>>>>>>>
>>>>>>>>>> And that would help our customers actually to simplify this 
>>>>>>>>>> mechanism of renewing certificates in different platforms with 
>>>>>>>>>> different 
>>>>>>>>>> systems, without having to reconfigure every individual system to 
>>>>>>>>>> work with 
>>>>>>>>>> the certificate authority and the type of certificates they're 
>>>>>>>>>> dealing 
>>>>>>>>>> with. Together with[sic] very important is one of the risks of 
>>>>>>>>>> automation, 
>>>>>>>>>> is that you're not doing it as a human. 
>>>>>>>>>>
>>>>>>>>>> If you do a process, if you follow a step-by-step process that is 
>>>>>>>>>> defined and tested, then you know the outcome, because you're 
>>>>>>>>>> following the 
>>>>>>>>>> steps. But in automation, something might go wrong. And how do you 
>>>>>>>>>> know? 
>>>>>>>>>> You need to make sure that systems are notifying you as someone is 
>>>>>>>>>> watching 
>>>>>>>>>> the notifications.
>>>>>>>>>>
>>>>>>>>>> That's also why in this similar proposal, we've included the 
>>>>>>>>>> mechanism of backup configuration. So if one process would fail, 
>>>>>>>>>> there is 
>>>>>>>>>> another process that can be followed. But other things are still in 
>>>>>>>>>> development. And we will see how that turns out. But the ecosystem 
>>>>>>>>>> seems to 
>>>>>>>>>> be supporting it.
>>>>>>>>>> *---*
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *4: 2023-07-26: Entrust Cybersecurity Institute Explains: Zero 
>>>>>>>>>> Trust and TLS/SSL Certificate Managemen

Re: Recent Entrust Compliance Incidents

['Ben Wilson' via dev-security-policy@mozilla.org]

ernet Engineering Task Force, where
>>>>>>>>> Anthos(?) created a proposal for a sort of auto-discovery based on 
>>>>>>>>> the most
>>>>>>>>> used automation, the ACME Auto Certificate Management Environment.
>>>>>>>>>
>>>>>>>>> And that would help our customers actually to simplify this
>>>>>>>>> mechanism of renewing certificates in different platforms with 
>>>>>>>>> different
>>>>>>>>> systems, without having to reconfigure every individual system to 
>>>>>>>>> work with
>>>>>>>>> the certificate authority and the type of certificates they're dealing
>>>>>>>>> with. Together with[sic] very important is one of the risks of 
>>>>>>>>> automation,
>>>>>>>>> is that you're not doing it as a human.
>>>>>>>>>
>>>>>>>>> If you do a process, if you follow a step-by-step process that is
>>>>>>>>> defined and tested, then you know the outcome, because you're 
>>>>>>>>> following the
>>>>>>>>> steps. But in automation, something might go wrong. And how do you 
>>>>>>>>> know?
>>>>>>>>> You need to make sure that systems are notifying you as someone is 
>>>>>>>>> watching
>>>>>>>>> the notifications.
>>>>>>>>>
>>>>>>>>> That's also why in this similar proposal, we've included the
>>>>>>>>> mechanism of backup configuration. So if one process would fail, 
>>>>>>>>> there is
>>>>>>>>> another process that can be followed. But other things are still in
>>>>>>>>> development. And we will see how that turns out. But the ecosystem 
>>>>>>>>> seems to
>>>>>>>>> be supporting it.
>>>>>>>>> *---*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *4: 2023-07-26: Entrust Cybersecurity Institute Explains: Zero
>>>>>>>>> Trust and TLS/SSL Certificate Management*
>>>>>>>>> https://www.youtube.com/watch?v=nd0QCvu2F_E
>>>>>>>>> *---*
>>>>>>>>> 1:20-2:18
>>>>>>>>>
>>>>>>>>> Well, first I would say we need to adopt automation. But then at
>>>>>>>>> the same point, I would point them at the risk of automation. Where
>>>>>>>>> processes by humans are easily manageable and can have multiple steps 
>>>>>>>>> to
>>>>>>>>> ensure they flow correctly. Without automation, this could be more
>>>>>>>>> challenging.
>>>>>>>>>
>>>>>>>>> For example, if you implement automation for your TLS
>>>>>>>>> certificates, this means that you need to have a credential for your
>>>>>>>>> certificate authority. You need to also have a credential, for 
>>>>>>>>> example, for
>>>>>>>>> your domain name provider, your DNS system. And that's all needed to 
>>>>>>>>> prove
>>>>>>>>> domain control and to make sure that a certificate with the right 
>>>>>>>>> identity
>>>>>>>>> is issued for your endpoints.
>>>>>>>>>
>>>>>>>>> But what if these credentials get compromised? Look at the DNS
>>>>>>>>> system.
>>>>>>>>> *---*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *5: 2023-08-14: Short-lived Certificates finally approved*
>>>>>>>>>
>>>>>>>>> https://www.entrust.com/blog/2023/08/short-lived-certificates-finally-approved/
>>>>>>>>> *---*
>>>>>>>>> After more than 10 years, short-lived TLS certificates are finally
>>>>>>>>> permitted by the browsers based on CA/Browser Forum ballot SC-063. 
>>>>>

Re: Recent Entrust Compliance Incidents

[Mike Shaver]

;> watching
>>>>>>>> the notifications.
>>>>>>>>
>>>>>>>> That's also why in this similar proposal, we've included the
>>>>>>>> mechanism of backup configuration. So if one process would fail, there 
>>>>>>>> is
>>>>>>>> another process that can be followed. But other things are still in
>>>>>>>> development. And we will see how that turns out. But the ecosystem 
>>>>>>>> seems to
>>>>>>>> be supporting it.
>>>>>>>> *---*
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *4: 2023-07-26: Entrust Cybersecurity Institute Explains: Zero
>>>>>>>> Trust and TLS/SSL Certificate Management*
>>>>>>>> https://www.youtube.com/watch?v=nd0QCvu2F_E
>>>>>>>> *---*
>>>>>>>> 1:20-2:18
>>>>>>>>
>>>>>>>> Well, first I would say we need to adopt automation. But then at
>>>>>>>> the same point, I would point them at the risk of automation. Where
>>>>>>>> processes by humans are easily manageable and can have multiple steps 
>>>>>>>> to
>>>>>>>> ensure they flow correctly. Without automation, this could be more
>>>>>>>> challenging.
>>>>>>>>
>>>>>>>> For example, if you implement automation for your TLS certificates,
>>>>>>>> this means that you need to have a credential for your certificate
>>>>>>>> authority. You need to also have a credential, for example, for your 
>>>>>>>> domain
>>>>>>>> name provider, your DNS system. And that's all needed to prove domain
>>>>>>>> control and to make sure that a certificate with the right identity is
>>>>>>>> issued for your endpoints.
>>>>>>>>
>>>>>>>> But what if these credentials get compromised? Look at the DNS
>>>>>>>> system.
>>>>>>>> *---*
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *5: 2023-08-14: Short-lived Certificates finally approved*
>>>>>>>>
>>>>>>>> https://www.entrust.com/blog/2023/08/short-lived-certificates-finally-approved/
>>>>>>>> *---*
>>>>>>>> After more than 10 years, short-lived TLS certificates are finally
>>>>>>>> permitted by the browsers based on CA/Browser Forum ballot SC-063. Gerv
>>>>>>>> Markham started a short-lived certs discussion in 2014, where he 
>>>>>>>> advised he
>>>>>>>> was reviewing the 2012 CA/Browser Forum discussion on the topic. He 
>>>>>>>> advised
>>>>>>>> that short-lived certificates was a plank of the Mozilla revocation
>>>>>>>> strategy. There was also a paper prepared in 2012 called Towards
>>>>>>>> Short-Lived Certificates. The paper stated OCSP is as good as dead, so 
>>>>>>>> the
>>>>>>>> CAs should issue certificates with a very short lifetime. I suppose no 
>>>>>>>> one
>>>>>>>> thought it would take so much time.
>>>>>>>>
>>>>>>>> Short-lived certificates are designed to help address a certificate
>>>>>>>> revocation issue. Back in 2012, Adam Langley discussed the seat-belt 
>>>>>>>> issue,
>>>>>>>> where it works fine, but snaps when you crash. This was based on the 
>>>>>>>> fact
>>>>>>>> the browser implements soft-fail revocation checks where the CRL or 
>>>>>>>> OCSP
>>>>>>>> response is ignored.
>>>>>>>> *---*
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *6: 2024-03-26: The Path to 90-Day Certificate Validity: Challenges
>>>>>>>> Facing Organizations*
>>>>>>>>
>>>>>>>> https://www.entrust.com/blog/2024/03/the-path-to-90-day-certificate-validity-challenges-facing-organizations/
>>>

Re: Recent Entrust Compliance Incidents

['Ben Wilson' via dev-security-policy@mozilla.org]

gt;>>>> they
>>>>>>> flow correctly. Without automation, this could be more challenging.
>>>>>>>
>>>>>>> For example, if you implement automation for your TLS certificates,
>>>>>>> this means that you need to have a credential for your certificate
>>>>>>> authority. You need to also have a credential, for example, for your 
>>>>>>> domain
>>>>>>> name provider, your DNS system. And that's all needed to prove domain
>>>>>>> control and to make sure that a certificate with the right identity is
>>>>>>> issued for your endpoints.
>>>>>>>
>>>>>>> But what if these credentials get compromised? Look at the DNS
>>>>>>> system.
>>>>>>> *---*
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *5: 2023-08-14: Short-lived Certificates finally approved*
>>>>>>>
>>>>>>> https://www.entrust.com/blog/2023/08/short-lived-certificates-finally-approved/
>>>>>>> *---*
>>>>>>> After more than 10 years, short-lived TLS certificates are finally
>>>>>>> permitted by the browsers based on CA/Browser Forum ballot SC-063. Gerv
>>>>>>> Markham started a short-lived certs discussion in 2014, where he 
>>>>>>> advised he
>>>>>>> was reviewing the 2012 CA/Browser Forum discussion on the topic. He 
>>>>>>> advised
>>>>>>> that short-lived certificates was a plank of the Mozilla revocation
>>>>>>> strategy. There was also a paper prepared in 2012 called Towards
>>>>>>> Short-Lived Certificates. The paper stated OCSP is as good as dead, so 
>>>>>>> the
>>>>>>> CAs should issue certificates with a very short lifetime. I suppose no 
>>>>>>> one
>>>>>>> thought it would take so much time.
>>>>>>>
>>>>>>> Short-lived certificates are designed to help address a certificate
>>>>>>> revocation issue. Back in 2012, Adam Langley discussed the seat-belt 
>>>>>>> issue,
>>>>>>> where it works fine, but snaps when you crash. This was based on the 
>>>>>>> fact
>>>>>>> the browser implements soft-fail revocation checks where the CRL or OCSP
>>>>>>> response is ignored.
>>>>>>> *---*
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *6: 2024-03-26: The Path to 90-Day Certificate Validity: Challenges
>>>>>>> Facing Organizations*
>>>>>>>
>>>>>>> https://www.entrust.com/blog/2024/03/the-path-to-90-day-certificate-validity-challenges-facing-organizations/
>>>>>>> *---*
>>>>>>> Certificate lifespan is getting shorter
>>>>>>>
>>>>>>> Over the years the cybersecurity industry has undergone notable
>>>>>>> transformations requiring organizations to implement new best-practice
>>>>>>> standards, often at a short notice.
>>>>>>>
>>>>>>> In 2020, Apple unilaterally opted for shorter TLS certificate
>>>>>>> durations, reducing them from three years to 398 days, thereby 
>>>>>>> increasing
>>>>>>> the burden on certificate management. Subsequently, Apple introduced
>>>>>>> shorter lifespans for S/MIME certificates at the start of 2022. In the 
>>>>>>> past
>>>>>>> year, both code signing and S/MIME users faced additional alterations,
>>>>>>> while Google proposed transitioning to 90-day certificates, a subject we
>>>>>>> have explored in our latest webinar. Anticipating further changes,
>>>>>>> particularly with the rise of artificial intelligence (AI) and the 
>>>>>>> looming
>>>>>>> risk of post-quantum (PQ) computing, organizations must enhance their
>>>>>>> agility.
>>>>>>>
>>>>>>> Today, TLS/SSL certificates are typically valid for about a year,
>>>>>>> according to the Certification Authority Browser (CA/B) Forum 
>>>>>>> requirements.
>>>>>>> This yearly 

Re: Recent Entrust Compliance Incidents

[Mike Shaver]

till have a long step ahead of us really to make that crypto
>>>>>> agility a reality.
>>>>>>
>>>>>> 4:41-end
>>>>>>
>>>>>> We're working with the Internet Engineering Task Force, where
>>>>>> Anthos(?) created a proposal for a sort of auto-discovery based on the 
>>>>>> most
>>>>>> used automation, the ACME Auto Certificate Management Environment.
>>>>>>
>>>>>> And that would help our customers actually to simplify this mechanism
>>>>>> of renewing certificates in different platforms with different systems,
>>>>>> without having to reconfigure every individual system to work with the
>>>>>> certificate authority and the type of certificates they're dealing with.
>>>>>> Together with[sic] very important is one of the risks of automation, is
>>>>>> that you're not doing it as a human.
>>>>>>
>>>>>> If you do a process, if you follow a step-by-step process that is
>>>>>> defined and tested, then you know the outcome, because you're following 
>>>>>> the
>>>>>> steps. But in automation, something might go wrong. And how do you know?
>>>>>> You need to make sure that systems are notifying you as someone is 
>>>>>> watching
>>>>>> the notifications.
>>>>>>
>>>>>> That's also why in this similar proposal, we've included the
>>>>>> mechanism of backup configuration. So if one process would fail, there is
>>>>>> another process that can be followed. But other things are still in
>>>>>> development. And we will see how that turns out. But the ecosystem seems 
>>>>>> to
>>>>>> be supporting it.
>>>>>> *---*
>>>>>>
>>>>>>
>>>>>>
>>>>>> *4: 2023-07-26: Entrust Cybersecurity Institute Explains: Zero Trust
>>>>>> and TLS/SSL Certificate Management*
>>>>>> https://www.youtube.com/watch?v=nd0QCvu2F_E
>>>>>> *---*
>>>>>> 1:20-2:18
>>>>>>
>>>>>> Well, first I would say we need to adopt automation. But then at the
>>>>>> same point, I would point them at the risk of automation. Where processes
>>>>>> by humans are easily manageable and can have multiple steps to ensure 
>>>>>> they
>>>>>> flow correctly. Without automation, this could be more challenging.
>>>>>>
>>>>>> For example, if you implement automation for your TLS certificates,
>>>>>> this means that you need to have a credential for your certificate
>>>>>> authority. You need to also have a credential, for example, for your 
>>>>>> domain
>>>>>> name provider, your DNS system. And that's all needed to prove domain
>>>>>> control and to make sure that a certificate with the right identity is
>>>>>> issued for your endpoints.
>>>>>>
>>>>>> But what if these credentials get compromised? Look at the DNS system.
>>>>>> *---*
>>>>>>
>>>>>>
>>>>>>
>>>>>> *5: 2023-08-14: Short-lived Certificates finally approved*
>>>>>>
>>>>>> https://www.entrust.com/blog/2023/08/short-lived-certificates-finally-approved/
>>>>>> *---*
>>>>>> After more than 10 years, short-lived TLS certificates are finally
>>>>>> permitted by the browsers based on CA/Browser Forum ballot SC-063. Gerv
>>>>>> Markham started a short-lived certs discussion in 2014, where he advised 
>>>>>> he
>>>>>> was reviewing the 2012 CA/Browser Forum discussion on the topic. He 
>>>>>> advised
>>>>>> that short-lived certificates was a plank of the Mozilla revocation
>>>>>> strategy. There was also a paper prepared in 2012 called Towards
>>>>>> Short-Lived Certificates. The paper stated OCSP is as good as dead, so 
>>>>>> the
>>>>>> CAs should issue certificates with a very short lifetime. I suppose no 
>>>>>> one
>>>>>> thought it would take so much time.
>>>>>>
>>>>>> Short-lived certificat

Re: Recent Entrust Compliance Incidents

['Ben Wilson' via dev-security-policy@mozilla.org]

uded the mechanism
>>>>> of backup configuration. So if one process would fail, there is another
>>>>> process that can be followed. But other things are still in development.
>>>>> And we will see how that turns out. But the ecosystem seems to be
>>>>> supporting it.
>>>>> *---*
>>>>>
>>>>>
>>>>>
>>>>> *4: 2023-07-26: Entrust Cybersecurity Institute Explains: Zero Trust
>>>>> and TLS/SSL Certificate Management*
>>>>> https://www.youtube.com/watch?v=nd0QCvu2F_E
>>>>> *---*
>>>>> 1:20-2:18
>>>>>
>>>>> Well, first I would say we need to adopt automation. But then at the
>>>>> same point, I would point them at the risk of automation. Where processes
>>>>> by humans are easily manageable and can have multiple steps to ensure they
>>>>> flow correctly. Without automation, this could be more challenging.
>>>>>
>>>>> For example, if you implement automation for your TLS certificates,
>>>>> this means that you need to have a credential for your certificate
>>>>> authority. You need to also have a credential, for example, for your 
>>>>> domain
>>>>> name provider, your DNS system. And that's all needed to prove domain
>>>>> control and to make sure that a certificate with the right identity is
>>>>> issued for your endpoints.
>>>>>
>>>>> But what if these credentials get compromised? Look at the DNS system.
>>>>> *---*
>>>>>
>>>>>
>>>>>
>>>>> *5: 2023-08-14: Short-lived Certificates finally approved*
>>>>>
>>>>> https://www.entrust.com/blog/2023/08/short-lived-certificates-finally-approved/
>>>>> *---*
>>>>> After more than 10 years, short-lived TLS certificates are finally
>>>>> permitted by the browsers based on CA/Browser Forum ballot SC-063. Gerv
>>>>> Markham started a short-lived certs discussion in 2014, where he advised 
>>>>> he
>>>>> was reviewing the 2012 CA/Browser Forum discussion on the topic. He 
>>>>> advised
>>>>> that short-lived certificates was a plank of the Mozilla revocation
>>>>> strategy. There was also a paper prepared in 2012 called Towards
>>>>> Short-Lived Certificates. The paper stated OCSP is as good as dead, so the
>>>>> CAs should issue certificates with a very short lifetime. I suppose no one
>>>>> thought it would take so much time.
>>>>>
>>>>> Short-lived certificates are designed to help address a certificate
>>>>> revocation issue. Back in 2012, Adam Langley discussed the seat-belt 
>>>>> issue,
>>>>> where it works fine, but snaps when you crash. This was based on the fact
>>>>> the browser implements soft-fail revocation checks where the CRL or OCSP
>>>>> response is ignored.
>>>>> *---*
>>>>>
>>>>>
>>>>>
>>>>> *6: 2024-03-26: The Path to 90-Day Certificate Validity: Challenges
>>>>> Facing Organizations*
>>>>>
>>>>> https://www.entrust.com/blog/2024/03/the-path-to-90-day-certificate-validity-challenges-facing-organizations/
>>>>> *---*
>>>>> Certificate lifespan is getting shorter
>>>>>
>>>>> Over the years the cybersecurity industry has undergone notable
>>>>> transformations requiring organizations to implement new best-practice
>>>>> standards, often at a short notice.
>>>>>
>>>>> In 2020, Apple unilaterally opted for shorter TLS certificate
>>>>> durations, reducing them from three years to 398 days, thereby increasing
>>>>> the burden on certificate management. Subsequently, Apple introduced
>>>>> shorter lifespans for S/MIME certificates at the start of 2022. In the 
>>>>> past
>>>>> year, both code signing and S/MIME users faced additional alterations,
>>>>> while Google proposed transitioning to 90-day certificates, a subject we
>>>>> have explored in our latest webinar. Anticipating further changes,
>>>>> particularly with the rise of artificial intelligence (AI) and the looming
>>>>> risk of post-quantum (PQ) computing, organizations must enhance their
>>>>> agility.
&

Re: Recent Entrust Compliance Incidents

[Tyrel]

gt;>>>> that you're not doing it as a human. 
>>>>>
>>>>> If you do a process, if you follow a step-by-step process that is 
>>>>> defined and tested, then you know the outcome, because you're following 
>>>>> the 
>>>>> steps. But in automation, something might go wrong. And how do you know? 
>>>>> You need to make sure that systems are notifying you as someone is 
>>>>> watching 
>>>>> the notifications.
>>>>>
>>>>> That's also why in this similar proposal, we've included the mechanism 
>>>>> of backup configuration. So if one process would fail, there is another 
>>>>> process that can be followed. But other things are still in development. 
>>>>> And we will see how that turns out. But the ecosystem seems to be 
>>>>> supporting it.
>>>>> *---*
>>>>>
>>>>>
>>>>>
>>>>> *4: 2023-07-26: Entrust Cybersecurity Institute Explains: Zero Trust 
>>>>> and TLS/SSL Certificate Management*
>>>>> https://www.youtube.com/watch?v=nd0QCvu2F_E
>>>>> *---*
>>>>> 1:20-2:18
>>>>>
>>>>> Well, first I would say we need to adopt automation. But then at the 
>>>>> same point, I would point them at the risk of automation. Where processes 
>>>>> by humans are easily manageable and can have multiple steps to ensure 
>>>>> they 
>>>>> flow correctly. Without automation, this could be more challenging.
>>>>>
>>>>> For example, if you implement automation for your TLS certificates, 
>>>>> this means that you need to have a credential for your certificate 
>>>>> authority. You need to also have a credential, for example, for your 
>>>>> domain 
>>>>> name provider, your DNS system. And that's all needed to prove domain 
>>>>> control and to make sure that a certificate with the right identity is 
>>>>> issued for your endpoints.
>>>>>
>>>>> But what if these credentials get compromised? Look at the DNS system.
>>>>> *---*
>>>>>
>>>>>
>>>>>
>>>>> *5: 2023-08-14: Short-lived Certificates finally approved*
>>>>>
>>>>> https://www.entrust.com/blog/2023/08/short-lived-certificates-finally-approved/
>>>>> *---*
>>>>> After more than 10 years, short-lived TLS certificates are finally 
>>>>> permitted by the browsers based on CA/Browser Forum ballot SC-063. Gerv 
>>>>> Markham started a short-lived certs discussion in 2014, where he advised 
>>>>> he 
>>>>> was reviewing the 2012 CA/Browser Forum discussion on the topic. He 
>>>>> advised 
>>>>> that short-lived certificates was a plank of the Mozilla revocation 
>>>>> strategy. There was also a paper prepared in 2012 called Towards 
>>>>> Short-Lived Certificates. The paper stated OCSP is as good as dead, so 
>>>>> the 
>>>>> CAs should issue certificates with a very short lifetime. I suppose no 
>>>>> one 
>>>>> thought it would take so much time.
>>>>>
>>>>> Short-lived certificates are designed to help address a certificate 
>>>>> revocation issue. Back in 2012, Adam Langley discussed the seat-belt 
>>>>> issue, 
>>>>> where it works fine, but snaps when you crash. This was based on the fact 
>>>>> the browser implements soft-fail revocation checks where the CRL or OCSP 
>>>>> response is ignored.
>>>>> *---*
>>>>>
>>>>>
>>>>>
>>>>> *6: 2024-03-26: The Path to 90-Day Certificate Validity: Challenges 
>>>>> Facing Organizations*
>>>>>
>>>>> https://www.entrust.com/blog/2024/03/the-path-to-90-day-certificate-validity-challenges-facing-organizations/
>>>>> *---*
>>>>> Certificate lifespan is getting shorter
>>>>>
>>>>> Over the years the cybersecurity industry has undergone notable 
>>>>> transformations requiring organizations to implement new best-practice 
>>>>> standards, often at a short notice.
>>>>>
>>>>> In 2020, Apple unilaterally opted for shorter TLS certificate 
>>>>> durations, reducing them from three years 

Re: Financial incentive against security ( was Re: [EXTERNAL] Recent Entrust Compliance Incidents)

[Mike Shaver]

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)

[Mike Shaver]

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)

[Mike Shaver]

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)

[Jeffrey Walton]

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)

[Mike Shaver]

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)

[Mike Shaver]

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)

[Watson Ladd]

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

[Mike Shaver]

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: Recent Entrust Compliance Incidents

[Wayne]

While Entrust have not provided details on their incident handling and 
decision-making as requested in this report, a few details have came to 
light in a reply to an incident today. This is specifically regarding 
#1886532 the delayed revocation CPSuri certificates.

https://bugzilla.mozilla.org/show_bug.cgi?id=1886532#c51

I will do this mailing a list a courtesy by not embedding it all, however I 
feel that similar details not being included for all of these incidents in 
this report already is troublesome. This comment shows that Entrust has all 
of this information available, they just did not feel it worth including 
despite it being asked for.
On Friday, June 7, 2024 at 11:42:34 PM UTC+1 Watson Ladd wrote:

> Dear Bruce,
>
> This report is completely unsatisfactory. It starts by presuming that
> the problem is 4 incidents. Entrust is always under an obligation to
> explain the root causes of incidents and what it is doing to avoid
> them as per the CCADB incident report guidelines. That's not the
> reason Ben and the community need this report. Rather it's to go
> beyond the incident report to draw broader lessons and to say more to
> help us judge Entrust's continued ability to stay in the root store.
> The report falls short of what was asked for, in a way that makes me
> suspect that Entrust is organizationally incapable of reading a
> document, understanding it, and ensuring each of the clearly worded
> requests is followed. The implications for being a CA are obvious.
>
> To start Ben specifically asked for an analysis involving the
> historical run of issues and a comparison. I don't see that in this
> report, at all. The list of incidents only has ones from 2024 listed,
> there's no discussion of the two issues specifically listed by Ben in
> his email.
>
> Secondly the remedial actions seem to be largely copy pasted from
> incident to incident without a lot of explanation. Saying the
> organizational structure will be changed to enhance support,
> governance and resourcing really doesn't leave us with a lot of
> ability to judge success or explain how the changes made (sparse on
> details) will lead to improvements. Similarly process weaknesses are
> not really discussed in ways that make clear what happened. How can I
> use this report if I was a different CA to examine my organization and
> see if I can do better? How can we as a community judge the adequacy
> of the remedial actions in this report?
>
> Section 2.4 I find mystifying. To my mind there's no inherent
> connection between a failure to update public information in a place
> it appears, a delay in reconfiguring a responder, and a bug in the CRL
> generation process beyond the organizational. These are three separate
> functions of rather different complexity. If there's a similarity it's
> between the latter two issues where there was a failure to notice a
> change in requirements that required action, but that's not what the
> report says! Why were these three grouped together, and not others?
> What's the common failure here that doesn't exist with the other
> incidents?
>
> If this is the best Entrust can do, why should we expect Entrust to be
> worthy of inclusion in the future? To be clear, there are CAs that
> have come back from profound failures of governance and judgement. But
> the first step in that process has been a full and honest accounting
> of what their failures have been, in a way that has helped others
> understand where the risks are and helps the community understand why
> they are trustworthy.
>
> 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/e374c341-8de4-4be3-9e5c-89a8feab1aadn%40mozilla.org.

Re: Recent Entrust Compliance Incidents

[Watson Ladd]

Dear Bruce,

This report is completely unsatisfactory. It starts by presuming that
the problem is 4 incidents. Entrust is always under an obligation to
explain the root causes of incidents and what it is doing to avoid
them as per the CCADB incident report guidelines. That's not the
reason Ben and the community need this report. Rather it's to go
beyond the incident report to draw broader lessons and to say more to
help us judge Entrust's continued ability to stay in the root store.
The report falls short of what was asked for, in a way that makes me
suspect that Entrust is organizationally incapable of reading a
document, understanding it, and ensuring each of the clearly worded
requests is followed. The implications for being a CA are obvious.

To start Ben specifically asked for an analysis involving the
historical run of issues and a comparison. I don't see that in this
report, at all.  The list of incidents only has ones from 2024 listed,
there's no discussion of the two issues specifically listed by Ben in
his email.

Secondly the remedial actions seem to be largely copy pasted from
incident to incident without a lot of explanation. Saying the
organizational structure will be changed to enhance support,
governance and resourcing really doesn't leave us with a lot of
ability to judge success or explain how the changes made (sparse on
details) will lead to improvements. Similarly process weaknesses are
not really discussed in ways that make clear what happened. How can I
use this report if I was a different CA to examine my organization and
see if I can do better? How can we as a community judge the adequacy
of the remedial actions in this report?

Section 2.4 I find mystifying. To my mind there's no inherent
connection between a failure to update public information in a place
it appears, a delay in reconfiguring a responder, and a bug in the CRL
generation process beyond the organizational. These are three separate
functions of rather different complexity. If there's a similarity it's
between the latter two issues where there was a failure to notice a
change in requirements that required action, but that's not what the
report says! Why were these three grouped together, and not others?
What's the common failure here that doesn't exist with the other
incidents?

If this is the best Entrust can do, why should we expect Entrust to be
worthy of inclusion in the future? To be clear, there are CAs that
have come back from profound failures of governance and judgement. But
the first step in that process has been a full and honest accounting
of what their failures have been, in a way that has helped others
understand where the risks are and helps the community understand why
they are trustworthy.

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/CACsn0ckZYa-Ycz0XFMpJNp7ECih5Ghy_3wbDC_H26CQLW3Asyw%40mail.gmail.com.

Re: Recent Entrust Compliance Incidents

[Wayne]

: 2023-08-14: Short-lived Certificates finally approved*
>>>>>
>>>>> https://www.entrust.com/blog/2023/08/short-lived-certificates-finally-approved/
>>>>> *---*
>>>>> After more than 10 years, short-lived TLS certificates are finally 
>>>>> permitted by the browsers based on CA/Browser Forum ballot SC-063. Gerv 
>>>>> Markham started a short-lived certs discussion in 2014, where he advised 
>>>>> he 
>>>>> was reviewing the 2012 CA/Browser Forum discussion on the topic. He 
>>>>> advised 
>>>>> that short-lived certificates was a plank of the Mozilla revocation 
>>>>> strategy. There was also a paper prepared in 2012 called Towards 
>>>>> Short-Lived Certificates. The paper stated OCSP is as good as dead, so 
>>>>> the 
>>>>> CAs should issue certificates with a very short lifetime. I suppose no 
>>>>> one 
>>>>> thought it would take so much time.
>>>>>
>>>>> Short-lived certificates are designed to help address a certificate 
>>>>> revocation issue. Back in 2012, Adam Langley discussed the seat-belt 
>>>>> issue, 
>>>>> where it works fine, but snaps when you crash. This was based on the fact 
>>>>> the browser implements soft-fail revocation checks where the CRL or OCSP 
>>>>> response is ignored.
>>>>> *---*
>>>>>
>>>>>
>>>>>
>>>>> *6: 2024-03-26: The Path to 90-Day Certificate Validity: Challenges 
>>>>> Facing Organizations*
>>>>>
>>>>> https://www.entrust.com/blog/2024/03/the-path-to-90-day-certificate-validity-challenges-facing-organizations/
>>>>> *---*
>>>>> Certificate lifespan is getting shorter
>>>>>
>>>>> Over the years the cybersecurity industry has undergone notable 
>>>>> transformations requiring organizations to implement new best-practice 
>>>>> standards, often at a short notice.
>>>>>
>>>>> In 2020, Apple unilaterally opted for shorter TLS certificate 
>>>>> durations, reducing them from three years to 398 days, thereby increasing 
>>>>> the burden on certificate management. Subsequently, Apple introduced 
>>>>> shorter lifespans for S/MIME certificates at the start of 2022. In the 
>>>>> past 
>>>>> year, both code signing and S/MIME users faced additional alterations, 
>>>>> while Google proposed transitioning to 90-day certificates, a subject we 
>>>>> have explored in our latest webinar. Anticipating further changes, 
>>>>> particularly with the rise of artificial intelligence (AI) and the 
>>>>> looming 
>>>>> risk of post-quantum (PQ) computing, organizations must enhance their 
>>>>> agility.
>>>>>
>>>>> Today, TLS/SSL certificates are typically valid for about a year, 
>>>>> according to the Certification Authority Browser (CA/B) Forum 
>>>>> requirements. 
>>>>> This yearly renewal cycle is convenient for organizations to manage and 
>>>>> schedule. However, transitioning to shorter-lived certificates, like the 
>>>>> proposed 90-day validity period, will require more frequent renewal 
>>>>> efforts. With 90-day validity, organizations will need to renew 
>>>>> certificates four times every 12 months within that timeframe. In 
>>>>> practice, 
>>>>> due to the need for buffer time, certificates may need to be renewed 
>>>>> every 
>>>>> 60 days. Ultimately, this change could lead to replacing certificates 
>>>>> more 
>>>>> than six times every 12 months, depending on the renewal window chosen.
>>>>> *---*
>>>>>
>>>>> Apologies that some of those got long, I wanted to preserve as much 
>>>>> context as possible given how little material we have to work with.
>>>>>
>>>>> I sincerely ask anyone if they can find any further communication on 
>>>>> these topics by Entrust. Their helpdesk has tutorials on specific 
>>>>> software 
>>>>> setups, but I'm not seeing any actual push for their subscribers to do 
>>>>> anything.
>>>>>
>>>>> It would be very beneficial for Entrust to provide us with any 
>>>>> information on what t

Re: Recent Entrust Compliance Incidents

['Amir Omidi (aaomidi)' via dev-security-policy@mozilla.org]

>>>>> permitted by the browsers based on CA/Browser Forum ballot SC-063. Gerv 
>>>>> Markham started a short-lived certs discussion in 2014, where he advised 
>>>>> he 
>>>>> was reviewing the 2012 CA/Browser Forum discussion on the topic. He 
>>>>> advised 
>>>>> that short-lived certificates was a plank of the Mozilla revocation 
>>>>> strategy. There was also a paper prepared in 2012 called Towards 
>>>>> Short-Lived Certificates. The paper stated OCSP is as good as dead, so 
>>>>> the 
>>>>> CAs should issue certificates with a very short lifetime. I suppose no 
>>>>> one 
>>>>> thought it would take so much time.
>>>>>
>>>>> Short-lived certificates are designed to help address a certificate 
>>>>> revocation issue. Back in 2012, Adam Langley discussed the seat-belt 
>>>>> issue, 
>>>>> where it works fine, but snaps when you crash. This was based on the fact 
>>>>> the browser implements soft-fail revocation checks where the CRL or OCSP 
>>>>> response is ignored.
>>>>> *---*
>>>>>
>>>>>
>>>>>
>>>>> *6: 2024-03-26: The Path to 90-Day Certificate Validity: Challenges 
>>>>> Facing Organizations*
>>>>>
>>>>> https://www.entrust.com/blog/2024/03/the-path-to-90-day-certificate-validity-challenges-facing-organizations/
>>>>> *---*
>>>>> Certificate lifespan is getting shorter
>>>>>
>>>>> Over the years the cybersecurity industry has undergone notable 
>>>>> transformations requiring organizations to implement new best-practice 
>>>>> standards, often at a short notice.
>>>>>
>>>>> In 2020, Apple unilaterally opted for shorter TLS certificate 
>>>>> durations, reducing them from three years to 398 days, thereby increasing 
>>>>> the burden on certificate management. Subsequently, Apple introduced 
>>>>> shorter lifespans for S/MIME certificates at the start of 2022. In the 
>>>>> past 
>>>>> year, both code signing and S/MIME users faced additional alterations, 
>>>>> while Google proposed transitioning to 90-day certificates, a subject we 
>>>>> have explored in our latest webinar. Anticipating further changes, 
>>>>> particularly with the rise of artificial intelligence (AI) and the 
>>>>> looming 
>>>>> risk of post-quantum (PQ) computing, organizations must enhance their 
>>>>> agility.
>>>>>
>>>>> Today, TLS/SSL certificates are typically valid for about a year, 
>>>>> according to the Certification Authority Browser (CA/B) Forum 
>>>>> requirements. 
>>>>> This yearly renewal cycle is convenient for organizations to manage and 
>>>>> schedule. However, transitioning to shorter-lived certificates, like the 
>>>>> proposed 90-day validity period, will require more frequent renewal 
>>>>> efforts. With 90-day validity, organizations will need to renew 
>>>>> certificates four times every 12 months within that timeframe. In 
>>>>> practice, 
>>>>> due to the need for buffer time, certificates may need to be renewed 
>>>>> every 
>>>>> 60 days. Ultimately, this change could lead to replacing certificates 
>>>>> more 
>>>>> than six times every 12 months, depending on the renewal window chosen.
>>>>> *---*
>>>>>
>>>>> Apologies that some of those got long, I wanted to preserve as much 
>>>>> context as possible given how little material we have to work with.
>>>>>
>>>>> I sincerely ask anyone if they can find any further communication on 
>>>>> these topics by Entrust. Their helpdesk has tutorials on specific 
>>>>> software 
>>>>> setups, but I'm not seeing any actual push for their subscribers to do 
>>>>> anything.
>>>>>
>>>>> It would be very beneficial for Entrust to provide us with any 
>>>>> information on what they've been communicating to their customers to 
>>>>> promote shorter certificate lifespans and automation.
>>>>>
>>>>> - Wayne
>>>>>
>>>>> On Saturday, May 11, 2024 at 8:04:24 PM UTC+1 Chris Bailey wrote:
>>>>>

Re: Recent Entrust Compliance Incidents

['Ben Wilson' via dev-security-policy@mozilla.org]

gt;>
>>> Over the years the cybersecurity industry has undergone notable 
>>> transformations requiring organizations to implement new best-practice 
>>> standards, often at a short notice.
>>>
>>> In 2020, Apple unilaterally opted for shorter TLS certificate durations, 
>>> reducing them from three years to 398 days, thereby increasing the burden 
>>> on certificate management. Subsequently, Apple introduced shorter lifespans 
>>> for S/MIME certificates at the start of 2022. In the past year, both code 
>>> signing and S/MIME users faced additional alterations, while Google 
>>> proposed transitioning to 90-day certificates, a subject we have explored 
>>> in our latest webinar. Anticipating further changes, particularly with the 
>>> rise of artificial intelligence (AI) and the looming risk of post-quantum 
>>> (PQ) computing, organizations must enhance their agility.
>>>
>>> Today, TLS/SSL certificates are typically valid for about a year, 
>>> according to the Certification Authority Browser (CA/B) Forum requirements. 
>>> This yearly renewal cycle is convenient for organizations to manage and 
>>> schedule. However, transitioning to shorter-lived certificates, like the 
>>> proposed 90-day validity period, will require more frequent renewal 
>>> efforts. With 90-day validity, organizations will need to renew 
>>> certificates four times every 12 months within that timeframe. In practice, 
>>> due to the need for buffer time, certificates may need to be renewed every 
>>> 60 days. Ultimately, this change could lead to replacing certificates more 
>>> than six times every 12 months, depending on the renewal window chosen.
>>> *---*
>>>
>>> Apologies that some of those got long, I wanted to preserve as much 
>>> context as possible given how little material we have to work with.
>>>
>>> I sincerely ask anyone if they can find any further communication on 
>>> these topics by Entrust. Their helpdesk has tutorials on specific software 
>>> setups, but I'm not seeing any actual push for their subscribers to do 
>>> anything.
>>>
>>> It would be very beneficial for Entrust to provide us with any 
>>> information on what they've been communicating to their customers to 
>>> promote shorter certificate lifespans and automation.
>>>
>>> - Wayne
>>>
>>> On Saturday, May 11, 2024 at 8:04:24 PM UTC+1 Chris Bailey wrote:
>>>
>>>> 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-secur...@mozilla.org <
>>>> dev-secur...@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 

Re: Recent Entrust Compliance Incidents

[Wayne]

s will need to renew 
>> certificates four times every 12 months within that timeframe. In practice, 
>> due to the need for buffer time, certificates may need to be renewed every 
>> 60 days. Ultimately, this change could lead to replacing certificates more 
>> than six times every 12 months, depending on the renewal window chosen.
>> *---*
>>
>> Apologies that some of those got long, I wanted to preserve as much 
>> context as possible given how little material we have to work with.
>>
>> I sincerely ask anyone if they can find any further communication on 
>> these topics by Entrust. Their helpdesk has tutorials on specific software 
>> setups, but I'm not seeing any actual push for their subscribers to do 
>> anything.
>>
>> It would be very beneficial for Entrust to provide us with any 
>> information on what they've been communicating to their customers to 
>> promote shorter certificate lifespans and automation.
>>
>> - Wayne
>>
>> On Saturday, May 11, 2024 at 8:04:24 PM UTC+1 Chris Bailey wrote:
>>
>>> 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-secur...@mozilla.org <
>>> dev-secur...@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 

Re: Recent Entrust Compliance Incidents

['Amir Omidi (aaomidi)' via dev-security-policy@mozilla.org]

utomation. Where processes by 
> humans are easily manageable and can have multiple steps to ensure they 
> flow correctly. Without automation, this could be more challenging.
>
> For example, if you implement automation for your TLS certificates, this 
> means that you need to have a credential for your certificate authority. 
> You need to also have a credential, for example, for your domain name 
> provider, your DNS system. And that's all needed to prove domain control 
> and to make sure that a certificate with the right identity is issued for 
> your endpoints.
>
> But what if these credentials get compromised? Look at the DNS system.
> *---*
>
>
>
> *5: 2023-08-14: Short-lived Certificates finally approved*
>
> https://www.entrust.com/blog/2023/08/short-lived-certificates-finally-approved/
> *---*
> After more than 10 years, short-lived TLS certificates are finally 
> permitted by the browsers based on CA/Browser Forum ballot SC-063. Gerv 
> Markham started a short-lived certs discussion in 2014, where he advised he 
> was reviewing the 2012 CA/Browser Forum discussion on the topic. He advised 
> that short-lived certificates was a plank of the Mozilla revocation 
> strategy. There was also a paper prepared in 2012 called Towards 
> Short-Lived Certificates. The paper stated OCSP is as good as dead, so the 
> CAs should issue certificates with a very short lifetime. I suppose no one 
> thought it would take so much time.
>
> Short-lived certificates are designed to help address a certificate 
> revocation issue. Back in 2012, Adam Langley discussed the seat-belt issue, 
> where it works fine, but snaps when you crash. This was based on the fact 
> the browser implements soft-fail revocation checks where the CRL or OCSP 
> response is ignored.
> *---*
>
>
>
> *6: 2024-03-26: The Path to 90-Day Certificate Validity: Challenges Facing 
> Organizations*
>
> https://www.entrust.com/blog/2024/03/the-path-to-90-day-certificate-validity-challenges-facing-organizations/
> *---*
> Certificate lifespan is getting shorter
>
> Over the years the cybersecurity industry has undergone notable 
> transformations requiring organizations to implement new best-practice 
> standards, often at a short notice.
>
> In 2020, Apple unilaterally opted for shorter TLS certificate durations, 
> reducing them from three years to 398 days, thereby increasing the burden 
> on certificate management. Subsequently, Apple introduced shorter lifespans 
> for S/MIME certificates at the start of 2022. In the past year, both code 
> signing and S/MIME users faced additional alterations, while Google 
> proposed transitioning to 90-day certificates, a subject we have explored 
> in our latest webinar. Anticipating further changes, particularly with the 
> rise of artificial intelligence (AI) and the looming risk of post-quantum 
> (PQ) computing, organizations must enhance their agility.
>
> Today, TLS/SSL certificates are typically valid for about a year, 
> according to the Certification Authority Browser (CA/B) Forum requirements. 
> This yearly renewal cycle is convenient for organizations to manage and 
> schedule. However, transitioning to shorter-lived certificates, like the 
> proposed 90-day validity period, will require more frequent renewal 
> efforts. With 90-day validity, organizations will need to renew 
> certificates four times every 12 months within that timeframe. In practice, 
> due to the need for buffer time, certificates may need to be renewed every 
> 60 days. Ultimately, this change could lead to replacing certificates more 
> than six times every 12 months, depending on the renewal window chosen.
> *---*
>
> Apologies that some of those got long, I wanted to preserve as much 
> context as possible given how little material we have to work with.
>
> I sincerely ask anyone if they can find any further communication on these 
> topics by Entrust. Their helpdesk has tutorials on specific software 
> setups, but I'm not seeing any actual push for their subscribers to do 
> anything.
>
> It would be very beneficial for Entrust to provide us with any information 
> on what they've been communicating to their customers to promote shorter 
> certificate lifespans and automation.
>
> - Wayne
>
> On Saturday, May 11, 2024 at 8:04:24 PM UTC+1 Chris Bailey wrote:
>
>> 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.

Re: Recent Entrust Compliance Incidents

[Wayne]

ur latest webinar. Anticipating further changes, particularly with the 
rise of artificial intelligence (AI) and the looming risk of post-quantum 
(PQ) computing, organizations must enhance their agility.

Today, TLS/SSL certificates are typically valid for about a year, according 
to the Certification Authority Browser (CA/B) Forum requirements. This 
yearly renewal cycle is convenient for organizations to manage and 
schedule. However, transitioning to shorter-lived certificates, like the 
proposed 90-day validity period, will require more frequent renewal 
efforts. With 90-day validity, organizations will need to renew 
certificates four times every 12 months within that timeframe. In practice, 
due to the need for buffer time, certificates may need to be renewed every 
60 days. Ultimately, this change could lead to replacing certificates more 
than six times every 12 months, depending on the renewal window chosen.
*---*

Apologies that some of those got long, I wanted to preserve as much context 
as possible given how little material we have to work with.

I sincerely ask anyone if they can find any further communication on these 
topics by Entrust. Their helpdesk has tutorials on specific software 
setups, but I'm not seeing any actual push for their subscribers to do 
anything.

It would be very beneficial for Entrust to provide us with any information 
on what they've been communicating to their customers to promote shorter 
certificate lifespans and automation.

- Wayne

On Saturday, May 11, 2024 at 8:04:24 PM UTC+1 Chris Bailey wrote:

> 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-secur...@mozilla.org <
> dev-secur...@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.
&

Re: [EXTERNAL] Recent Entrust Compliance Incidents

['Chris Bailey' via dev-security-policy@mozilla.org]

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

Re: Recent Entrust Compliance Incidents

['Ben Wilson' via dev-security-policy@mozilla.org]

Added " Although not expressed in the bug, it appears that certificate
revocation was delayed as well."

On Fri, May 10, 2024 at 10:54 AM George  wrote:

> Although it was not mentioned in the original bug, it may be worth adding
> that the certificates in bug 1867130
>  were also not
> revoked within 5 days of discovery. Entrust might've based the start of the
> 5 day deadline at the time the "Director of compliance confirmed
> investigation conclusions to support team" at 2023-11-21 15:00 UTC with all
> certificates being revoked by 2023-11-26 14:50 UTC, but I don't think
> that's correct if that was the case.
>
> On Friday, May 10th, 2024 at 5:27 PM, 'Ben Wilson' via
> dev-security-policy@mozilla.org  wrote:
>
> Here are draft summaries of the additional historic incidents. I'll be
> adding these to the Entrust Issues page:
> https://wiki.mozilla.org/CA/Entrust_Issues
>
> *Invalid data in State/Province Field -*
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1658792
>
> It was initially discovered that Entrust had issued 395 OV SSL
> certificates to a large international organization with “NA” for the
> state/province information. Entrust worked on a drop-down list to prevent
> the error. Certificate revocation would not occur within established
> timeframes, so Bug #1658794 for delayed revocation was opened.
>
> *Late Revocation for Invalid State/Province Issue - *
> https://bugzilla.mozilla.org/show_bug.cgi?id=1658794
>
> This is the delayed revocation bug related to Bug #1658792, above. Entrust
> said that when educating large institutions about rapid revocation, factors
> include who owns a certificate, where it is deployed, and the type of
> system or application that requires the certificate. It also said that it
> was advocating automation with such institutions to help speed up
> certificate replacement and to minimize human error.
>
> *EV TLS Certificate incorrect jurisdiction -*
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1802916
>
> Entrust mis-issued 322 EV certificates with the wrong state and locality
> jurisdiction fields due to complex data entry processes. Entrust
> implemented a different automated dropdown system for jurisdiction
> selection. Certificate revocation would not occur within established
> timeframes, so Bug #1804753 for delayed revocation was opened.
>
> *Delayed Revocation for EV TLS Certificate incorrect jurisdiction - *
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1804753
>
> This is the delayed revocation bug related to Bug #1802916, above. Entrust
> listed 8 Subscribers who were pushing back on immediate certificate
> revocation and the reasons given (e.g. extensions granted due to
> end-of-year freezes). Entrust committed to “continue to develop and extend
> methods for automatic certificate renewal.”
>
> *Jurisdiction Locality Wrong in EV Certificate -*
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1867130
>
> Two EV TLS Certificates were mis-issued due to human error in the
> Jurisdiction Locality field. (The incident revealed 340 additional accounts
> needing similar updates.) Entrust said it would enhance its linting
> processes to include possibly using an external service to validate
> locality data against verified country data.
>
> *SHA-256 hash algorithm used with ECC P-384 key - *
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1648472
>
> A Mozilla policy was adopted to require hashing with SHA-384 for an ECC
> P-384 key. Existing CAs using SHA-256 were not re-configured when Mozilla
> adopted this policy. This incident revealed a serious gap in taking new
> requirements and implementing them. Ryan Sleevi noted that linting was just
> a safety net and not a systemic solution. Entrust was also criticized for
> the lack of detail in its incident report and its decision to not revoke
> the certificates.
>
> Entrust committed to improving its monitoring and implementation of policy
> changes to prevent similar incidents. Ryan set forth a number of proactive
> systemic corrections that Entrust needed to take, rather than taking a
> reactive stance on matters of non-compliance.
>
> Entrust committed to rigorous review of certificate profiles, browser
> policy revisions, and industry developments. As a final comment, Ryan said,
> “My big concern is, going forward, we see incident reports from Entrust
> take a more systemic, holistic response, like Comment #16, to try and cover
> the scenarios, and to provide sufficient detail about the situation and its
> failures to understand how those relate. The goal isn't to make CAs wear
> proverbial sackcloth, it's to try and make sure we're understanding how
> things go wrong, so that we can effectively collaborate on identifying
> solutions to avoid that going forward.”
>
> *Late Revocation due to SHA-256 hash algorithm - *
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1651481
>
> This bug is related to Bug #1648472. Entrust issued TLS certificates

Re: Recent Entrust Compliance Incidents

['George' via dev-security-policy@mozilla.org]

Although it was not mentioned in the original bug, it may be worth adding that 
the certificates in [bug 
1867130](https://bugzilla.mozilla.org/show_bug.cgi?id=1867130) were also not 
revoked within 5 days of discovery. Entrust might've based the start of the 5 
day deadline at the time the "Director of compliance confirmed investigation 
conclusions to support team" at 2023-11-21 15:00 UTC with all certificates 
being revoked by 2023-11-26 14:50 UTC, but I don't think that's correct if that 
was the case.

On Friday, May 10th, 2024 at 5:27 PM, 'Ben Wilson' via 
dev-security-policy@mozilla.org  wrote:

> Here are draft summaries of the additional historic incidents. I'll be adding 
> these to the Entrust Issues page: https://wiki.mozilla.org/CA/Entrust_Issues
>
> Invalid data in State/Province Field -
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1658792
>
> It was initially discovered that Entrust had issued 395 OV SSL certificates 
> to a large international organization with “NA” for the state/province 
> information. Entrust worked on a drop-down list to prevent the error. 
> Certificate revocation would not occur within established timeframes, so Bug 
> #1658794 for delayed revocation was opened.
>
> Late Revocation for Invalid State/Province Issue -
> https://bugzilla.mozilla.org/show_bug.cgi?id=1658794
>
> This is the delayed revocation bug related to Bug #1658792, above. Entrust 
> said that when educating large institutions about rapid revocation, factors 
> include who owns a certificate, where it is deployed, and the type of system 
> or application that requires the certificate.It also said that it was 
> advocating automation with such institutions to help speed up certificate 
> replacement and to minimize human error.
>
> EV TLS Certificate incorrect jurisdiction -
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1802916
>
> Entrust mis-issued 322 EV certificates with the wrong state and locality 
> jurisdiction fields due to complex data entry processes. Entrust implemented 
> a different automated dropdown system for jurisdiction selection. Certificate 
> revocation would not occur within established timeframes, so Bug #1804753 for 
> delayed revocation was opened.
>
> Delayed Revocation for EV TLS Certificate incorrect jurisdiction -
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1804753
>
> This is the delayed revocation bug related to Bug #1802916, above. Entrust 
> listed 8 Subscribers who were pushing back on immediate certificate 
> revocation and the reasons given (e.g. extensions granted due to end-of-year 
> freezes). Entrust committed to “continue to develop and extend methods for 
> automatic certificate renewal.”
>
> Jurisdiction Locality Wrong in EV Certificate -
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1867130
>
> Two EV TLS Certificates were mis-issued due to human error in the 
> Jurisdiction Locality field. (The incident revealed 340 additional accounts 
> needing similar updates.) Entrust said it would enhance its linting processes 
> to include possibly using an external service to validate locality data 
> against verified country data.
>
> SHA-256 hash algorithm used with ECC P-384 key -
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1648472
>
> A Mozilla policy was adopted to require hashing with SHA-384 for an ECC P-384 
> key. Existing CAs using SHA-256 were not re-configured when Mozilla adopted 
> this policy. This incident revealed a serious gap in taking new requirements 
> and implementing them. Ryan Sleevi noted that linting was just a safety net 
> and not a systemic solution. Entrust was also criticized for the lack of 
> detail in its incident report and its decision to not revoke the certificates.
>
> Entrust committed to improving its monitoring and implementation of policy 
> changes to prevent similar incidents. Ryan set forth a number of proactive 
> systemic corrections that Entrust needed to take, rather than taking a 
> reactive stance on matters of non-compliance.
>
> Entrust committed to rigorous review of certificate profiles, browser policy 
> revisions, and industry developments. As a final comment, Ryan said, “My big 
> concern is, going forward, we see incident reports from Entrust take a more 
> systemic, holistic response, like Comment #16, to try and cover the 
> scenarios, and to provide sufficient detail about the situation and its 
> failures to understand how those relate. The goal isn't to make CAs wear 
> proverbial sackcloth, it's to try and make sure we're understanding how 
> things go wrong, so that we can effectively collaborate on identifying 
> solutions to avoid that going forward.”
>
> Late Revocation due to SHA-256 hash algorithm -
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1651481
>
> This bug is related to Bug #1648472.Entrust issued TLS certificates using ECC 
> P-384 keys hashed with SHA-256, contrary to Mozilla policy requiring SHA-384 
> for hashing. Entrust’s initial decision was to allow certifi

Re: Recent Entrust Compliance Incidents

['Ben Wilson' via dev-security-policy@mozilla.org]

Here are draft summaries of the additional historic incidents. I'll be
adding these to the Entrust Issues page:
https://wiki.mozilla.org/CA/Entrust_Issues

*Invalid data in State/Province Field -*

https://bugzilla.mozilla.org/show_bug.cgi?id=1658792

It was initially discovered that Entrust had issued 395 OV SSL certificates
to a large international organization with “NA” for the state/province
information. Entrust worked on a drop-down list to prevent the error.
Certificate revocation would not occur within established timeframes, so
Bug #1658794 for delayed revocation was opened.

*Late Revocation for Invalid State/Province Issue - *
https://bugzilla.mozilla.org/show_bug.cgi?id=1658794

This is the delayed revocation bug related to Bug #1658792, above. Entrust
said that when educating large institutions about rapid revocation, factors
include who owns a certificate, where it is deployed, and the type of
system or application that requires the certificate.  It also said that it
was advocating automation with such institutions to help speed up
certificate replacement and to minimize human error.

*EV TLS Certificate incorrect jurisdiction -*

https://bugzilla.mozilla.org/show_bug.cgi?id=1802916

Entrust mis-issued 322 EV certificates with the wrong state and locality
jurisdiction fields due to complex data entry processes. Entrust
implemented a different automated dropdown system for jurisdiction
selection. Certificate revocation would not occur within established
timeframes, so Bug #1804753 for delayed revocation was opened.

*Delayed Revocation for EV TLS Certificate incorrect jurisdiction - *

https://bugzilla.mozilla.org/show_bug.cgi?id=1804753

This is the delayed revocation bug related to Bug #1802916, above. Entrust
listed 8 Subscribers who were pushing back on immediate certificate
revocation and the reasons given (e.g. extensions granted due to
end-of-year freezes). Entrust committed to “continue to develop and extend
methods for automatic certificate renewal.”

*Jurisdiction Locality Wrong in EV Certificate -*

https://bugzilla.mozilla.org/show_bug.cgi?id=1867130

Two EV TLS Certificates were mis-issued due to human error in the
Jurisdiction Locality field. (The incident revealed 340 additional accounts
needing similar updates.) Entrust said it would enhance its linting
processes to include possibly using an external service to validate
locality data against verified country data.

*SHA-256 hash algorithm used with ECC P-384 key - *

https://bugzilla.mozilla.org/show_bug.cgi?id=1648472

A Mozilla policy was adopted to require hashing with SHA-384 for an ECC
P-384 key. Existing CAs using SHA-256 were not re-configured when Mozilla
adopted this policy.  This incident revealed a serious gap in taking new
requirements and implementing them. Ryan Sleevi noted that linting was just
a safety net and not a systemic solution. Entrust was also criticized for
the lack of detail in its incident report and its decision to not revoke
the certificates.

Entrust committed to improving its monitoring and implementation of policy
changes to prevent similar incidents. Ryan set forth a number of proactive
systemic corrections that Entrust needed to take, rather than taking a
reactive stance on matters of non-compliance.

Entrust committed to rigorous review of certificate profiles, browser
policy revisions, and industry developments. As a final comment, Ryan said,
“My big concern is, going forward, we see incident reports from Entrust
take a more systemic, holistic response, like Comment #16, to try and cover
the scenarios, and to provide sufficient detail about the situation and its
failures to understand how those relate. The goal isn't to make CAs wear
proverbial sackcloth, it's to try and make sure we're understanding how
things go wrong, so that we can effectively collaborate on identifying
solutions to avoid that going forward.”

*Late Revocation due to SHA-256 hash algorithm - *

https://bugzilla.mozilla.org/show_bug.cgi?id=1651481

This bug is related to Bug #1648472.  Entrust issued TLS certificates using
ECC P-384 keys hashed with SHA-256, contrary to Mozilla policy requiring
SHA-384 for hashing. Entrust’s initial decision was to allow certificates
to expire naturally without revocation, but this was revised with a
decision to revoke all affected certificates. Entrust committed to: filing
incident report within one business day for future incidents, filing late
revocation incident reports within the required 24 hours or 5 days, as
applicable, and advising Subscribers about revocation within 24 hours or 5
days, or provide an explanation if they are unable to meet such timeframes.
Entrust was told it needed to align its revocation procedures more closely
with the Baseline Requirements and Mozilla’s policy, especially in
providing a detailed rationale for any delays in revocation on a
per-subscriber basis and ensuring timely revocation in line with the
Baseline Requirements.



On Thu, May 9, 2024 at 8:13 PM

Re: Recent Entrust Compliance Incidents

[Watson Ladd]

Could we add a section for geographical incidents? This is slightly
outside your time window, but I think reading the series here has some
uncanny echos in the ones in your window.

https://bugzilla.mozilla.org/show_bug.cgi?id=1658792
https://bugzilla.mozilla.org/show_bug.cgi?id=1658794
https://bugzilla.mozilla.org/show_bug.cgi?id=1802916
https://bugzilla.mozilla.org/show_bug.cgi?id=1804753
https://bugzilla.mozilla.org/show_bug.cgi?id=1867130

On Tue, May 7, 2024 at 7:59 AM 'Ben Wilson' via
dev-security-policy@mozilla.org 
wrote:
>
> 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. 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 and #1648472), 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 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 
> 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 to 
> offer systematic, automated solutions for effective remediation, like ACME 
> ARI and that it also include clear and measurable targets for the adoption of 
> these tools by new and existing subscribers.
>
> This report should be submitted to Mozilla dev-security-policy mailing list 
> for evaluation by the community and Mozilla, who will weigh whether Entrust’s 
> report presents a credible and effective path towards re-establishing trust 
> in Entrust’s operation. Submission should be no later than June 7, 2024.
>
> We thank community members for their engagement on these issues and look 
> forward to their feedback on Entrust’s report and proposed commitments.
>
>  Thanks,
>
> Ben Wilson
>
> Mozilla Root Program
>
> --
> 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/CA%2B1gtaYURqFzRqVmJdc7fBXE1mbGs25HpSkp5wZ0Xm%2BRG0YHCA%40mail.gmail.com.



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

Recent Entrust Compliance Incidents

['Ben Wilson' via dev-security-policy@mozilla.org]

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. 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
 and #1648472
), 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
 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  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
 to offer
systematic, automated solutions for effective remediation, like ACME ARI
and that it also include clear and measurable targets for the adoption of
these tools by new and existing subscribers.

This report should be submitted to Mozilla dev-security-policy mailing list
for evaluation by the community and Mozilla, who will weigh whether
Entrust’s report presents a credible and effective path towards
re-establishing trust in Entrust’s operation. Submission should be no later
than June 7, 2024.

We thank community members for their engagement on these issues and look
forward to their feedback on Entrust’s report and proposed commitments.

 Thanks,

Ben Wilson

Mozilla Root Program

-- 
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/CA%2B1gtaYURqFzRqVmJdc7fBXE1mbGs25HpSkp5wZ0Xm%2BRG0YHCA%40mail.gmail.com.