Closed Bug 1578505 Opened 2 years ago Closed 1 year ago

LuxTrust: Outdated audit statement for intermediate cert

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kwilson, Assigned: ca)

Details

(Whiteboard: [ca-compliance] - Overdue Audit for intermediate cert)

The following intermediate cert has an outdated audit statement.

Please update its record in the CCADB with the current audit statement information as soon as possible.

https://ccadb.org/cas/intermediates

Please also provide an Incident Report for having an overdue audit statement.
https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

CA Owner: LuxTrust

  • Certificate Name: LuxTrust Corporate CA
    SHA-256 Fingerprint: AE373E488DD13DEF71611D52F0B5179DD648241A381F67A80734F6615FF6E6CA
    Standard Audit Period End Date (mm/dd/yyyy): 03/30/2018
Assignee: wthayer → ca.luxtrust

This intermediate CA was audited at the same time as the other CAs. This is an omission in the attestation letter.
We have requested on September 4 to the auditor to provide us an updated attestation letter.
we will update it in the CCADB upon receipt.
To prevent this from happening again, a 4-eye verification process is in place for this type of document.

(In reply to ca from comment #2)

The updated attestation letter is available here : http://lsti-certification.fr/images/LSTI_Audit_Atttestation_Letter_11085-124_V20_Luxtrust.pdf

I confirm that the audit attestation letter has been added to the record in the CCADB, and that Audit Letter Validation (ALV) passes (with the exception of the audit date being over 3 months after the audit period end date due to the audit statement being re-issued). So I was about to close this bug as resolved, but decided to check the other intermediate certs...

The following intermediate cert is said to have "Audits Same as Parent", but ALV does not find it in the parent's audit statement, and I don't find it either.

Subject: CN=LuxTrust Global Qualified CA 3; O=LuxTrust S.A.; C=LU
Issuer: CN=LuxTrust Global Root 2; O=LuxTrust S.A.; C=LU
SHA-256 Fingerprint: BED0F19ED46D94900D2A9FCD7C6F660B61FF7588D8B71CF8F279D5FAA3021CCF

Please resolve and also provide an Incident Report about these intermediate certs not being in audit attestation letters:

https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

There does not appear to be an incident report on this issue, as requested by Kathleen in Comment #3.

Flags: needinfo?(ca.luxtrust)
  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.
    => Our CA first became aware of the problem via a Bugzilla bug on 2019-09-20 at 18:58.

  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.
    => Our CA took the following actions in response:

  • 2019-09-23 at 08:54: our CA requested an updated attestation letter from the CAB
  • 2019-10-22 at 14:36: our CA received an updated attestation letter
  • 2020-02-04: our CA uploaded the updated attestation letter in the CCADB
  1. 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.
    => The incident was due to a wording oversight and not an operational or a security issue. Hence our CA has not stopped issuing certificates.

  2. 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.
    => Not applicable: the incident was due to a wording oversight, hence there were no problematic certificates.

  3. 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.
    => Not applicable: the incident was due to a wording oversight, hence there were no problematic certificates.

  4. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
    => The “Audits Same as Parent” has been mistakenly ticked off.
    => The audited CAs, as part of the eIDAS audit, were not mentioned in the attestation letter because there was a misunderstanding with the certification body/LuxTrust and Mozilla regarding the following requirements:
    1. BR Section 1.1: “These Requirements only address Certificates intended to be used for authenticating servers accessible through the Internet.”
    2. The Mozilla's Root Store Policy section 5.3.2. requires in summary that all intermediate CA must be audited

  5. 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.
    => Our CA is taking the following actions to resolve the situation and to avoid such issues in the future:
    The Mozilla's Root Store Policy section 5.3.2. requirement has been clarified and from now, any new attestation letter will mention all intermediate CA, including those CAs in the eIDAS scope.
    To avoid delays in CCADB publications, the procedure for supervising Mozilla notifications has been strengthened and regular reminders have been added in the calendar of the persons responsible for monitoring the update of the attestation letter and its publication in CCADB.

019-10-22 at 14:36: our CA received an updated attestation letter
2020-02-04: our CA uploaded the updated attestation letter in the CCADB

This is a significant and meaningful gap, and the incident report does nothing to address why this gap was so significant and what's been done to correct it.

The closest that can be seen is "To avoid delays in CCADB publications", but that woefully fails to acknowledge there was an issue, what caused it, or how the proposed calendar reminders are supposed to ensure things. For example, if staff turnover happens, there's no assurance that the new calendar reminders will be created.

Flags: needinfo?(ca.luxtrust) → needinfo?(ca)

I am checking in on the status of this bug. It appears we are still awaiting a response from LuxTrust.

Assignee: ca.luxtrust → ca
QA Contact: wthayer → bwilson
Status: NEW → ASSIGNED

Closing this bug.

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Flags: needinfo?(ca)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.