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 [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/1c0822a3-88b4-4cbe-a175-3ffdc84c1c27n%40mozilla.org.
