(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). 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/c2528f48-d51f-4d0e-a68d-23001e595bfcn%40mozilla.org.
