Firmaprofesional: 2022 - CPS without correct explanation about difference between OCSP and CRL
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: mprieto, Assigned: mprieto)
Details
(Whiteboard: [ca-compliance] [policy-failure] [audit-finding])
Steps to reproduce:
The TSP supports multiple methods (CRL and OCSP) to provide revocation status. However, delays in updating the status information between both methods exist, but the TSP has not documented in its CPS the origin of such delays and how to interpret the results in case of differences.
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.
It is a finding identified during the annual eIDAS/ETSI audit being carried out these days.
Actual results:
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.
Does not apply, since Firmaprofesional is not only fulfilling but exceeding root programs and CA/Browser Forum requirements.
Indeed, our CPS in section 4.9.7 say: “The CRL of the end entity certificates are issued at least every 24 hours, or whenever a revocation occurs, and is valid for 7 days.”
And in CPS section 4.9.10 say ”Information provided via OCSP service is updated at least every four days”
Additionally Firmaprofesional OCSP responses for TLS certificates have a validity interval of 24 hours.
However, Firmaprofesional will share the steps that have been taken to solve this ETSI requirement:
Firmaprofesional had previously modified the CPS in this point (section 4.9.7) with the sentence “The CRL does not contain the expired certificates”.
When a certificate is revoked in Firmaprofesional, its status is immediately updated in the OCSP service and there is a maximum delay of 30 minutes until an updated CRL is published.
We will add information in the CPS clarifying that during that period of time, the correct information on the status of the certificate is offered by the OCPS service.
Firmaprofesional will publish a new CPS adding an explanatory paragraph of these cases.
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.
Does not apply.
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.
Does not apply.
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.
Does not apply.
Expected results:
6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
See point 2
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.
Firmaprofesional will publish a new CPS adding an explanatory paragraph of these cases.
Updated•2 years ago
|
Assignee | ||
Comment 1•2 years ago
|
||
Confirming that as the CPS has been updated and published today on June 23, 2022, we consider this issue resolved.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•1 year ago
|
Description
•