Closed Bug 1688215 Opened 3 years ago Closed 3 years ago

Camerfirma: CP/CPS of Intesa Sanpaolo Sub-CA is Non-Compliant

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: ana.lopes)

Details

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

The CP/CPSes for Intesa Sanpaolo Organization Validation 2019 CA and Intesa Sanpaolo Organization Validation CA have the following deficiencies:

  1. They do not specify which subsection(s) of BR 3.2.2.5 are used for domain validation, as required by Mozilla Policy 2.2(4).

  2. They do not specify which domains are used for CAA, as required by the BRs.

Note that the exact same problems were reported with Camerfirma's own CPS in 2018: https://bugzilla.mozilla.org/show_bug.cgi?id=1478933#c16

Camerfirma fixed their own CPS but evidently did not conduct a comprehensive review of all the CPSes in their hierarchy. This provides another example of Camerfirma's poor incident response practices, and of their poor supervision of sub-CAs.

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

Ben: I believe this should be added to the wiki, for completeness sake.

Flags: needinfo?(bwilson)

Please, find the incident report below for more details:

  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.
    We became aware of the problem on January 22nd because of this bug opened by Andrew Ayer.

  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.
    First of all, we want to inform you that the latest and current version of the CPS for the two Intesa Sanpaolo CAs is version 1.7, which was published on October 29th, 2020.

  3. As soon as the bug was opened, we started the review of those points in the CPS (January 22nd).
    After reviewing this latest version of the CPS – in order to find out which information required by subsection(s) of BR 3.2.2.5 are used for domain validation, as required by Mozilla Policy 2.2(4) and which domains are used for CAA, as required by the BRs – we have verified that the said information has not been properly included in it.

  4. Once we analyzed the correct information that Intesa Sanpaolo has to include in those points of the CPS, they started the process to include the updates and approve a new version. (January 27th). This process will finish by February 5th with the publication of the new CPS.

  5. 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.
    N/A. This incident does not affect certificate issuance.

  6. 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.
    N/A. We do not have affected certificates.

  7. 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.
    N/A. We do not have affected certificates.

  8. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
    We have not been reviewing our SubCAs CPSs because we trusted them, as they are liable to maintain the documentation properly updated.
    We make them complete all the CA questionnaires every time needed, in order to make clear for them all the changes in the BRs and policies. They also must apply all the changes necessary to comply with them.
    From now on, we are involved in periodic reviewto audit all our SubCAs CPSs to ensure that they comply with all the given requirements. (This task has been defined as “Action Point 10” in the plan shared in the public discussion: https://groups.google.com/g/mozilla.dev.security.policy/c/dSeD3dgnpzk/m/diOfeWNpBQAJ?pli=1 and will be finished by the end of June).

  9. 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.

  10. Make the appropriate changes and publish a new version of the CPS to comply with the given requirements. (completed on January 27th).

  11. Approve the new CPS version (by February 5th).

  12. From now on, we are involved in a periodic review to audit all our SubCAs CPSs to assure that they comply with all the given requirements. (This task has been defined as “Action Point 10” in the plan shared in the public discussion: https://groups.google.com/g/mozilla.dev.security.policy/c/dSeD3dgnpzk/m/diOfeWNpBQAJ?pli=1 and will be finished by the end of June).

  13. When we finish the first review, we will audit periodically the SubCAs in order to grant that everything is quickly and properly updated (once a year from June 2021).

Please, find the incident report below for more details:

  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.
    We became aware of the problem on January 22nd because of this bug opened by Andrew Ayer.

  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.
    First of all, we want to inform you that the latest and current version of the CPS for the two Intesa Sanpaolo CAs is version 1.7, which was published on October 29th, 2020.
    2.1. As soon as the bug was opened, we started the review of those points in the CPS (January 22nd).
    After reviewing this latest version of the CPS – in order to find out which information required by subsection(s) of BR 3.2.2.5 are used for domain validation, as required by Mozilla Policy 2.2(4) and which domains are used for CAA, as required by the BRs – we have verified that the said information has not been properly included in it.
    2.2 Once we analyzed the correct information that Intesa Sanpaolo has to include in those points of the CPS, they started the process to include the updates and approve a new version. (January 27th). This process will finish by February 5th with the publication of the new CPS.

  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.
    N/A. This incident does 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.
    N/A. We do not have affected certificates.

  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.
    N/A. We do not have affected certificates.

  6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
    We have not been reviewing our SubCAs CPSs because we trusted them, as they are liable to maintain the documentation properly updated.
    We make them complete all the CA questionnaires every time needed, in order to make clear for them all the changes in the BRs and policies. They also must apply all the changes necessary to comply with them.
    From now on, we are involved in periodic reviewto audit all our SubCAs CPSs to ensure that they comply with all the given requirements. (This task has been defined as “Action Point 10” in the plan shared in the public discussion: https://groups.google.com/g/mozilla.dev.security.policy/c/dSeD3dgnpzk/m/diOfeWNpBQAJ?pli=1 and will be finished by the end of June).

  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.
    7.1. Make the appropriate changes and publish a new version of the CPS to comply with the given requirements. (completed on January 27th).
    7.2. Approve the new CPS version (by February 5th).
    7.3. From now on, we are involved in a periodic review to audit all our SubCAs CPSs to assure that they comply with all the given requirements. (This task has been defined as “Action Point 10” in the plan shared in the public discussion: https://groups.google.com/g/mozilla.dev.security.policy/c/dSeD3dgnpzk/m/diOfeWNpBQAJ?pli=1 and will be finished by the end of June).
    7.4. When we finish the first review, we will audit periodically the SubCAs in order to grant that everything is quickly and properly updated (once a year from June 2021).

We continue with the plan to have the CPS updated by February 5th.

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
Resolution: --- → FIXED
Product: NSS → CA Program
Whiteboard: [ca-compliance] → [ca-compliance] [policy-failure]
You need to log in before you can comment on or make changes to this bug.