Closed Bug 1672029 Opened 4 years ago Closed 3 years ago

Camerfirma: Failure to abide by Section 8 of Mozilla Policy: Unauthorized, improperly disclosed Subordinate CA

Categories

(CA Program :: CA Certificate Compliance, task)

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

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: ryan.sleevi, Assigned: ana.lopes)

Details

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

As captured in Issue 169, which was addressed in Mozilla Policy 2.7, which is that prior to issuing an unconstrained subordinate CA to an entity that is not directly included within the Mozilla Root Store, prior public discussion and approval is required, as captured within Section 8 of policy.

As subordinate CAs are as powerful as root CAs, this is key to ensuring the community has the appropriate review and discussion about the subordinate CA.

It would appear Camerfirma has violated this, a potentially egregious repeat of Bug 1502957 which Policy 2.7 sought to make unambiguous.

Camerfirma has disclosed https://crt.sh/?q=0F17E376FE94E582D6EE649CDC516FF977E765C561AE087F31A3F5E8E66CCECD within CCADB as "Audit Same as Parent / CP/CPS Same as Parent". However, this is materially incorrect, in that this certificate is not disclosed within the relevant audit.

However, this certificate also chains to a CA that is not part of the Mozilla Root Program, operated by Multicert. Within CCADB, Multicert has disclosed a different version of this subordinate/SPKI as within the scope of Multicert's CP/CPS and audit, at https://crt.sh/?q=41E1F1B8DBDD05D8AD04F2CA8A7342F461D99D79E7B466D49284B1909C28E2D8

As mentioned, Bug 1502957 previously explored a similar situation, and revealed problematic controls and understanding of expectations on behalf of Camerfirma, and an inappropriate degree of supervision of sub-CAs. The resolution of those bugs suggested a next step was to take a holistic examination of Camerfirma and its continued role with Mozilla, in light of the issues with MULTICERT as well as two other CAs (InfoCert and Intesa Sanpaolo). Since then, we've seen more issues (e.g. Bug 1575530) with subCAs, as well as issues with the aforementioned sub-CAs (e.g. Bug 1668331)

Camerfirma folks: Please provide an incident report, as captured by https://wiki.mozilla.org/CA/Responding_To_An_Incident . This incident report must holistically cover the previous incident and why this has occurred. It must also specifically examine why Camerfirma has introduced a third-party into the Mozilla Root Program, in direct violation of Section 8 of Mozilla Policy. Note: It is not acceptable to highlight Camerfirma's previous relationship with Multicert, given the issues.

Flags: needinfo?(bwilson)
Flags: needinfo?(ana.lopes)

Hi Ryan,

After the publication of the version 2.7 – effective from January 1st, 2020, we have only issued SubCAs created as a substitution of old ones that will stopped been used for some different causes.

All the old SubCAs were created before that version as you can see on the list below:

InfoCert Organization Validation CA 3
https://crt.sh/?caid=54353

Intesa Sanpaolo Organization Validation CA
https://crt.sh/?caid=57139

MULTICERT SSL Certification Authority 001
https://crt.sh/?id=573264407

The SubCAs created as a substitution of the old ones are listed below:

InfoCert Organization Validation 2019 CA 3
https://crt.sh/?caid=153239

Intesa Sanpaolo Organization Validation 2019 CA
https://crt.sh/?caid=153236

MULTICERT SSL Certification Authority 005
https://crt.sh/?id=2926377689

We have always verified that the old problems with the certificates had been solved and the needed audits performed before the creation of the new certificates.

Regarding the mentioned subCA "MULTICERT SSL Certification Authority 005", it was issued as a substitution of the prior subCA "MULTICERT SSL Certification Authority 001" and it was not going to be controlled by a new third party.

In these cases, we followed the given instructions to incorporate a new CA in the CCADB that had not debuted yet, indicating “same as parent” until the audit was performed.

Concretely, it was done for the subCA "MULTICERT SSL Certification Authority 005", before performing the audit that covered the period: 2019-12-06 / 2020-04-06.

This subCA has not issued certificates yet.

Anyway, we catch the information, and it will be taken into account to notify all the new CA issuances in the future, even if they are renewals of old certificates.

Tomorrow, we will include an incident report.

Kind regards

(In reply to Eusebio Herrera from comment #1)

After the publication of the version 2.7 – effective from January 1st, 2020, we have only issued SubCAs created as a substitution of old ones that will stopped been used for some different causes.

That doesn't excuse the process. The CA is expected to give notice for participants that Mozilla does not have a direct relationship with. You can see this discussion for the introduction of this, precisely to ensure that Mozilla reviews the CP/CPSes for new entities.

In these cases, we followed the given instructions to incorporate a new CA in the CCADB that had not debuted yet, indicating “same as parent” until the audit was performed.

Please consider in your incident report that your framing of the question to Mozilla omitted the salient technical details, and the approach you used entirely failed to follow the discussions had in the past, in m.d.s.p. and CA incidents, regarding what this means. In particular, Camerfirma has mislead the community and misstated how this CA is operated: This was not issued under Camerfirma's CP/CPS, and is not operated according to Camerfirma's CP/CPS.

Please understand: This is an egregiously serious issue.

Hi Ryan
Regarding the notification, we consider that Mozilla already had a knowlege of Multicet. Audit and CPS was already disclosed in CCADB. https://ccadb.force.com/0011J00001HcKZoQAN. Obviously we will notify any change in the SubCAs from now on.

Regarding the incident report we do not fully understand your sentence:
"..that your framing of the question to Mozilla omitted the salient technical details, and the approach you used entirely failed to follow the discussions had in the past, in m.d.s.p. and CA incidents, regarding what this means"
Please, we would appreciate your clarification.

When we disclose the new Multicert SubCA we open a case in CCADB and we placed "same as parent" value in the audit and CPS. We will update the audit report in April 2021 where the new SubCA will be included. I think there is not an issue here. Regarding the CPS we will update the CCADB immediately and we will investigate why we are delayed to do that.

Agree it's a very concerning issue for us, and in any way it's our aim to mislead the community.

Regards
Ramiro

(In reply to Ramiro Muñoz Muñoz from comment #3)

Regarding the notification, we consider that Mozilla already had a knowlege of Multicet. Audit and CPS was already disclosed in CCADB. https://ccadb.force.com/0011J00001HcKZoQAN.

This would be relevant only if you were claiming MULTICERT is operating this certificate. Which you didn't, you claimed you operate this root, with no evidence yet, while MULTICERT has claimed they operate the certificate and key, and provided independent evidence to that effect in CCADB.

When we disclose the new Multicert SubCA we open a case in CCADB and we placed "same as parent" value in the audit and CPS. We will update the audit report in April 2021 where the new SubCA will be included. I think there is not an issue here. Regarding the CPS we will update the CCADB immediately and we will investigate why we are delayed to do that.

Are you saying MULTICERT has mislead the community, by disclosing in CCADB that they operate the CA according to their CP/CPS and it's part of their audit, as mentioned in Comment #0?

This should be simple:

  • Who generated the key?
  • Who performed the ceremony?
  • Under which CP/CPS was the ceremony performed?

MULTICERT has declared to the community MULTICERT did it. Camerfirma is declaring that Camerfirma did it. Something doesn't add up, and since it is Camerfirma that is the participant in the Mozilla Root Program, and Camerfirma that issued the certificate, we need Camerfirma to provide an explanation here.

This is critically relevant because we already discussed "Audit Same as Parent" in Bug 1502957

Hi Ryan,

I will try to solve your doubts below.
First of all, keep in mind that the certificate issued by this CA of MULTICERT is a cross certificate, so both roots, Camerfirma and MULTICERT, are involved in the activity and there exist one certificate issued by each of those CAs.

There are two registers on CCADB, one of them belonged to the root managed by Multicert
https://ccadb.force.com/0011J00001W2Rkp?srPos=1&srKp=001

And the other one belonged to the root managed by Camerfirma
https://ccadb.force.com/0011J00001hWGr1?srPos=0&srKp=001

In this case, it appears “Same as parent” in the audit until we receive the annual report from MULTICERT. It's important to mention that this SubCA has not issued a certificate yet.

Regarding your questions, please find the responses below:

Who generated the key?
The key is generated by Multicert ( an audit key cenremony report exists)

Who performed the ceremony?
In this case, two certificates are needed because it is a cross certificate, so two different ceremonies were performed, one for each CA to issue its own certificate.

Under which CP/CPS was the ceremony performed?
All the activity related to those certificates is performed under MULTICERT CP/CPS, as you can see in the information provided on CCADB: https://pki.multicert.com/docs/EN/MULTICERT_PJ.ECRAIZ_427_en.pdf

Regards
Ramiro

During the review process that we are performing we have detected that there have not been any comments from your part since our last answer.

We have no updates to share with you.

Do you need extra information about it?

If the CA private signing key is in possession of MULTICERT, and if MULTICERT obtains its own audits, then both CA certificates should be listed in the MULTICERT audit and the box "Audits Same as Parent" shouldn't be checked. So, with this confusion in the CCADB (https://ccadb.force.com/0011J00001hWGr1?srPos=0&srKp=001) I am still unclear on who controls the CA private key for the CA MULTICERT SSL Certification Authority 005.

We are tracking CAs by their subject public key info (SPKI), and the audit and CP/CPS information between records in the CCADB needs to be consistent for the same SPKI. See e.g. https://crt.sh/mozilla-disclosures#disclosedwithinconsistentaudit.
I have updated the CCADB record for the MULTICERT cross certificate to point to the last audit by APCER - https://apcergroup.com/images/site/downloads/Audit_Attestation_Letters/19_08_2020/I1002_v3b_EN_Audit_letter_eIDAS_WEB_MC_NQUAL_followup.pdf The SHA256 hash of 0F17E376FE94E582D6EE649CDC516FF977E765C561AE087F31A3F5E8E66CCECD will need to be in the next APCER audit of this CA.

We still need to resolve compliance with Section 8 of the Mozilla Root Store Policy with respect to MULTICERT, Intesa Sanpaolo, and any other externally operated third party CAs that would require review and discussion by the Mozilla community.

Hi Ben:
(in response to comment #7) Multicert controls the private key for the CA MULTICERT SSL Certification Authority 005.
(in response to comment #9) As we said in the previous comments, we did not consider that approval for those CAs was needed, because we have only issued SubCAs created as a substitution of old ones that will stopped been used for some different causes and we did not include any new CAs for new CA owners in any case.
Please, in order to clarify the information about audits and private key owners, find below the information about the SubCAs listed in comment #1:
-InfoCert Organization Validation CA 3
https://crt.sh/?caid=54353
Private key controlled by Infocert
Last audit report uploaded on CCADB was issued on January 21st, 2020.
CSQA has already performed the new audit for the last period and we are waiting for the final version to upload it on CCADB.

-Intesa Sanpaolo Organization Validation CA
https://crt.sh/?caid=57139
Private key controlled by Intesa Sanpaolo.
Last audit report was issued on January 21st, 2020.
CSQA has already performed the new audit for the last period and we are waiting for the final version to upload it on CCADB.

-MULTICERT SSL Certification Authority 001
https://crt.sh/?id=573264407
Private key controlled by Multicert.
Last audit report was issued on August 19th, 2020.

-InfoCert Organization Validation 2019 CA 3
https://crt.sh/?caid=153239
Private key controlled by Infocert.
Last audit report uploaded on CCADB was issued on March 16th, 2020.
CSQA has already performed the new audit for the last period and we are waiting for the final version to upload it on CCADB.

-Intesa Sanpaolo Organization Validation 2019 CA
https://crt.sh/?caid=153236
Private key controlled by Intesa Sanpaolo.
Last audit report was issued on March 16th, 2020.
CSQA has already performed the new audit for the last period and we are waiting for the final version to upload it on CCADB.

-MULTICERT SSL Certification Authority 005
https://crt.sh/?id=2926377689
Private key controlled by Multicert.
Last audit report was issued on August 19th, 2020.

Flags: needinfo?(ana.lopes)

I think there is an underlying issue - there is no express exception to Section 8 of the Mozilla Root Store Policy to allow CAs to proceed as "grandfathered" (and not have to satisfy MRSP Section 8 requirements). Section 8 says, "CAs SHOULD NOT assume that trust is transferable. All CAs whose certificates are included in Mozilla's root program MUST notify Mozilla if: ... an organization other than the CA obtains control of an unconstrained intermediate certificate (as defined in section 5.3.2 of this policy) that directly or transitively chains to the CA's included certificate(s)". It also says, "CAs should err on the side of notification if there is any doubt. ... If one of the above events occurs, Mozilla MAY require additional audit(s) as a condition of remaining in the root program. CAs are encouraged to notify in advance in order to avoid unfortunate surprises."

We continue working on this bug. For the moment, we can assure that no certificates have been issued yet with this MULTICERT SSL Certification Authority 005 and no certificate will issued until we clarify the situation.
We will update the information as soon as possible.

Update: In order to avoid problems with this SubCA we have decided to revoke MULTICERT SSL Certification Authority 005. We will update the information about the date to revoke as soon as possible.

We will revoke MULTICERT SSL Certification Authority 005 by February 12th.

The CA "MULTICERT SSL Certification Authority 005" has been revoked yesterday (February 9th).

We do not have more updates for this bug.

We do not have more updates for this bug.

We do not have more updates for this bug.

We do not have more updates for this bug.

We do not have more updates for this bug.

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.