Public Discussion of SSL.com CA Inclusion Request
Chris Clements
All,
This email commences a six-week public discussion of SSL.com’s request to include the following certificates as publicly trusted root certificates in one or more CCADB Root Store Member’s program. This discussion period is scheduled to close on May 2, 2023.
The purpose of this public discussion process is to promote openness and transparency. However, each Root Store makes its inclusion decisions independently, on its own timelines, and based on its own inclusion criteria. Successful completion of this public discussion process does not guarantee any favorable action by any root store.
Anyone with concerns or questions is urged to raise them on this CCADB Public list by replying directly in this discussion thread. Likewise, a representative of the applicant must promptly respond directly in the discussion thread to all questions that are posted.
CCADB Case Numbers: 00001049 and 00001132
Organization Background Information (listed in CCADB):
CA Owner Name: SSL.com
Website: https://www.ssl.com/
Address: 3100 Richmond Ave., Suite 405, Houston, Texas, 77098, United States of America
Problem Reporting Mechanisms: sup...@ssl.com, https://www.ssl.com/revoke/
Organization Type: Public Corporation
Repository URL: https://www.ssl.com/repository/
Certificates Requesting Inclusion:
SSL.com TLS RSA Root CA 2022 (included in case 00001049):
Certificate download links: (CA Repository, crt.sh)
Use cases served/EKUs:
Server Authentication (TLS) 1.3.6.1.5.5.7.3.1
Client Authentication 1.3.6.1.5.5.7.3.2
Test websites:
SSL.com TLS ECC Root CA 2022 (included in case 00001049):
Certificate download links: (CA Repository, crt.sh)
Use cases served/EKUs:
Server Authentication (TLS) 1.3.6.1.5.5.7.3.1
Client Authentication 1.3.6.1.5.5.7.3.2
Test websites:
SSL.com Client ECC Root CA 2022 (included in case 00001132):
Certificate download links: (CA Repository, crt.sh)
Use cases served/EKUs:
Secure Email (S/MIME) 1.3.6.1.5.5.7.3.4
Client Authentication 1.3.6.1.5.5.7.3.2
Test websites: N/A
SSL.com Client RSA Root CA 2022 (included in case 00001132):
Certificate download links: (CA Repository, crt.sh)
Use cases served/EKUs:
Secure Email (S/MIME) 1.3.6.1.5.5.7.3.4
Client Authentication 1.3.6.1.5.5.7.3.2
Test websites: N/A
Existing Publicly Trusted Root CAs from SSL.com:
SSL.com EV Root Certification Authority ECC:
Certificate download links: (CA Repository, crt.sh)
Use cases served/EKUs:
Server Authentication (TLS) 1.3.6.1.5.5.7.3.1
Code Signing 1.3.6.1.5.5.7.3.3
Time Stamping 1.3.6.1.5.5.7.3.8
Certificate corpus: here (login required)
Included in: Apple, Chrome, Microsoft, and Mozilla
SSL.com EV Root Certification Authority RSA R2:
Certificate download links: (CA Repository, crt.sh)
Use cases served/EKUs:
Server Authentication (TLS) 1.3.6.1.5.5.7.3.1
Code Signing 1.3.6.1.5.5.7.3.3
Time Stamping 1.3.6.1.5.5.7.3.8
Certificate corpus: here (login required)
Included in: Apple, Chrome, Microsoft, and Mozilla
SSL.com Root Certification Authority ECC:
Certificate download links: (CA Repository, crt.sh)
Use cases served/EKUs:
Server Authentication (TLS) 1.3.6.1.5.5.7.3.1
Secure Email (S/MIME) 1.3.6.1.5.5.7.3.4
Client Authentication 1.3.6.1.5.5.7.3.2
Code Signing 1.3.6.1.5.5.7.3.3
Document Signing AATL 1.2.840.113583.1.1.5
Document Signing MS 1.3.6.1.4.1.311.10.3.12
Certificate corpus: here (login required)
Included in: Apple, Chrome, Microsoft, and Mozilla
SSL.com Root Certification Authority RSA:
Certificate download links: (CA Repository, crt.sh)
Use cases served/EKUs:
Server Authentication (TLS) 1.3.6.1.5.5.7.3.1
Secure Email (S/MIME) 1.3.6.1.5.5.7.3.4
Client Authentication 1.3.6.1.5.5.7.3.2
Code Signing 1.3.6.1.5.5.7.3.3
Document Signing AATL 1.2.840.113583.1.1.5
Document Signing MS 1.3.6.1.4.1.311.10.3.12
Time Stamping 1.3.6.1.5.5.7.3.8
Certificate corpus: here (login required)
Included in: Apple, Chrome, Microsoft, and Mozilla
Relevant Policy and Practices Documentation:
The following apply to all four (4) applicant root CAs:
Most Recent Self-Assessment:
The following apply to all four (4) applicant root CAs:
https://bugzilla.mozilla.org/attachment.cgi?id=9302401 (completed 11/7/2022)
Audit Statements:
Auditor: BDO International Limited (enrolled through WebTrust)
Audit Criteria: WebTrust
Date of Audit Issuance: 9/27/2022
For Period Ending: 6/30/2022
Audit Statement(s):
Standard Audit (covers all four (4) applicant root CAs)
BR (SSL) Audit (covers all four (4) applicant root CAs)
EV SSL Audit (only covers “SSL.com TLS RSA Root CA 2022” and “SSL.com TLS ECC Root CA 2022”)
Incident Summary (Bugzilla incidents from previous 24 months):
1790693: SSL.com: Issuance of 1 EV TLS certificate using a Registration/Incorporation Agency not included in our approved public list.
1800753: SSL.com: Delayed revocation of certificate with weak key
1719916: SSL.com: Issuance of an EV TLS certificate with incorrect O Field Value
1722089: SSL.com: Issuance of 3 EV TLS certificates without 2-person validation of the organization information
1724520: SSL.com: Incorrect Domain Validation for 1 TLS certificate with FQDN having "www." string within domain labels
1750631: SSL.com: Issuance of TLS certificates with validation methods prohibited by SC-45
1752636: SSL.com: Delayed revocation of 53 certificates affected by bug #1750631
Thank you,
Chris, on behalf of the CCADB Steering Committee
Matthias van de Meent
<pub...@ccadb.org> wrote:
>
> All,
>
> This email commences a six-week public discussion of SSL.com’s request to include the following certificates as publicly trusted root certificates in one or more CCADB Root Store Member’s program. This discussion period is scheduled to close on May 2, 2023.
>
> The purpose of this public discussion process is to promote openness and transparency. However, each Root Store makes its inclusion decisions independently, on its own timelines, and based on its own inclusion criteria. Successful completion of this public discussion process does not guarantee any favorable action by any root store.
>
> Anyone with concerns or questions is urged to raise them on this CCADB Public list by replying directly in this discussion thread. Likewise, a representative of the applicant must promptly respond directly in the discussion thread to all questions that are posted.
>
>
> Incident Summary (Bugzilla incidents from previous 24 months): [...]
>
> - 1800753: SSL.com: Delayed revocation of certificate with weak key
In this issue I expressed my concerns about SSL.com's lack of urgency
regarding detecting, handling, and responding to reports about, and
awareness of, weak public keys in the timelines required by BRs
4.9.1.1 par.1 item (4).
The issue itself concerns the revocation timeline of a certificate
that contains a public key vulnerable to Fermat Factorization, where
the problem wasn't reported through the CA's normal certificate
problem report flow, but instead was reported on the public forum of
dev-secur...@mozilla.org.
After SSL.com publicly acknowledged that there could be problems with
the certificate (and thus had become aware of the existence of the
problem), they still took more than 24 hours to revoke the certificate
without considering that timeline problematic, with their reasoning
being as follows:
> However, as the current BRs and our CP/CPS remain silent about characterizing the Fermat’s factorization method as “a demonstrated or proven method that can easily compute the Subscriber’s Private Key”, especially without additional details about the number of rounds needed to factor the key, we did not consider that the 24h revocation timeline applied. In particular, we proceeded with revocation within the 5-days timeline defined in BRs 4.9.1.1 par.2 item (11), which says (emphasis ours):
>
> “The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise or **if there is clear evidence that the specific method used to generate the Private Key was flawed** ”.
To me, this argument doesn't hold, because the problem report nor the
certificate identified any information about what way the private key
was generated.
I find it concerning that the CA does not do due diligence and
validate the claims of a report on a potentially problematic
certificate, but instead states that Fermat Factorization is not
mentioned by name in the BR and that the CA thus doesn't have to
revoke the certificate in the 24-hour time window: according to the
first mail from SSL.com in the dev-security-policy mail, the
certificate was to be revoked "out of an abundance of caution", and
not due to the requirements agreed upon in the BR. Because the
relevant public key is factored in 1 round of Fermat's Factorization
Method, this makes it difficult to believe that SSL.com did any work
on validating the claims of the post on the forum: They acknowledged
that the certificate's public key could have problems but did not
effectively act on that suspicion.
This issue makes me wonder whether SSL.com is able to handle reports
on novel weaknesses in public keys appropriately, as they don't seem
to be able to handle knowledge about known vulnerabilities like close
primes/Fermat Factorization without waiting for a CA/B Forum ballot to
get through the approval process.
Note that I don't advocate that all CAs must run hours of Fermat's on
each certificate's public keys, but that when a CA is confronted with
the knowledge that a certificate's public key may be weak to a certain
attack, then it should do its due diligence by testing at the very
least the most trivial version of the attack to check whether the
claim that the PK is vulnerable might be true. In this case, that was
apparently too much for SSL.com.
All in all, I am concerned about SSL.com's ability to comply with the
BR in those places where the BR describes only the broad ideas without
specifics, like those in section 4.9.1.1 par.1 item (4), especially
when it concerns security, key material, and/or revocation timelines
of certificates.
Kind regards,
Matthias van de Meent
Thomas Zermeno
In response to https://groups.google.com/a/ccadb.org/g/public/c/mTUkK-gkHPE/m/WBaf7QUnAwAJ, starting from the Matthias’ last statement we would like to point to our actions as explained in [1], [2] and [3], which demonstrate SSL.com’s ability to monitor, analyze and take informed decisions, addressing particular cases in accordance with the BRs.
More specifically, our immediate actions demonstrate:
i) active monitoring of industry channels such as m.d.s.p., which allowed capturing a case which was not reported via the required channels, as published in our CP/CPS section 4.9.3 per provisions of BRs section 4.9.3;
ii) ability to respond swiftly with expedited deployment and testing of technical control updates (pre-issuance linting), effectively blocking any similar issuances;
iii) provident care to retrospectively test against the entire corpus of certificates, confirming no other occurrences exist;
iv) due diligence by promptly analyzing the technical and compliance aspects of the issue at hand, considering the relevant literature and the applicable requirements, thus leading to informed decisions instead of acting hastily;
v) eagerness to test our processes and identify possible improvements by handling the issue as a real-world case, acting in communication with the subscriber and reporter (in this case, the same person).
In our opinion, completing the above-mentioned actions (analysis, decision, notification, revocation, retrospection and mitigation) within 26 hours, is not a sign of “SSL.com's lack of urgency regarding detecting, handling, and responding” as stated in Matthias opening statement.
It is worth explaining the rationale of our actions, and more specifically why we didn’t make an earlier revocation decision. Context played a decisive role here. If we had received a Certificate Problem Report (CPR) per section 4.9.5 of the BRs, we would be forced to follow the exact deadlines specified in the CPR procedure (confirmation, revocation decision and execution within 24 hours of receipt of the CPR). We would have a significantly different approach (lower level of analysis depth, lower priority in updating preventive controls, etc.). Since this case was reported in a public mailing list, we considered it better to do a more in-depth analysis as due diligence and use this time to prioritize other equally important actions (preventive controls, retrospection).
Overall, we would like to state that this is not a case of a CA trying to escape its obligations. With [3] we made clear that, in our opinion, and in accordance with the expectations of the industry, a CA may not arbitrarily extend the period of investigation and use it as an excuse to delay revocation. We have also been completely transparent and tried to detail the rationale of our actions. As stated in [2], if the root store owners considered this a violation or found any value in filing an incident report, we would do so. However, no such request was made (for the more than two months after our December response, which further explained our rationale); on the contrary, [4] is a clear indication that our actions were considered reasonable and compliant.
As a publicly-trusted CA, we have handled numerous cases of CPRs reporting vulnerable or other forms of compromised keys and we have followed the requirements to the letter. Our annual audits confirm our compliance with these requirements.
However, we are using this case as a learning opportunity. Handling it as a real-world report, rather than as a security researcher’s exercise, allowed us to test our processes and draw useful conclusions which will improve our understanding and the maturity of our processes going forward. For example, this allowed us to do further research on weak keys, which is shortly presented in [6] and which will be used in delivering Ballot SC-59.
[1]
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/TlhjCJm610I/m/LmlR3tJCBAAJ
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1800753#c2
[3]
https://bugzilla.mozilla.org/show_bug.cgi?id=1800753#c6
[4]
https://bugzilla.mozilla.org/show_bug.cgi?id=1800753#c7
[5]
https://bugzilla.mozilla.org/show_bug.cgi?id=1800753#c8
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1800753#c11
Ben Wilson
All,
I have just completed a CP/CPS review of SSL.com's CP/CPS v. 1.16 and attached it to Bugzilla Bug #1799533 (https://bugzilla.mozilla.org/show_bug.cgi?id=1799533). See https://bugzilla.mozilla.org/attachment.cgi?id=9327554 (Excel Spreadsheet).
I would like SSL.com to read through my comments and respond to them in Bug # 1799533.
Thanks,
Ben
--
You received this message because you are subscribed to the Google Groups "CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/5c8a49d2-914f-4019-8cd4-fd2487271ad9n%40ccadb.org.
Matthias van de Meent
>
> In response to https://groups.google.com/a/ccadb.org/g/public/c/mTUkK-gkHPE/m/WBaf7QUnAwAJ, starting from the Matthias’ last statement we would like to point to our actions as explained in [1], [2] and [3], which demonstrate SSL.com’s ability to monitor, analyze and take informed decisions, addressing particular cases in accordance with the BRs.
>
> More specifically, our immediate actions demonstrate:
>
> i) active monitoring of industry channels such as m.d.s.p., which allowed capturing a case which was not reported via the required channels, as published in our CP/CPS section 4.9.3 per provisions of BRs section 4.9.3;
that exist in certificates. The CA is required to act in the time
specified in BR section 4.9.1.1, regardless of the way they became
aware of the poblem. The only thing that CPR brings onto the table is
a clear and objective way to determine when the clock starts without
depending on the CA for the rather vague moment of "becoming aware" or
"receives evidence": the moment that the message containing the CPR
was received by the CA, regardless of other processing steps.
Note, again, that neither of us seems to consider the original mail a
Certificate Problem Report as per the BR. That's also why I don't
think BRs4.9.5's start time stipulation is relevant - this time only
4.9.1.1 specifies the time windows.
> ii) ability to respond swiftly with expedited deployment and testing of technical control updates (pre-issuance linting), effectively blocking any similar issuances;
>
> iii) provident care to retrospectively test against the entire corpus of certificates, confirming no other occurrences exist;
>
> iv) due diligence by promptly analyzing the technical and compliance aspects of the issue at hand, considering the relevant literature and the applicable requirements, thus leading to informed decisions instead of acting hastily;
noncompliance issue under 6.1.1.3, not 4.9.1.1. The sections are
related, but are distinct in function: One is to prevent issuance, and
one is to revoke once issued. Being known not to comply with 6.1.1.3
doesn't mean that the certificates issued won't have to be revoked
with 4.9.1.1-specified timelines.
> v) [...]
revocation)" feels like it refers a time period including both the
first mail from SSL.com on the m.d.s.p. forum's topic [0] and the
revocation timestamp of the certificate [1], which already spans at
least 25 hours and 50 minutes.
The first mail already claims to have completed testing the database
for other vulnerable certificates, which would mean that the database
was scanned and a new linter version was installed within 10 minutes,
which to me seems extremely fast for a database containing hundreds of
thousands of certificates (which at the time of writing is 205648
unexpired certificates for the issuer CA of the problematic
certificate alone), and a deployment process that needs sign-off of at
least 2 people, which is why I doubt that your claim of 26 hours is
accurate.
Again, from an outsider's perspective the timeline looks something like this:
2022-10-29 20:45 UTC - the problem was sent in a mail to m.d.s.p
No specific moment known, but implied to be before 2022-11-02 15:00
UTC: SSL.com notices the mail in m.d.s.p, becomes aware of the problem
and starts acting on the issue.
No specific moment known, but implied to be before 2022-11-02 15:00
UTC: SSL.com expedites their zlint update, and scans its database for
problematic certificates, completing before the next item.
2022-11-02 15:00 UTC - SSL.com publicly posts on m.d.s.p that they
have updated zlint, scanned their database for the issue, proposed a
CA/B Forum ballot, and have started planning to replace the
certificate.
2022-11-03 16:50 UTC - the timestamp in CRL / OCSP for the revoked certificate.
In whatever manner, if the certificate itself wasn't considered to be
vulnerable before the database scan, the certificate should have
popped up in the search of the database for vulnerable public keys and
at that point the timeline required by 4.9.1.1(4) starts. I don't see
how the "needs more context" changes the requirements - the public key
has a known vulnerability, you knew ("was aware") of the vulnerability
of the key at-or-before 2022-11-02 15:00 UTC due to _at least_ the
database scan, and failed to revoke within the stipulated 24 hours.
A CA misunderstanding the BR does not remove their need to comply with
the BR, that'd be absurd.
> It is worth explaining the rationale of our actions, and more specifically why we didn’t make an earlier revocation decision. Context played a decisive role here. If we had received a Certificate Problem Report (CPR) per section 4.9.5 of the BRs, we would be forced to follow the exact deadlines specified in the CPR procedure (confirmation, revocation decision and execution within 24 hours of receipt of the CPR).
taken, it isn't going to change the point I'm making. The BR don't
require a CPR for the 24-hour requirement to be applicable.
If a CA is otherwise notified or becomes aware of problematic
certificates, regardless of the method, the clock starts from the
moment they become aware. The clause for the CPR endpoint in 4.9.5
only makes it clear that a CPR being received by the CA at their
specified CPR endpoint is equivalent to the CA becoming aware, which
starts the timer. Other methods of becoming aware of issues still
co-exist with the CPR endpoint, and although they are less clear about
the awareness timelines, they still have the 24-hour time limit.
> We would have a significantly different approach (lower level of analysis depth, lower priority in updating preventive controls, etc.). Since this case was reported in a public mailing list, we considered it better to do a more in-depth analysis as due diligence and use this time to prioritize other equally important actions (preventive controls, retrospection).
the non-compliance with BR 6.1.1.3, I feel like you're failing to see
the forest for the trees. The issue is not that you handled your whole
certificate corpus in a great manner, but that you did not meet the
BR-stipulated timeline for the one certificate that showed the
problem.
I see three distinct ways to interpret the publicly available timeline:
1. Until (at the earliest) 2022-11-02 16:50 UTC (which is after
SSL.com's m.d.s.p mail on the topic) SSL.com did not know that for
that certificate there was "a demonstrated or proven method that can
easily compute the Subscriber’s Private Key based on the Public Key in
the Certificate", with in this case "a proven method" being Fermat's
Factorization Method.
2. SSL.com did know that the certificate was vulnerable to Fermat's
Factorization Method before 2022-11-02 16:50 UTC
3. as above, but SSL.com didn't think 4.9.1.1 (4) to apply to Close
Primes / Fermat's Factorization Method
If the first, then I worry about the CA's ability to act on clear
reports from side-channels and linters about problematic certificates
- the report refers to the certificate by a public id and reference,
and which attack it is vulnerable to, and you reply with what looks
like an acknowledgement of the attack vector and an acknowledgement
that the database was scanned for the vulnerability. At that point,
you should have known that the certificate must be revoked within 24
hours under the 4.9.1.1(4) requirements.
If the second, then the required timeline of 24 hours (as per BR
4.9.1.1(4)) was not met, and in that case the CA does seem to be
trying to escape the obligations that come with being part of the
Mozilla Root Store under MRSP 2.4 by explaining their actions.
If the last, then that is also quite problematic: what other (new)
attack vectors to RSA could the CA be aware of without considering the
public keys vulnerable to those attacks as in need to be revoked? A CA
not being able to put 1 and 1 together in the timeframe it said it
would seems quite concerning.
I agree that explaining actions is important to understand them, but
if mistakes/incidents aren't considered a problem, then there is no
value in explaining the actions that lead to that incident, as the
problematic behaviour would persist.
> Overall, we would like to state that this is not a case of a CA trying to escape its obligations.
> With [3] we made clear that, in our opinion, and in accordance with the expectations of the industry, a CA may not arbitrarily extend the period of investigation and use it as an excuse to delay revocation.
directly related to the issue at hand. The mail containing information
that implied that SSL.com had knowledge of the vulnerable certificate
was released more than 24 hours before the certificate was ultimately
revoked.
> We have also been completely transparent [...]
It would be greatly appreciated if you could share your timeline of
the events on that issue, and specifically the moments where each of
your above i) to v) was handled regarding that issue.
> [We] tried to detail the rationale of our actions.
Yes, I understand and (mostly) agree with the rationale of the actions
you took, except the one where you stated that attacks not in the BR
don't trigger the 4.9.1.1(4) requirement - I think they do.
> As stated in [2], if the root store owners considered this a violation or found any value in filing an incident report, we would do so. However, no such request was made (for the more than two months after our December response, which further explained our rationale); on the contrary, [4] is a clear indication that our actions were considered reasonable and compliant.
What I read is that Ben considered that the extensive discussion on
the issue dying out warranted the bug to be closed; not specifically
as Invalid, and had probably missed that there was no incident report
published yet.
> As a publicly-trusted CA, we have handled numerous cases of CPRs reporting vulnerable or other forms of compromised keys and we have followed the requirements to the letter. Our annual audits confirm our compliance with these requirements.
for the period of July 1, 2021 to June 30, 2022) does, whilst not
modifying the opinion, refer to other non-compliance issues, including
more late revocations; implying that your "following to the letter"
also includes "failing to comply". In that case, I'd rather have you
not "follow the requirements to the letter", but instead be compliant
on all aspects of the requirements.
So, in short: I still see no reason to believe SSL.com was _not_ aware
of the certificate's issue w.r.t. vulnerable public key by the time
they sent their mail, yet by all metrics they failed to comply with
the BR. They then try to confuse us with context of them solving their
non-compliance with BR 6.1.1.3 (which is another compliance issue)
without considering their non-compliance with BRs4.9.1.1 as an issue.
I'm not confident that SSL.com's understanding of the BR is to the
level that we can expect of a CA, let alone one that already has root
certificates in various root stores.
Kind regards,
Matthias van de Meent
[1] https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=4abb6f0c-a72d-40ca-90a1-1c40b140f75a
Thomas Zermeno
Chris Clements
All,
This is a reminder that the public discussion period on the inclusion application of SSL.com will close next Tuesday, on May 2, 2023.
Thank you,
Chris, on behalf of the CCADB Steering Committee
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/6a8dca06-087e-4818-b41a-5e5212271ffcn%40ccadb.org.
Leo Grove
Regards,
Leo
Sent: Tuesday, April 25, 2023 8:07 AM
To: Thomas Zermeno <madca...@gmail.com>
Cc: CCADB Public <pub...@ccadb.org>; Ben Wilson <bwi...@mozilla.com>
Subject: Re: Public Discussion of SSL.com CA Inclusion Request
Thomas Zermeno
Ben Wilson
Chris Clements
All,
On March 21, 2023, we began a six-week, public discussion [1] on the request from SSL.com for inclusion of its root certificate(s):
The public discussion period ended on May 2, 2023.
Summary of Discussion
Discussion Item #1: Concerns were raised about SSL.com’s lack of urgency in detecting, handling, and responding to weak public keys and their ability to comply with the BRs in areas without specific guidelines, especially when it comes to security and revocation timelines.
SSL.com Response to Discussion Item #1: SSL.com believes their actions in [2], [3] and [4] demonstrate their ability to monitor, analyze, and make informed decisions in accordance with the BRs. It was pointed out that the actions in [3] demonstrate a commitment to addressing concerns, and the context in which the issue was reported influenced the decision to perform a more in-depth analysis. It was also mentioned that this incident is being used as a learning opportunity to test and improve processes, and the experience has informed their research and contributions to Ballot SC-59.
Discussion Item #1 Continued: It was stressed that CAs must respond to certificate issues promptly per Section 4.9.1.1, regardless of how they discover the problem. An interpretation of the timeline in Incident Report 1800753 [5] was provided, and it was suggested that SSL.com should have known of a certificate’s vulnerability and revoked it within 24 hours.
Discussion Item #2: Ben Wilson commented on the SSL.com CP/CPS v. 1.16. [6]
SSL.com Response to Discussion Item #2: SSL.com is updating the CP/CPS to version 1.17 with expected publication on or before May 15, 2023. [7]
==========================
We thank community members for their review and consideration during this period. Root Store Programs will make final inclusion decisions independently, on their own timelines, and based on each Root Store Member’s inclusion criteria. Further discussion may take place in the independently managed Root Store community forums (i.e., MDSP).
[1] https://groups.google.com/a/ccadb.org/g/public/c/mTUkK-gkHPE/m/bBl1fCN5AAAJ
[2] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/TlhjCJm610I/m/LmlR3tJCBAAJ
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1800753#c2
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1800753#c6
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1800753
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1799533#c6
[7] https://bugzilla.mozilla.org/show_bug.cgi?id=1799533#c11
Thank you,- Chris, on behalf of the CCADB Steering Committee
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaaoGgHOrPNwp7R-Uj9%3DC_vDiiq9f9NhbuqBjOGQ8JJi3g%40mail.gmail.com.