Closed Bug 1793210 Opened 2 years ago Closed 2 years ago

Apple: CRLs for dormant CAs will not be populated in CCADB

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: certification_authority, Assigned: certification_authority)

Details

(Whiteboard: [ca-informational])

1) How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

On October 1, 2022, the following Mozilla Root Store Policy version 2.8 requirement goes into effect:

“Effective October 1, 2022, CA operators with intermediate CA certificates that are capable of issuing TLS certificates chaining up to root certificates in Mozilla's root store SHALL populate the CCADB fields under "Pertaining to Certificates Issued by This CA" with either the CRL Distribution Point for the "Full CRL Issued By This CA" or a "JSON Array of Partitioned CRLs";"

Apple Public CA has eight dormant CA certificates that are capable of issuing TLS certificates. Apple Public CA will not be providing CRLs for these dormant CAs to our root vendors for population in CCADB by October 1, 2022. Our understanding of the Mozilla Root Store Policy requirements, based on statements made by Mozilla, is that dormant CAs that have never produced a CRL nor signed a certificate are not required to provide ‘Full CRLs’ to root vendors.

2) A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

  • 2018-12-12 and 2018-12-21: DigiCert issued to Apple six CAs capable of issuing TLS certificates. These CAs were not put into production due to Apple CA’s strategy of active/passive CA redundancy. These CAs were, and are, classified as passive, or dormant, CAs.
  • 2019-06-19: Sectigo issued to Apple two CAs capable of issuing TLS certificates. These CAs were not put into production due to Apple CA’s strategy of active/passive CA redundancy. These CAs were, and are, classified as passive, or dormant, CAs.
  • 2022-06-01: Effective date of the Mozilla Root Store Policy version 2.8, which says in section 4.1 that:

“Effective October 1, 2022, CA operators with intermediate CA certificates that are capable of issuing TLS certificates chaining up to root certificates in Mozilla's root store SHALL populate the CCADB fields under "Pertaining to Certificates Issued by This CA" with either the CRL Distribution Point for the "Full CRL Issued By This CA" or a "JSON Array of Partitioned CRLs";"

  • 2022-09-21: Mozilla noted its intent to modify section 4.1 to clarify when full CRLs need to be added to the CCADB but also stated that such modifications would not be made to the policy before October 1, 2022.
  • 2022-09-27: Apple Public CA concluded discussions with each root vendor on the approach for Apple’s dormant CAs.
  • 2022-09-28: The Apple Root Program shared that the Apple Root Program Policy had been updated to clarify the Apple Root Program’s expectation with regards to the Full CRL disclosure requirements and their interaction with both dormant CAs:

“Effective October 1, 2022, CA providers must populate the CCADB fields under "Pertaining to Certificates Issued by This CA" with either the CRL Distribution Point for the "Full CRL Issued By This CA" or a "JSON Array of Partitioned CRLs" on Root and Intermediate Certificate records, within 7 days of the corresponding CA issuing its first certificate. This requirement applies to each included CA Certificate and each CA Certificate chaining up to an included CA Certificate in the Apple Root Program."

  • 2022-09-28: Mozilla stated that they would be following the same language as the Apple Root Program Policy in the next version of the Mozilla Root Store Policy for populating the CCADB full-CRL fields.

3) Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.

This did not affect certificate issuance.

4) In a case involving certificates, a summary of the problematic certificates. For each problem: the number of certificates, and the date the first and last certificates with that problem were issued. In other incidents that do not involve enumerating the affected certificates (e.g. OCSP failures, audit findings, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified. This will help us measure the severity of each problem.

There were no problematic certificates issued in error, hence no certificates needed to be revoked and reissued.

5) In a case involving certificates, the complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.

There were no problematic certificates issued in error, hence no certificates needed to be revoked and reissued.

The following TLS CAs are dormant and have never produced a CRL nor signed a certificate:

Dormant CAs issued by DigiCert:

Dormant CAs issued by Sectigo:

6) Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

Our understanding of the Mozilla Root Store Policy requirements, based on statements made by Mozilla, is that dormant CAs that have never produced a CRL nor signed a certificate are not required to provide ‘Full CRLs’ to root vendors.

7) List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these remediation steps.

While we understand Mozilla’s intent to clarify the policy in a later version, we will be out of compliance with the written Mozilla Root Store Policy version 2.8, section 4.1 on October 1, 2022. We expect to remain out of compliance with this requirement until the policy is updated.

As Sectigo is CA issuer and ultimately responsible for two of these CA certificates, we would like to acknowledge the incident report posted by Apple and add our own internal events leading up to this response.

In order to comply with the Apple and Mozilla requirement of disclosing the full CRL data for any CA certificate capable of issuing TLS certificates, we started adding required data into CCADB on September 22, 2022. When this process was complete, we noticed that two CA certificates capable of issuing TLS certificates were listed as missing the required CRL data. We posted a message on m.d.s.p to clarify what was required of us.

Mozilla has publicly announced its intention to change its policy and follow the same language the Apple Root Program Policy has adopted. Mozilla also stated that it would not be able to make such changes before the October 1st deadline.

After an internal discussion we reached out to Apple to coordinate our responses. This discussion included which party should open the incident report. As Apple has CA certificates issued by both Sectigo and DigiCert, we agreed it made sense for Apple to open the report.

Assignee: bwilson → certification_authority
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-compliance]

Hey Ben - For clarity, this bug was filed for completeness because non-issuing ICAs aren't officially excluded from Mozilla policy. However, the email from you on Sept 20th gave an unofficial exception for non-issuing CAs. Since these ICAs are not issuing, they don't technically need a CRL yet under the upcoming change to the policy. Kudos to Apple for filing for completeness, but I think you aren't seeing a lot of similar incident reports because of the unofficial policy change to require a CCADB listing within 7 days of first issuance.

(In reply to Tim Callan from comment #1)
As October 1 was the deadline for the existing Mozilla policy requirement, we quickly wrote and posted a comment on Saturday to keep it current. Now that we have had a chance for more members of our team to weigh in, we would like to update comment 1 with additional information in case this detail is helpful to other CAs or the community at large.

Unfortunately I do not have editbugs permissions at present, so I must post this as a follow-on comment. I will look into the possibility of changing those permissions for future posts.

In the lead up to the October 1 CRL disclosure deadline from Apple and Mozilla, we at Sectigo used the CCADB API to ensure that the “Full CRL Issued By This CA” field was populated for all the disclosed and unexpired intermediate certificates issued directly by Sectigo. We noticed that two of our intermediates showed as lacking CRL disclosures using crt.sh’s views (here and here) of the CCADB data and CRL disclosure requirements. We knew that these two intermediate CAs, externally operated by Apple, had not yet issued any certificates. A previous m.d.s.p thread had begun to discuss adding an exception to the CRL disclosure requirements in such cases, but the proposed resolutions had not been implemented in the two root store policies. The m.d.s.p message from us referenced above was to revive this discussion.

Since then, the Apple Root Program Policy has been updated with an exception in such cases and Mozilla has stated its intention to update its policy as well. Sectigo considered the matter internally and came to the conclusion that the published Mozilla Root Store Policy takes precedence over Mozilla’s stated intentions for a future version of the Mozilla Root Store Policy and therefore not disclosing CRLs for these Apple intermediate certificates would constitute an incident.

As mentioned above, we reached out to Apple to share our viewpoint and the rest is as reported in comment 0 and comment 1.

I don't think that Mozilla considers this an "incident" but a "disclosure", so I'm going to tag this on the whiteboard as informational, and I'll close it. However, comments can be posted here for purposes of continuing the discussion.

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Whiteboard: [ca-compliance] → [ca-informational]
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.