Lints for ETSI TS 119 312

[RufusJWB]

ETSI publishes ETSI TS 119 312 providing guidance on the selection of cryptographic suites. As this is a normative document under the ETSI audit regime, we should have LINTs for it.

[sleevi]

@RufusJWB It’s not clear to me the relevance or lintability of this document. I’m assuming you’re thinking in the context of OCSP and CA certificates, and not suggesting lints for CAdES/XAdES. For the OCSP/CA side of things, the specifications in Appendix A are only with respect to interoperability profiles, and not with respect to exclusions/prohibitions.

Perhaps you could be more precise what you think is missing? That would help evaluate whether it’s even possible to LINT.

[RufusJWB]

I would like to have - for example - LINTs for table 10 of the technical specification. Such a lint could look like the following:

if (cert.algorithm == sha256-with-rsa) {
   if (cert.validUntil > 1.1.2025) {
      return "Error"
   }
   if (cert.validUntil > 1.1.2020) {
      if (cert.keypair.keySize < 1900 ) {
         return "Error"
      }
   }
}
return 'Ok'

[sleevi]

But those aren’t normative? They’re just recommendations, and structured weirdly (in that they aren’t a factor of key lifetime, but if absolute date). I don’t know if I’d be able to be an effective reviewer, as I’ve not paid any attention to TS 119 312, as its narrow focus has meant zero practical applicability to browsers so far.

[RufusJWB]

If someone is under ETSI audit regime, they are normative (even if only a 'should'):

if the subscriber or subject generates the subject's keys: i) an obligation or recommendation to generate the subject keys using an algorithm as specified in ETSI TS 119 312 [i.10] for the uses of the certified key as identified in the CP; and ii) an obligation or recommendation to use key length and algorithm as specified in ETSI TS 119 312 [i.10] for the uses of the certified key as identified in the CP during the validity time of the certificate.

[...]

GEN-6.5.1-06: CA key pair generation should be performed using an algorithm as specified in ETSI TS 119 312 [i.10] for the CA's signing purposes. GEN-6.5.1-07: The selected key length and algorithm for CA signing key should be one which is specified in ETSI TS 119 312 [i.10] for the CA's signing purposes.

[...]

SDP-6.5.1-18 [CONDITIONAL]: If the CA generates the subject's keys, CA-generated subject keys should be of a key length and for use with a public key algorithm as specified in ETSI TS 119 312 [i.10] for the purposes stated in the CP during the validity time of the certificate.

https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.02.00_20/en_31941101v010200a.pdf

Regarding the "in that they aren’t a factor of key lifetime, but if absolute date": I think this is discussed in table 9.

[sleevi]

I think we’re miscommunicating here. That cited text is not a MUST (“an obligation or recommendation”).

More explicitly: I don’t think the things you want linked can be linted in a reasonable way. I also wouldn’t feel comfortable reviewing those lints.

[dzacharo]

To @RufusJWB's point, I thought ZLint also contains lints that report on SHOULD requirements as well, throwing WARNING messages. Perhaps this is something different?

[sleevi]

NOTICE, not WARNING.

However, the objection is on how suitable and lintable these are, given the requirements. Knowledge of whether the TSP generated the key or not is outside of ZLint, as is knowing the effective lifetime of the key (which depends on all certificates issued, not just the linted certificate). Some of these requirements are not implementable in Go via the current ZCrypto support (Brainpool), and some are actively harmful recommendations (RSA-PSS). These are largely recommendations, and so at best, are NOTICEs, and would take considerable time to review.

The extent of my own ability to maintain and support ETSI lints is limited to the extent they are relevant to the Web PKI, and thus lints for matters like QSeals or QSigs are things I am unable to personally support reviewing. The support for ETSI lints in ZLint was itself tenuous at best, in terms of finding maintainers who can support, and which are actively following developments, and the many lints from @mtgag have shown it’s a very high support burden (and highlighting many ambiguities or issues within the ETSI specifications).

[dzacharo]

I think you are confusing the SHOULD requirements (e.g. in GEN-6.5.1-06, GEN-6.5.1-07) with recommendations in other sections of the standard. I agree that it's not easy to maintain such lints but if community members want to have a shot at creating such lints, why shut down these efforts?

[RufusJWB]

Well, currently I have an apprentice who needs to do some GO coding for learning the language. And since I always think an apprentice should do real work, I thought she might help here implementing these LINTs. I would propose the following: she will start working in a different fork and only when we have the feeling that she has achieved something worth presenting, we will make a Pull Request. Maybe @dzacharo would like to review before we create the pull request. So we avoid filling the inboxes of the maintainers.

[dzacharo]

I am not so familiar with GO to understand the code of these lints in depth like other maintainers or participants. Thanks for the offer though.

[sleevi]

@dzacharo I appreciate your clarification, but that's not what is happening here.

If you examine @RufusJWB 's remarks, you'll notice that the GEN language cited from 319 411 is a SHOULD. However, I'm also highlighting that the language within TS 119 312 is also a SHOULD, and focused on defining interoperability profiles more than restricting the profile. A good example of this is Section 7.3, which is ambiguous with respect to curve/hash combinations for ECDSA: a strict reading would read that the use of SHA-384 with P-256 is prohibited by paragraph two, consistent with Mozilla policy (and now CABF, with respect to SC31), while a liberal interpretation would see Table 4 as permitting such mixing.

However, more concretely, the normative requirements expressed in Appendix A (e.g. Section A.7) are non-restrictive; they indicate mandatory-to-implement, but they do not impose limits. A naïve reading of the requirements might be to argue that Table 4 / Section 7.3 is restrictive, but even within that section, there are contradictory statements (e.g. paragraph one notes "recommended hash functions and signature algorithms", while paragraph three states "The signature suites listed in table 4 shall be used"). There are multiple problems with this (whether this is an inclusive or exclusive set, whether this is dispositive only to qualified certificates or also applicable to non-qualified certificates, consistency between these sections). These sort of self-contradictions are not unique to ETSI; e.g. https://github.com/cabforum/documents/issues/191 - but represent considerable time to sort through.

However, my concern on push back is to make sure that unnecessary work is not done which we ultimately reject. While open source is certainly about encouraging and welcoming participation, and we want to support that, supporting everything isn't always possible. Sometimes, the best answer is a clear "No". You can see some of the history regarding ZLint support for ETSI documents, and we want to make sure that lints are things that the @zmap/zlint-maintainers can support, and not just any community contribution. Similarly, because reviewing lints can take considerable time, we want to make sure that time is spent on the most impactful things.

I'm not trying to speak for all of the ZLint maintainers, certainly, but as one of the folks who explicitly stepped up to review ETSI lints, I wanted to make sure I wasn't overlooking anything when I tried to very clearly say: I don't think this is a lint I can support, and I don't think this is a good lint for ZLint.

[RufusJWB]

I went through the discussion in the past and I understand your point, @sleevi . Please excuse my direct question, but I would like to understand whether are we now on point 2 of The Art of Closing or would you want us to open single issues for every possible lint and discuss them before we start coding? If we are on point 2 that's also fine for me ("no is temporary, yes is forever").

[sleevi]

@RufusJWB I certainly don't want to discourage all contributions, particularly those related to ETSI, but to highlight both prioritization and the degree of clarity of the requirements ("good specs make for good lints", to make up a new aphorism). I think an issue-per-proposed-lint would be just as overwhelming, if not more so, than a bunch of a PRs. If there's strong interest in contributing a number of lints re: ETSI to ZLint, then I would probably encourage an approach similar to how the original ZLint lints came to be: by examining the relevant standards, identifying clear and measurable requirements within the context of the information ZLint presently provides (i.e. currently, only an input certificate), and where the gaps are within the ETSI lints.

You can see I started this in https://github.com/zmap/zlint/issues/410 with respect to @mtgag 's lints, and if you spot further gaps, I'm sure we can add and update. You can look at the ZLint BR coverage sheet to understand how ZLint did this for the Baseline Requirements.

If you, @mtgag , @dzacharo and others would like to take a similar approach, of identifying the normative requirements that can be technically quantified, I'd be happy to review such a spreadsheet, highlighting impactful lints that we can upstream and maintain going forward.