This means that the affected certificate is an Electronic Seal Certificate pursuant eIDAS, and NOT an SSL Certificate.
I appreciate the clarification, but that was clear from your original message. However, that doesn't address the concern or the expectation.
https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report specifically requests:
In a case involving certificates, the complete certificate data for the problematic certificates.
The reason this exists is so that the CA can factually demonstrate the data, and not just their conclusions. Put differently, we need Firmaprofesional to demonstrate it's not a TLS certificate, and not just state it's not a TLS certificate. Past CA incidents have shown an unfortunate pattern of CAs making mistakes in their judgement and evaluation, and that's part of why the full certificate data helps address this.
We attach here details to identify the affected certificate:
CN=AC Firmaprofesional - CUALIFICADOS,
Serial number: 3932b3f9931f1b4ed0b4a9a4147397ca
NotBefore: miércoles, 8 de julio de 2020 13:10:31
NotAfter: sábado, 8 de julio de 2023 13:10:21
SKI: 0x373F 317B 52ED DDC0 321E 1BCF 4624 0830 1B6B 832A
OID: 18.104.22.168.4.1.1322.214.171.124.2 (see: Firmaprofesional Certificate’s Profiles Document (https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_Perfiles_Certificados-210322-EN-sFP.pdf) and CP Electronic Seal Certificates (https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CP_SelloElectronico-210217-EN-sFP.pdf) for details on the kind of
We cannot attach the certificate due to data protection regulation (RGPD) and the certificate is not in “Certificate transparency” because it is not a QCP-w, so there is no public link to the certificate.
Also, an independent auditor is stating that the affected certificate is a QCP-l, and not a QCP-w .
Although it is true that there are two different incidents reported in this bug, we have considered that they should be reported together as such for several reasons:
That's a very audit-centric approach, but that's not the approach we take with incident reports. We want to understand relevant timelines, root causes, and steps taken. While they're shared in terms of "what auditable control was missed", they're clearly very different in terms of relevant facts and root causes, and we want to treat them independently. In the future, even if you have only a single finding on the audit, based on some auditable control, we want to see distinct incident reports for the different types of failures.
We agree with you on this. It would be easier to follow the different timelines of the different issues. We will do so in the future!
Just to clarify, as we proposed, one part is already managed in Bug 1700145 and we keep dealing with the other one in this ticket.
Comment #5 gets to what I was raising in Comment #1: Namely, 9.16.3 of the BRs is an incredibly important provision, and any CA relying on any special government dispensation or instruction needs to be intimately familiar with the expectations, since any deviation on the basis of third-party advice (e.g. auditor and/or government and/or contractual requirements) is grounds for immediate removal. While I'm encouraged to see that acknowledged, I share (some of) Matthias' concerns in Comment #6, namely that it is not actually clear what happens in practice. Given that we've seen a spate of CA issues where the CP/CPS states one thing, but the CA performs another, it's absolutely critical that the CA make sure their CP/CPS is clear and unambiguous about what is done.
(and In reply to Matthias from Comment # 9)
I believe that the kind of certificate is only important if you distinguish between different certificate profiles in relevant sections of your Certification Practices Statement, or when determining if a certificate complies with the BR. My comment was about your CPS, in a section where certificate profiles were not mentioned, and as such the kind of certificate is not important in my argument.
Because there is no distinction between certificate profiles in section 3.1.4 of your CPS, and with the comments you've made above regarding how that section came to be, the wording of "without character limits" in that section should be either removed, limited to certificates issued under a CA that is not server nor email-enabled‡, or properly disclosed under the guidance of BR s9.16.3.
‡ assuming that those restrictions are enough to exclude such leaf certificates from the requirements of the MRSP and BR/OV Guidelines.
We want to clearly state here that:
1. The BR prevail with respect to our CPS and
2. In any case we always comply with the RFC5280.
We consider that we are aligned with the RFC in accordance with the first paragraph of the section 3.1.4: Firmaprofesional complies in any case with what is marked by the X.500 reference standard in ISO / IEC 9594, thus as per RFC 5280 and the CA / Browser-Forum Requirements (Baseline Requirements and EV Guidelines).
Since our aim and what we declare is that we fully comply with the BR, we think that it is not needed to use the BR s9.16.3 section. As you say, if we finally find a case in which the character limits of the RFC, or other requirements established by the BR, should not be respected, we, prior to issuing a certificate under the modified requirement) would notify the CA/Browser Forum and we would take all the steps stated in BR s9.16.3 section.
We agree with you both, Matthias and Ryan, that the paragraph “The information in the fields of the certificates linked to data of the natural or legal person that appear in the official records must be exact, without character limits and in accordance with said official sources” could be misinterpreted and lead to ambiguous interpretation, so we propose to delete it completely and adding the following paragraph: “In the event of any inconsistency between this CPS and the previous documents, these documents will prevail over this CPS.” to reinforce the idea in point 9.14 and not leave room for ambiguity.
The result would be:
3.1.4. Rules for interpreting various name forms
In all cases Firmaprofesional follows the rules set out in the reference standard X.500 in ISO/IEC 9594, as well as by RFC 5280 and by the CA / Browser-Forum (Baseline Requirements and EV Guidelines).
In the event of any inconsistency between this CPS and the previous documents, these documents will prevail over this CPS. If you agree we will make these changes to our CPS.
Where I disagree with Comment #6, and what Dimitris was highlighting in Comment #2, is that in this case, RFC 5280 is actually more lax, and so there may not actually be a violation here. Thus, my primary concern with this incident report was
- That Firmaprofesional didn't perform a detailed analysis of RFC 5280, either beforehand or with their auditor, to be able to evaluate and reach this conclusion.
- That Firmaprofesional suggested that government orders would be taken over compliance with the BRs and root program requirements, in the event of conflict.
In this regard, the incident report in Comment #0 neither makes it clear the analysis performed (simply that AENOR rejected it, without explanation from AENOR) nor the process that Firmaprofesional has in place to do such evaluations.
I would appreciate your clarifications around this incident, the timeline and facts considered, and the steps you're taking in the future to better address such issues. Notably, I also want to highlight the expectation of incident reports, and the disclosure to root programs promptly - i.e. even if the auditor doesn't issue a finding. This has been something repeatedly communicated with Firmaprofesional, and would be unacceptable if the next audit cycle also saw late-disclosed incidents.
On March 22, the auditors indicated to Firmaprofesional a possible finding with the limits established by RFC5280 in certain fields of QCP-l certificates (not QCP-w).
On March 24, we started an investigation in two lines: on the one hand, the limits of the fields in the RFC and on the other hand, the legal requirements, because it was a QCP-l certificate.
On March 29, Our conclusion is that we were NOT in breach of the RFC, but we admit that, as seen later, it is a controversial and ambiguous issue and on which it is difficult to find consensus. There is a discrepancy of criteria with the auditor regarding compliance with the RFC. Our criteria is that we do not violate the RFC while the auditor insists that we do.
Because it is an eiDAS audit, the auditor not only reviews the RFC compliance also reviews compliance with European legislation. In this sense, we proposed that, since it is a QCP-l certificate (it is not a certificate intended to be used for authenticating servers accessible through the Internet), and following the criteria of the Ministry, it was necessary to maintain that length in the fields, which, in addition, according to our criteria and as seen in the discussion maximum allowed size of the subject:givenName, subject:surname, does not violate RFC5280.
On April 8, Firmaprofesional rejected the non-conformity based on previous opinions of the Ministry for similar cases.
On May 13, the auditors allege that the Ministry's previous opinion refers to QCP-n certificates (they are neither a certificate intended to be used for authenticating servers accessible through the Internet) and not QCP-l.
On May 26, the Ministry answered clarifying that it is not a Spanish or European legislation’s breach: "The requirements established in the eIDAS Regulation are technologically neutral and compliance with standards or specifications provides a legal presumption of compliance" .
Finally, in future occasions, when there are discrepancies between the auditors and our interpretation of a possible finding, we will launch a public discussion to verify which is the valid criterion, a fact that will help both the community and us in the specific case.