Bug: ESI lints are not consistent with ETSI EN 319 412-5 requirements regarding non-qualified certificates

[attilarozgonyi]

When non-qualified certificates containing QC Statements are used, zlint returns an error for e_qcstatem_mandatory_etsi_statems. By the documentation's description, this lint "Checks that a QC Statement that contains at least one of the ETSI ESI statements, also features the set of mandatory ETSI ESI QC statements." and the description references "ETSI EN 319 412-5 V2.2.1 (2017 - 11) / Section 5". This assumption is however incorrect due to the mentioned clause features requirements for qualified certificates only, but there are ETSI-defined statements that can be used in other than qualified certificates, eg. esi4-qcStatement-2 or any other statements defined in subclause 4.3.

The same problem goes to w_qcstatem_qctype_web which "Checks that a QC Statement of the type Id-etsi-qcs-QcType features at least the type IdEtsiQcsQctWeb", and references "ETSI EN 319 412 - 5 V2.2.1 (2017 - 11) / Section 4.2.3", which is titled "QCStatement claiming that the certificate is a EU qualified certificate of a particular type", thus does not apply to non-qualified certificates (the new version, V2.3.1 adds non-qualified certificates to the subclause, but the usage is still not mandatory, only „when the certificate is issued in accordance with Annex III or Annex IV of Regulation (EU) No 910/2014”). Also, I understand that zlint is mainly focused on website authentication certificates but if other types (eg. electronic signature certificates) are in scope, this lint should be broadened to accept other identifiers than IdEtsiQcsQctWeb as well.

The solution to this would be either to fix the above-mentioned lints based on EN 319 412-5 requirements with differentiating between (EU) qualified and non-qualified certificates, or to omit these lints completely.

I have seen a similar bug (https://github.com/zmap/zlint/issues/424) that covers this one’s main idea, but only regarding e_qcstatem_mandatory_etsi_statems, and it contains the proposal of reducing the error to a warning which, following the fix, in my understanding, would still as well warn regarding a 100% ETSI-compliantly issued non-qualified certificate.

[sleevi]

@zakird @dadrian @cpu Given that @mtgag has mostly trailed off contributing, how do you feel about removing the ETSI lints entirely, and closing out the related items?

@attilarozgonyi Thanks for raising this! One of the unique challenges with ETSI’s approach, which is unfortunately very different and incompatible with other trust frameworks, is that CA compliance is a bit more ineffable. That is, a certificate is either qualified or not-qualified, and a not-qualified certificate is totally fine. As you point out, a number of extensions have semantics that change based on whether or not it’s qualified, rather than other trust frameworks that treat these as explicit error cases. For example, we don’t know, from the data available, whether a given certificate is intentionally not qualified or unintentionally not qualified.

The current lints are designed around an assumption that largely the CA will be running these on their qualified certificates. However, because ETSI (well, eIDAS and the SBs) don’t require separate certificate hierarchies for this (as opposed to browsers and the CA/B Forum which increasingly recognize this as industry good practice), non-qualified certificates are treated as errors.

Equally, ETSI changes semantics of extensions - e.g. to allow in non-qualified uses or conditionalize on other fields - which makes linting particularly difficult. This is because the CAB decides what portions and version of ETSI specs to apply to TSPs, and as a result, we can’t simply rely on the notBefore date or a certificate and an effective date.

I think the best approach here would be to remove these lints. These problems are solvable, in theory, but they could be significantly disruptive to the project to tackle on. If ETSI was a more open SDO, and engaged industry technical experts more often, then it’s possible some of this feedback could be provided. However, given that ETSI continues to distance themselves from both the CA/B Forum and the IETF (e.g. the recent optional redefining of subject field lengths, which are incompatible with PKIX), it seems increasingly likely that ZLint may be an ill fit for ETSI.

[cpu]

Given that @mtgag has mostly trailed off contributing, how do you feel about removing the ETSI lints entirely, and closing out the related items?

Strong +1.

[mtgag]

We are still willing to contribute to the ETSI and other lints, as well as update/correct the current ones from ETSI. I am not sure if this helps this discussion, but I just wanted to note it.

[zakird]

I fully support removing ETSI lints from ZLint. The current strategy and commitment is not working. Over the past year and half, there's been frustratingly little movement, lack of interest from multiple CAs, and repeated code problems. Coverage is minimal such that they can't be relied on and I haven't seen evidence that this will change. Further, without an open standard that maintainers of ZLint can reference, we have no ability to ensure quality.

[sandorszoke]

ZLint is a very useful tool, especially for TLS certificates. We run it automatically for every TLS certificate issued before publishing.

We as a European CA would like to use it for all type of certificates, but the false error messages and warnings make this more difficult and problematic. Of course, false error messages can be prevented during runtime by disabling problematic lints (-excludeNames flag), but the optimal solution would be to improve the program.

Rather than completely removing these currently problematic ETSI lints, I would rather resolve existing issues.

You say that it is not too easy for you to clearly understand and follow the ETSI requirements. We offer our contribution in this issue, we can help in the understanding and interpretation of the ETSI requirements. We will be happy to help you specify the required lint functions.

@zakird If this is interesting for you, please let me know it and we can discuss the details.

I hope that the decision will be the development and not the removal.

[christopher-henderson]

@zakird @dadrian @cpu Given that @mtgag has mostly trailed off contributing, how do you feel about removing the ETSI lints entirely, and closing out the related items?

Let me check up with at least Digicert on this as I have a handle into their Slack. Last time I spoke with them it sounded like they were at least one major CA that had an interest in ETSI (although I am not sure how strong that interest is).

[christopher-henderson]

@sleevi @cpu @zakird

Digicert is showing interest in maintaining ETSI support, however they recognize that ZLint is sort of a lame duck in this regard.

I am thinking of moving forward with #592 which seems like it will be necessary for upcoming BRs regardless. Perhaps when we have such an infrastructure in place we can revisit whether or not the extant ETSI lints can be updated to be accurate of if they just need to be plainly rewritten.