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 [email protected] <[email protected]> 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/[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/471e40fe-85b0-4306-85a4-7916695a2f66n%40mozilla.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/471e40fe-85b0-4306-85a4-7916695a2f66n%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/CADQzZqt0NUe40FjW_kFKCLSXA8Sf0jA%2BabpiZpnnJ__kM%3DO_DQ%40mail.gmail.com.
