Lint that the EKU values within a SubCA certificate comply with CABF_BR 7.1.2.2 letter g)

[defacto64]

Adds a new lint, identified as e_sub_ca_eku_incmpatible_values, to check that the EKU values within a Subordinate CA certificate meet the MUST NOT requirement of CABF Baseline Requirements 7.1.2.2, letter g).

[defacto64]

Indeed this lint may raise an error erroneously, so to speak, upon a cross-certificate that contains the EKU extension AND the EKU contains serverAuth. This lint was not intended to cover that case, and at any rate it does not seem possible to determine if a CA certificate under examination is a cross-certificate unless extra information is passed to Zlint, and this seems tricky.

However, considering that cross-certificates are a microscopic minority of all CA certificates, and that only some of them would trigger this lint (depending on whether they contain the EKU and depending on its value), in my opinion it is acceptable that this lint produces a "false positive" (that is, an error) in those very few cases, which can then be managed with an ad hoc procedure (e.g. by temporarily bypassing the linter). How about this?

[sleevi]

We’ve intentionally tried to avoid this in the past, because unreliable lints mistakenly encourage CAs to believe ZLint as a whole is unreliable.

My own view is that we should properly lint the requirements completely, and use warnings for if we’re unable to detect errors.

[cardonator]

I have to agree that any scenario that would return an Error (which impacts issuance) in a situation that is non-deterministic, the lint should be lowered to a Warning despite that not lining up exactly with the BR terminology as discussed in the README.

[defacto64]

I appreciate the reasoning and all in all I agree. I am therefore available to revise the lint so that it returns a warning instead of an error, being the alternatives (e.g. passing additional context to Zlint) too tricky and lengthy. This is an easy change and I can do it quickly, then submit a new pull request. @sleevi, @christopher-henderson, @cardonator, would this be fine with you?

Please note that the aim of this lint was specifically that of checking compliance with the first "MUST NOT" of BRs 7.1.2.2 letter g). In view of this, the lint's description may seem too wide-scoped, and I would agree to narrow it. Otherwise, in order to also cover the case of "Subordinate CA certificates not used to issue TLS certificates" (which was not my intention) I'd have to add a bit more code and test cases. Nothing too difficult, but it could be handled as a subsequent refinement ...