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/CAOY5%3DRA%3D9LY6Dd4QKtzMRcRr7bcoPeE5VPxe%3D1tPts%2B-c572gA%40mail.gmail.com.

Reply via email to