1717795 - Firmaprofesional: 2021 Audit Report Finding 3 out of 3

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Maria Jose Prieto]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36

Steps to reproduce:

#3 The certificates analyzed are aligned with the RFC 5280 standard as well as with the ETSI EN 319 412 series with the following exceptions:

• 1.3.6.1.4.1.13177.10.1.21.2 (QCP-l): One certificate of the sample has been detected whose subject:givenName field is larger than the size allowed by RFC 5280.
• 1.3.6.1.4.1.13177.10.1.20.2 (QCP-w), 1.3.6.1.4.1.13177.10.1.3.10 (QCP-w) and 1.3.6.1.4.1.13177.10.1.3.1 (OVCP): The certificates do not include the certificate policy identifier beneath the CA/Browser Forum’s reserved policy OID (mandatory from September 30, 2020).
  3.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.
  In the last eIDAS audit carried out in March 2021.

Actual results:

3.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.
For 1.3.6.1.4.1.13177.10.1.20.2 (QCP-w), 1.3.6.1.4.1.13177.10.1.3.10 (QCP-w) and 1.3.6.1.4.1.13177.10.1.3.1 (OVCP): The certificates do not include the certificate policy identifier beneath the CA/Browser Forum’s reserved policy OID (mandatory from September 30, 2020):
On 2020-03-22 9:45, it was oppened this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1700145 and now This bug is closed because we have done all the things we had said we would do.
For 1.3.6.1.4.1.13177.10.1.21.2 (QCP-l, these are certificates for electronic seals, pursuant eIDAS. They are not SSL or have a ServerAuth EKU): One certificate of the sample has been detected whose subject:givenName field is larger than the size allowed by RFC 5280.
On 2021-04-08 This finding was initially rejected because the competent governmental body was consulted by Firmaprofesional in 2019 on a similar issue and Firmaprofesional was notified that in a discrepancy case between a technical standard with Spanish law, the latter prevailed over the standard.
On 2021-05-13 AENOR did not accept finding rejection. For this reason, the Corrective Action Plan (PAC) was modified by firmaprofesional and a new corrective action was introduced. This corrective action consists of asking the Ministry about this matter in order to clarify the steps that have to be taken. This question was done the same day (on 2021-05-13).
On 2021-05-26 The Ministry answered “there should be no limitation imposed by standards to indicate the exact data of the natural or legal person that appears in the official records". That is why Firmaprofesional considers that it is acting in accordance with the law and it is not necessary to make any changes in its way of acting.
The next release of Firmaprofesional’s CPS will have an update in section 3.1.4 in which is said “Certificate’s fields linked to data of the natural or legal person must appear, without character limits, exact and in accordance with official sources”.
3.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.
Firmaprofesional stopped the issuance of certificates affected by the mistake on March, 22nd, 9:30 am.
3.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.
Total number of affected certificates: 587
Date of first affected certificate issued by "AC Firmaprofesional - Secure Web 2020" (https://crt.sh/?CAid=180582): Oct, 6th 2020
Date of last affected certificate issued by "AC Firmaprofesional - Secure Web 2020" (https://crt.sh/?CAid=180582): March, 18th 2021
Date of first affected certificate issued by AC Firmaprofesional - Secure Web 2021" (https://crt.sh/?CAid=202947): March, 18th 2021
Date of last affected certificate issued by AC Firmaprofesional - Secure Web 2021" (https://crt.sh/?CAid=202947): March, 18th 2021

3.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.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1700145.

Expected results:

3.6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Although Firmaprofesional was diligent on dates for the addition of mandatory CA/B Forum OIDs to SSL certificate profiles, we make a typo defining the new profile.
This happened due to a lack of peer-review in the deployment of such change: one person from the Compliance department proposes the change, that is approved by the steering committee to be included in the public document of certificate profiles, then one person from the Technical department gathered this information from that document and implemented the change in a pre production environment and sends samples to the same Compliance person.
Additionally, although Firmaprofesional implements automated certlint validations previous to the issuance of certificates, certlint did not return any mistake. Please, understand that this is not an excuse at all, but a warning so other CAs can learn from our mistakes. We have to go further with automated validations.
Due to the fact that is a small typo in an OID not detected automatically, it also passed our quarterly internal audit, for Q4-2020. We will also require validation of the samples against the last version of certlint and zlint.

3.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.
DONE- March 22nd:
09:30 am: the issuance of SSL certificates is stopped
09:50 am: profiles updated in CA software
DONE- Regarding the root cause we will define a new procedure, more time-consuming but also far more reliable consisting on:
Person A of the Compliance department applies for a change, with information of: the change itself, why it is necessary, time to be on production, the original source of the requirement.
Person 1 of the Technical department deploys the change in pre production environment and makes samples that will add to the previous tiquet.
Person B of Compliance gets the ticket, checks the changes in the documentation and the samples and against the original source.
If everything is right, then the changes are sent to the Quality and Security Committee to approve its deployment in production environments.
DONE- Additionally we will improve the automatic verifications previous to issuance:
Adding zlint verifications. Estimated date: 21st April, 2021
Implementing a self updating certlint and zlint environment to use always last certlint libraries (via dockerization). Estimated date: 19th May, 2021
DONE- Finally, we will improve the quarterly internal audits making it necessary to verify against the last version of zlint and certlink libraries.

Comment 1

[Ryan Sleevi]

First, this report appears to be describing two separate, independent incidents: the incident covered in Bug 1700145, which was previously addressed, and a violation of RFC 5280.

Second, I see no actual disclosure of the certificate mentioned for violation of RFC 5280, just Firmaprofesional's assurance that it's not TLS. That doesn't inherently exempt it from Mozilla requirements, and so Firmaprofesional bears the burden of demonstration about this certificate.

Third, Firmaprofesional's proposed CP/CPS update appears to have the potential of being a BR violation in and of itself. While I realize it's a bit unfair to say "You're wrong, but I won't tell you why you're wrong", I am sincerely hoping that Firmaprofesional can perform a successful evaluation to determine why I would say this, and similarly suggest that other commenters fail to point out precisely why. Given the concerns around expectations, this is primarily meant to see if Firmaprofesional is capable of evaluating the BRs and determining why this proposed update would be so potentially problematic that, if enacted-as-proposed, might trigger a discussion about distrusting: that's how serious it is. My hope is this is just a failure to provide an effective incident report, and not actually a reflection of the underlying plan. If that's the case, it's an opportunity for Firmaprofessional to realize how serious it is to provide clear incident reports (as touched on in Bug 1717791, Comment #1).

The quality of this incident report is concerning (as more broadly covered in Bug 1717790, Comment #1). While I'm generally not one to harp on formatting, I believe the formatting here hides some of the seriousness of the issue (e.g. that this is two separate issues), and contributes to the difficulty to understand the full scope and impact of risk. More in the spirit of Bug 1717791, Comment #1 - and emphasizing the value that clear incident reports have in mitigating gravely serious concerns - I'd highlight that you can use Markdown in Bugzilla to help ensure the information is readable, in addition to ensuring that the information itself is useful and valuable to addressing the concerns.

Comment 2

[Dimitris Zacharopoulos]

I would also like to highlight discussions regarding the maximum allowed size of the subject:givenName, subject:surname fields that took place recently. Disclosure of such certificate(s) would help to see if indeed they are RFC 5280 violations or not.

Comment 3

[Maria Jose Prieto]

Dear Ryan,

Thanks for the bug formatting recommendations (Markdown in Bugzilla), we apply it in the answers now.
If you agree, let’s consider the finding regarding OIDs managed on Bug 1700145, and let us be more specific regarding the RFC 5280 finding.
The audit report expressly says that the affected certificate is a QCP-l and not a QCP-w. This means that the affected certificate is an Electronic Seal Certificate pursuant eIDAS, and NOT an SSL Certificate.

@Dimitris Zacharopoulos Thank you very much for the link maximum allowed size of the subject:givenName, subject:surname, it’s a really constructive comment. Reading this link, if we understand it well, we see that there is not even a violation of RFC 5280 because the number of characters in the given_name of the certificate should be <32k, what is a way long given name. In fact, the given_name length of the affected certificate is longer than 16 but shorter than 64: “Cristina Margatina”

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:

1. The two findings are enclosed in a single one categorized as “alignment with the RFC 5280 standard as well as with the ETSI EN 319 412 series”.
2. Firmaprofesional there has already been a specific bug (Bug 1700145), which is already closed, due to one of the incidents and therefore, we consider that this finding has already been dealt with independently.

Comment 4

[Matthias]

I'd like to mention that I too have concerns regarding Firmaprofessional's suggested CPS changes (like Ryan in his third point in Comment #1); and that this concern has not been addressed in this latest response.

Comment 5

[Maria Jose Prieto]

I'd like to mention that I too have concerns regarding Firmaprofessional's suggested CPS changes (like Ryan in his third point in Comment #1); and that this concern has not been addressed in this latest response.

Dear Matthias,
We attach the new CPS: ttps: //www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CPS-210628-EN-sFP.pdf

With update:
section 9.14 and 9.15 prevalence of the BR and EV Guidelines and resolution of conflicts with national law and
section 3.1.4 EV Guidelines reference and data requirements of natural or legal persons.

This means according to point 9.14 and 9.15 of our CPS, the BR and EV Guidelines prevail whenever there is a conflict between national law and these. Although in point 3.1.4 it is said that the names and surnames must always be put as they appear in the official documents, without limitation of characters. In this way, our national legislator is satisfied with compliance with the names appearing as they appear in the official records, while we guarantee that the BR and EV Guidelines will always prevail according to point 9.14 and 9.15 of our CPS.

To date, as we have already explained, we have not had any case in which the names are longer than 64 characters. If there is a conflict between both points, we know, according to point 9.16.3 of the BR, we must immediately notify the CA / Browser Forum and also notify the national legislative exceptions in point 9.16.3 of our CPS.

Comment 6

[Matthias]

Seeing that you've found my concern, but not exactly resolved my concerns:

The extra wording that was added to section 3.1.4 of your CPS (as a response to the communication on 2021-05-26 with this relevant Ministry) directly contradicts the limits that are posed by RFC 5280 (see page 124 of that RFC for actual numbers). It seems to me that this change in CPS is due to a government order (as specified under BR s9.16.3) and ignores limits set by RFCs and the BR / OV Guidelines, and thus would require handling as specified in BR s9.16.3.

Seeing that FirmaProfessional has knowledge of BR s9.16.3 (Comment #5), and assuming that FirmaProfessional has acted upon these requirements, I would like to know where I can find the (public) evidence that is available that FirmaProfessional has acted according to these requirements. I cannot find the evidence in the CPS section 9.16.5, nor section 9.15, nor in the public mailing list archives of the CA/B forum.

Lastly, you claim in Comment #5 that "the BR and EV Guidelines prevail whenever there is a conflict between law and these [in the CPS]", and that's a good thing to have. But regardless of that, there should not be any conflicts in your CPS that are resolved by such section, and if you know of the existance of such conflict, this conflict should be resolved as soon as possible as to not confuse the subscribers and/or relying parties. A 'if A and B conflict, then A prevales'-clause should be a last resort, not a go-to solution.

Comment 7

[Ryan Sleevi]

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.

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.

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.

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

1. 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.
2. 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.

Comment 8

[Maria Jose Prieto]

Seeing that you've found my concern, but not exactly resolved my concerns:

The extra wording that was added to section 3.1.4 of your CPS (as a response to the communication on 2021-05-26 with this relevant Ministry) directly contradicts the limits that are posed by RFC 5280 (see page 124 of that RFC for actual numbers). It seems to me that this change in CPS is due to a government order (as specified under BR s9.16.3) and ignores limits set by RFCs and the BR / OV Guidelines, and thus would require handling as specified in BR s9.16.3.

Seeing that FirmaProfessional has knowledge of BR s9.16.3 (Comment #5), and assuming that FirmaProfessional has acted upon these requirements, I would like to know where I can find the (public) evidence that is available that FirmaProfessional has acted according to these requirements. I cannot find the evidence in the CPS section 9.16.5, nor section 9.15, nor in the public mailing list archives of the CA/B forum.

Lastly, you claim in Comment #5 that "the BR and EV Guidelines prevail whenever there is a conflict between law and these [in the CPS]", and that's a good thing to have. But regardless of that, there should not be any conflicts in your CPS that are resolved by such section, and if you know of the existance of such conflict, this conflict should be resolved as soon as possible as to not confuse the subscribers and/or relying parties. A 'if A and B conflict, then A prevales'-clause should be a last resort, not a go-to solution.

Dear Mathias,

We are pleased that the resolution of the potential conflict of standards is well under way according to the BR and EV guidelines. There is always room for improvement!

After analyzing the discussion "maximum allowed size of the subject: givenName, subject: surname" we have understood that the consensus is that the limit is either 64 or 32k, and we think that this sentence is the key: "The current lints are based on ub -given-name-length and ub-surname-length, but these lengths are not used by the AttributeTypeAndValue field of the DN, but by the PersonalName / TeletexPersonalName of BuiltInStandardAttributes of an ORAddress”. Either way, the affected certificate givenname length is less than 64 characters.

Additionally, if we take into account the following statement: “After discussing this further (see sleevi/cabforum-docs#36 (comment)), it was determined that a 64-character limit for givenName and surname is the path forward.” CAs could not trust the responses of automated validation tools even for the fulfillment of requirements that they are supposedly checking, such as the length of the givenName and surname fields.

We think that this discussion is very useful for the community, and we would like to take advantage of it to clarify also for other CAs, what the accepted limits are.
Lastly, we think it is important to note that the affected certificate is a QCP-l (“Certificates issued under these requirements are aimed to support the advanced electronic seals based on a qualified certificate defined in articles 36 and 37 of the Regulation (EU) No 910/2014”), these are certificates issued to legal persons, with the aim to seal documents, but not to protect any server, URL or website. Indeed, this certificate does not include the Server Auth EKU, nor any of the CA/B Forum reserved OIDS (arc 2.23.140.1.) To sum up, these certificates are not intended to be used for authenticating servers accessible through the Internet (BR Section 1.1 Overview).

Comment 9

[Matthias]

(In reply to Ryan Sleevi from comment #7)

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.

This might be my limited understanding of how to interpret RFCs; but doesn't Appendix A of RFC 5280† specify limits to the length of several fields that may be included in the subject? Are those limits from Appendix A then not binding for implementing RFC 5280 correctly?

The concern that I voiced in the first paragraph in Comment #6 was not with the violation that was defined in the report (although concerning, it was not what I wrote Comment #6 about), but the "without character limits" clause of their changes to the CPS; as (to the best of my knowledge) all subject fields defined in RFC 5280 have a limit to their length, and the "without character limits" clause of their CPS s3.1.4 is not limited to the specific certificate profiles and would therefore leak to server- and email-certificates, which conflicts with the requirements set by the BR/OV Guidelines for several of the fields that may be included.

e.g. organizationName is limited to 64 characters according to RFC 5820's Appendix A, but section 3.1.4 of their CPS implies that Firmaprofesional would put 91 characters into subject:organizationName if my company (a legal person) was officially called "The Organization With The Name That Would Not Fit In The subject:organizationName Field".

Did you misunderstand my Comment #6? Or did I misunderstand some sections of the requirements and/or CPS, or did I otherwise fundamentally misunderstand something?

† The BR and/or OV Guidelines might pose stricter limits, but RFC 5820 was easier to search through. If BR / OV Guidelines are more strict, the CPS should of course honor those stricter limits.

---

(In reply to Maria Jose Prieto from comment #8)

After analyzing the discussion "maximum allowed size of the subject: givenName, subject: surname" we have understood that the consensus is that the limit is either 64 or 32k, and we think that this sentence is the key: "The current lints are based on ub -given-name-length and ub-surname-length, but these lengths are not used by the AttributeTypeAndValue field of the DN, but by the PersonalName / TeletexPersonalName of BuiltInStandardAttributes of an ORAddress”. Either way, the affected certificate givenname length is less than 64 characters.

OK.

Additionally, if we take into account the following statement: “After discussing this further (see sleevi/cabforum-docs#36 (comment)), it was determined that a 64-character limit for givenName and surname is the path forward.” CAs could not trust the responses of automated validation tools even for the fulfillment of requirements that they are supposedly checking, such as the length of the givenName and surname fields.

We think that this discussion is very useful for the community, and we would like to take advantage of it to clarify also for other CAs, what the accepted limits are.

I agree that clear limits on certificate field lengths are very useful.

Lastly, we think it is important to note that the affected certificate is a QCP-l (“Certificates issued under these requirements are aimed to support the advanced electronic seals based on a qualified certificate defined in articles 36 and 37 of the Regulation (EU) No 910/2014”), these are certificates issued to legal persons, with the aim to seal documents, but not to protect any server, URL or website. Indeed, this certificate does not include the Server Auth EKU, nor any of the CA/B Forum reserved OIDS (arc 2.23.140.1.) To sum up, these certificates are not intended to be used for authenticating servers accessible through the Internet (BR Section 1.1 Overview).

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.

Comment 10

[Maria Jose Prieto]

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.

Dear Ryan,

We attach here details to identify the affected certificate:
Issuer: https://crt.sh/?id=1038824329
CN=AC Firmaprofesional - CUALIFICADOS,
SERIALNUMBER=A62634068,
OU=Certificados Cualificados,
O=Firmaprofesional S.A.,
C=ES
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: 1.3.6.1.4.1.13177.10.1.21.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
certificate)
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

1. 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.
2. 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.

Comment 11

[Ryan Sleevi]

(In reply to Matthias from Comment #9)

Are those limits from Appendix A then not binding for implementing RFC 5280 correctly?

Appendix A is binding, but you're misreading which field this particular limit applies to. See Comment #2 for more details.

(In reply to Maria Jose Prieto from comment #10)

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 .

Please understand: This is not reassuring, although I know you clearly mean it to be. The problem is simply that this doesn't meet expectations, and those expectations exist because they're security relevant, and because it's critical to security to ensure consistency.

I'm not going to belabor this point further: Firmaprofesional has made it abundantly clear that it will not disclose the certificate, because it feels it cannot. However, this also means that it cannot demonstrate unambiguously that what it says is true: that this isn't a TLS-capable certificate. I'm aware that Firmaprofesional feels that the auditor opinion should be sufficient, but we have ample experience to know that we do not, nor have we ever, taken auditor opinions at face value. In particular, as a party relying on that auditor opinion, we had no involvement in the selection of that auditor, nor any awareness that they possess the necessary technical knowledge to appropriately evaluate that it is not, technically, a TLS certificate.

Given that, in part, Firmaprofesional is also asserting that the auditor lacked the technical knowledge to know this was not an RFC 5280 violation, hopefully it's clear the potential contradiction we're being asked to accept: that the auditor is technically skilled enough to make the distinction of RFC 5280 certificate types, but not technically skilled enough to understand RFC 5280 requirements.

It's for reasons like these that CAs are asked, and as of BRs 1.7.1, required, to distinguish separate hierarchies at the intermediate level, to ensure that there can be meaningful technical disclosure (e.g. an intermediate that is EKU constrained to only issue, or not issue, TLS).

I'm saying this not because I think it will shame Firmaprofessional into disclosing the certificate, but rather, making sure it's understood that systemic steps can and should be taken in the future to prevent this non-disclosure, and this non-disclosure will remain a point of concern for this CA when considering incidents.

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

Note that X.500 and RFC 5280 have some incompatibilities and contradictions. This has been raised with ETSI ESI, for example, and ETSI ESI's decision is to permit ignoring RFC 5280 when they deem appropriate, in favor of X.500-series. I want to make sure that there's a clear sequence of precedent (Root Program Policies, BRs, RFC 5280, X.500-series, local legislation), listed in order of most-important to adhere to.

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.

In line with my previous paragraph, I want to highlight that it's exactly this analysis that can and has lead CAs wrong in the past; e.g. compliance with local EU legislation has been seen to trump the RFC 5280 requirements, which is a decision ETSI ESI has made and the IETF rejected.

So far in this exchange, I haven't quite seen the reassurance or systemic change we'd ideally be looking for, so I want to pose a question unambiguously:

• Does Firmaprofessional understand that, in delaying this reporting, they've failed to meet the expectations of https://wiki.mozilla.org/CA/Responding_To_An_Incident
• Will Firmaprofesional commit to adhering to https://wiki.mozilla.org/CA/Responding_To_An_Incident , including promptly reporting any incident, suspected or confirmed, promptly? If it turns out to not be an incident, it can be resolved as Invalid.

Comment 12

[Maria Jose Prieto]

Attachment: QCP-L

Comment 13

[Ryan Sleevi]

Thanks.

Comment #12 shows that the EKU contained is id-kp-clientAuth and id-kp-serverAuth. Considering the BRs before SC31 (that is, BRs v1.7.0), Section 7.1.2.3(f) states the following, emphasis added:

Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or both values MUST be present. id-kp-emailProtection [RFC5280] MAY be present. Other values SHOULD NOT be present.

The presence of the or here creates ambiguities as to whether it's in-scope or out-of-scope of the BRs, since this can be used to authenticate a server (via mTLS). The draft Certificate Profiles work is trying to provide greater clarity here on this exact point - by using id-kp-serverAuth to distinguish in-scope or out-of-scope, after several previous attempts in the CA/B Forum were unable to reach consensus on language for the scope and capability.

The "correct" way to resolve this is at the intermediate layer, so that it's clearer the scope.

However, given the ambiguity, and recognizing that Comment #12 provided the information needed to independently assess, I'm sending this to Ben to evaluate closure here.

Comment 14

[Ben Wilson]

I'll review this issue and anticipate closing it on or about Wed. July 28, 2021.

Comment 15

[Ben Wilson]

I've read through all comments again, and I am satisfied that further exploration and discussion of the causes and resolution of these issues and problems will not yield more useful insights. Therefore, I'm closing this bug.