Closed Bug 1671410 Opened 4 years ago Closed 3 years ago

IdenTrust / ISRG: Inconsistent Disclosure of Externally-Operated Intermediate

Categories

(CA Program :: CA Certificate Compliance, task)

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

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: agwa-bugs, Assigned: roots)

Details

(Whiteboard: [ca-compliance] [disclosure-failure])

IdenTrust has disclosed the following intermediate as being operated under the same CP/CPS as parent:

https://crt.sh/?sha256=730C1BDCD85F57CE5DC0BBA733E5F1BA5A925B2A771D640A26F7A454224DAD3B

However, the same subject and SPKI is found in this intermediate, which ISRG has disclosed as being operated under their CP/CPS:

https://crt.sh/?sha256=67ADD1166B020AE61B8F5FC96813C04C2AA589960796865572A3C7E737613DFD

ISRG has previously asserted that they operate this subject, so I assume that IdenTrust has incorrectly disclosed this intermediate.

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

Mr. Ayer is right, the ISRG subordinates signed by the IdenTrust DST CA X3 root are operated under ISRG's CP/CPS. We have corrected the entries in Mozilla's CCADB accordingly.

I believe this bug can be closed. I'll schedule it for closure on or about 23-October-2020 unless there are other issues to discuss.

Flags: needinfo?(bwilson)

This was a failure to follow Mozilla policy, and as such this is an incident and IdenTrust should be required to file an incident report per https://wiki.mozilla.org/CA/Responding_To_An_Incident and as has been required in the past for the failure to properly disclose intermediates (e.g. #1647084). Proper disclosure is important for transparency, and based on Comment 1 there is no reason to believe that this won't happen again, or that there aren't other intermediate certificates issued by IdenTrust that are not properly disclosed.

I don't see how this was a failure to follow policy or was the non-disclosure of a CA. I think this falls short of requiring an incident report, but I'll see what others think.

Ben: Could you help explain your reasoning? Mozilla has absolutely consistently treated this as an incident, so Comment #2 sounds like a significant change in policy.

Past incidents:

See also past m.d.s.p discussion.

I'm not sure I understand your Comment #4, but it would appear by that logic, Identrust could have said the CPS was at https://www.honest-cas-used-certs.example and, as long as that pointed to a document, it wouldn't matter that the CA referenced was not actually operated according to that CPS. Much like a failure to disclose at all would be a grave and serious issue, and improper disclosure, as this clearly is (Comment #1), are very deserving of an incident report. Even more so, given the past discussion.

Ryan, The only situation from the four you cite where the CA filed an incident report was here - https://bugzilla.mozilla.org/show_bug.cgi?id=1647084#c2 (in response to my question whether an incident report should be required).
So, I'll wait to hear from any others on this issue. I think Identrust has an argument that the Let's Encrypt CA was operated under their infrastructure, CPS, etc. The CA certificate was issued by them, and they would be responsible for having issued it, what happens under it, etc. There is at least a gray area, here, I believe.

Section 4 of the Mozilla Root Store Policy states:

CAs with certificates in Mozilla’s root program MUST use the CCADB, and are bound by the latest published version of the Common CCADB Policy, which is incorporated here by reference.

Section 5 of the Common CCADB Policy states:

The entry for each intermediate certificate has “Audits Same as Parent” and “CP/CPS Same as Parent” checkboxes. When those are checked, the details do not need to be duplicated from the parent cert. However, the intermediate certificate must be specifically listed in the audit statements of the parent certificate.

URLs for the following documents are required for each certificate, unless the exceptions below apply:

Certificate Policy (CP)
Certificate Practice Statement (CPS)
Standard audit (WebTrust or ETSI)
Baseline Requirements (BR) audit (if the certificate is capable of issuing TLS/SSL server certificates)
Extended Validation (EV) SSL and/or Code Signing audit (if applicable)

None of the enumerated exceptions apply to this case, which makes this a clear cut violation of Mozilla Policy.

Additionally, Section 1 states:

CAs have an overarching responsibility to keep the information in the CCADB about themselves, their operations and their certificates accurate,

Relying parties use the information in the CCADB to determine what organization was responsible for issuing a certificate, and to know who controls what are essentially the keys to the Internet. When a CA erroneously checks the "Same as Parent" boxes, it deprives relying parties of this information. The only way third parties can reliably detect when this happens is when the subject+SPKI of the wrongly-disclosed intermediate also exists in a certificate disclosed by a different member of the Mozilla root program as being operated by them. This is obviously not the case for all externally-operated intermediates, so when a discovery like this is made there is a concern that it's only the tip of an iceberg. That's why it's so important to have an incident report - the community needs assurance that the CA has a reliable process for accurately disclosing externally-operated intermediates.

So, I think I see part of your argument. An incident report helps the community understand what has happened, e.g. potentially the relationship between ISRG/Let's Encrypt and Identrust that would have caused this confusion? It may not be obvious that Identrust is responsible for reporting in the CCADB the certificates that it issues under its roots. Access rights in the CCADB only allow Identrust to do that. Here Identrust should have coordinated with ISRG to get the correct CP/CPS and audit information and input it correctly into the CCADB. Finally, I think there is a gap in the CCADB policy. It does not specify what to do with newly created subordinate CAs (in between audits), but maybe that was intentional because that situation is not included in the list of exceptions.

It may not be obvious that Identrust is responsible for reporting in the CCADB the certificates that it issues under its roots

Actually, the Mozilla Root Store Policy is clear about this.

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited says (emphasis mine):
"All certificates that are capable of being used to issue new certificates, that are not technically constrained, and that directly or transitively chain to a certificate included in Mozilla’s root program...MUST be publicly disclosed in the CCADB by the CA that has their certificate included in Mozilla’s root program. The CA with a certificate included in Mozilla’s root program MUST disclose this information within a week of certificate creation, and before any such subordinate CA is allowed to issue certificates"

(In reply to Ben Wilson from comment #6)

So, I'll wait to hear from any others on this issue. I think Identrust has an argument that the Let's Encrypt CA was operated under their infrastructure, CPS, etc. The CA certificate was issued by them, and they would be responsible for having issued it, what happens under it, etc. There is at least a gray area, here, I believe.

I don't believe there's a gray area at all here. Mozilla explicitly makes it clear that the Root CA is responsible to

ensure that all certificates within the scope of this policy, as described in Section 1.1, adhere to this policy

This same intent is captured by the fact that Mozilla requires complete (transitive) disclosure, and holds the Root CA accountable for everything issued beneath the Root's hierarchy, even if the Root may have cross-certified an additional a CA that is also a member of the Mozilla Root Program.

I'm surprised to hear the suggestion that this is a gray area, because this has been one of the most clearcut requirements that has underscored most of Mozilla's root program operation, including the decision to ultimately remove trust in Symantec.

(In reply to Ben Wilson from Comment #8)

It does not specify what to do with newly created subordinate CAs (in between audits), but maybe that was intentional because that situation is not included in the list of exceptions.

This was previously discussed and resolved

A newly created subordinate CA is created and operated according to a CPS, and the issuing CA knows that CP/CPS and relevant policies. This has been settled now for nearly two years, in which the CA discloses that CP/CPS, and the CA is explicitly expected to be listed within the next year's audit to the point of key creation, as already noted in Issue 153

Thanks. This is very helpful. I would like Identrust to prepare an incident report for this.

Flags: needinfo?(bwilson) → needinfo?(roots)

(In reply to Rob Stradling from comment #9)

It may not be obvious that Identrust is responsible for reporting in the CCADB the certificates that it issues under its roots

Actually, the Mozilla Root Store Policy is clear about this.

What I meant is that it may not be obvious to some people.

We acknowledge the requirement to supply a formal incident report and will be supplying one no later than Friday October 24, 2020.

Flags: needinfo?(roots)

  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.
    IdenTrust:
    On October 15, 2020 via this Bugzilla bug we were made aware of an incorrect disclosure of a subordinate CA signed by the IdenTrust DST Root CA X3.

  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.
    IdenTrust:
    September 30, 2020: Issued 2 subordinate CA’s (R3 &R4) signed by the IdenTrust DST Root CA X3.
    September 30, 2020: Disclosed those 2 subordinate CA’s into Mozilla’s CCADB
    October 7, 2020: Re-signed/revoke the 2 subordinate CA’ as they were missing EKU extension for which a separate incident report was filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1669594
    October 7, 2020: Updated Mozilla’s CCADB reflecting the revocation status of the 2 revoked subordinate CA’s and disclosed the resigned versions.
    October 15, 2020: Learned of the incorrect disclosure.
    October 16, 2020: Upon review, we found that this subordinate CA along with 5 others for the same entity were timely disclosed in Mozilla’s CCADB but flagged in error as being operated under IdenTrust CP/CPS when they are in fact externally operated with their own policy documents. Corrected the discrepancy in CCADB for the reported subordinate as well as for other 5 subordinate CAs with the same issue.

  3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.
    IdenTrust:
    Not applicable as no mis-issuance has occurred.

  4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
    IdenTrust:
    We found a total of 6 subordinate CA certificates signed by the IdenTrust DST Root CA X3 correctly issued and disclosed in Mozilla’s CCADB, but with the wrong flag for the ruling CP/CPS.

  5. 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.
    IdenTrust:
    https://crt.sh/?id=3470671161
    https://crt.sh/?id=3470671160
    https://crt.sh/?id=10235198
    https://crt.sh/?id=10970235
    https://crt.sh/?id=15706126
    https://crt.sh/?id=15710291

  6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
    IdenTrust:
    During the timely disclosure, we flagged the wrong option within the CCADB which we have now corrected accordingly. In the correction process, we updated the required details not only for this subordinate CA, but also for other 5 subordinate CA’s that had the same issue.

  7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
    IdenTrust:
    The current process for handling updates in Mozilla’s CCADB is done by the program management team exclusively. For future CCADB updates, effectively immediately, we have added a step involving the internal audit compliance area acting as dual-check control on any CCADB updates, before saving.
    The added dual-control validation from a different area within the company should help reduce the likelihood of repeating this incident.

I see that two of the certificates from your report were listed at https://crt.sh/mozilla-disclosures#disclosedwithinconsistentaudit since 2020-08-25.

https://crt.sh/?id=15706126
https://crt.sh/?id=15710291

Have you reviewed the other IdenTrust certificates listed there?

Checking at the report pointed by Mathew Hodson on comment 16, the 2 missing subordinate CA's that are NOT included here on item 5 of the incident report are subordinate CA's R3 and R4. By mistake, we reported the revoked versions of those. The correct certificates for those 2 subordinates that were corrected in CCADB are:
https://crt.sh/?id=3479778542
https://crt.sh/?id=3479778543

Flags: needinfo?(bwilson)

Are there any additional comments, concerns, or issues to address in relation to this matter? If not, I intend to close it on or about 22-Jan-2021. Thanks to those who provided feedback already.

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
Product: NSS → CA Program
Whiteboard: [ca-compliance] → [ca-compliance] [disclosure-failure]
You need to log in before you can comment on or make changes to this bug.