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/[email protected]/msg13151.html > <https://www.mail-archive.com/[email protected]/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 >> [email protected] <[email protected]>: >> >>> 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 <[email protected]>: >>> >>> >>> >>> On Thu, Jul 4, 2024, 11:49 AM 'Bruce Morton' via >>> [email protected] <[email protected]> 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 "[email protected]" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> 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 >>> >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b4dcb651-aec5-4f2e-8325-9aafa2f9ea58n%40mozilla.org?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "[email protected]" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> >>> 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 >>> >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CACsn0cnV%2B3b3XM8Xi8r8b5w%2BP3oQ%2BAer_vt8HmZdLyw7QMV5Pw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "[email protected]" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> >> To view this discussion on the web visit >>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/8b89eed0-98f9-4aff-9133-443d048aea29n%40mozilla.org >>> >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/8b89eed0-98f9-4aff-9133-443d048aea29n%40mozilla.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/00a790a4-f6e2-43ff-b6cb-a3c02f02a4fen%40mozilla.org.
