Reintroduce lint for inconsistent KU and EKU

[vanbroup]

This updated lint has been created and reviewed by several members of the @pkic and its addressing the issues with e_key_usage_and_extended_key_usage_inconsistent introduced in #497 (and refined in #528), see also #553 and #556.

We have tried to provide sufficient details in the error for debugging purposes:

{"e_key_usage_and_extended_key_usage_inconsistent":{"result":"error","details":"KeyUsage [DigitalSignature KeyEncipherment] (00000101) inconsistent with ExtKeyUsage serverAuth"}}

The lint has been tested against all valid certificates in yeti2024, most of yeti2023, and hundreds of millions in argon2023 without issues.

In the test corpus we identified 29960 certificates with an invalid combination:

Fingerprint	Count
KeyUsage [DataEncipherment DigitalSignature KeyEncipherment] (00001101) inconsistent with multiple purpose ExtKeyUsage [clientAuth serverAuth]	28052
KeyUsage [ContentCommitment DigitalSignature KeyEncipherment] (00000111) inconsistent with multiple purpose ExtKeyUsage [clientAuth serverAuth]	723
KeyUsage [DigitalSignature KeyEncipherment] (00000101) inconsistent with ExtKeyUsage clientAuth	443
KeyUsage [DataEncipherment DigitalSignature KeyEncipherment] (00001101) inconsistent with multiple purpose ExtKeyUsage [clientAuth emailProtection]	327
KeyUsage [DataEncipherment DigitalSignature KeyEncipherment] (00001101) inconsistent with ExtKeyUsage serverAuth	233
KeyUsage [ContentCommitment DigitalSignature KeyEncipherment] (00000111) inconsistent with ExtKeyUsage serverAuth	88
KeyUsage [DataEncipherment DigitalSignature KeyAgreement KeyEncipherment] (00011101) inconsistent with multiple purpose ExtKeyUsage [clientAuth serverAuth]	55
KeyUsage [DataEncipherment DigitalSignature KeyEncipherment] (00001101) inconsistent with multiple purpose ExtKeyUsage [clientAuth emailProtection serverAuth]	9
KeyUsage [ContentCommitment DataEncipherment DigitalSignature KeyEncipherment] (00001111) inconsistent with multiple purpose ExtKeyUsage [clientAuth emailProtection]	7
KeyUsage [ContentCommitment DataEncipherment DigitalSignature KeyEncipherment] (00001111) inconsistent with multiple purpose ExtKeyUsage [clientAuth serverAuth]	7
KeyUsage [DigitalSignature KeyAgreement KeyEncipherment] (00010101) inconsistent with ExtKeyUsage serverAuth	4
KeyUsage [ContentCommitment DataEncipherment DigitalSignature KeyAgreement KeyEncipherment] (00011111) inconsistent with multiple purpose ExtKeyUsage [clientAuth emailProtection]	3
KeyUsage [ContentCommitment DataEncipherment DigitalSignature KeyEncipherment] (00001111) inconsistent with multiple purpose ExtKeyUsage [emailProtection serverAuth]	3
KeyUsage [ContentCommitment DigitalSignature] (00000011) inconsistent with multiple purpose ExtKeyUsage [clientAuth serverAuth]	2
KeyUsage [ContentCommitment DataEncipherment DigitalSignature KeyAgreement KeyEncipherment] (00011111) inconsistent with ExtKeyUsage clientAuth	1
KeyUsage [ContentCommitment DigitalSignature KeyEncipherment] (00000111) inconsistent with ExtKeyUsage clientAuth	1
KeyUsage [ContentCommitment DataEncipherment DigitalSignature KeyEncipherment] (00001111) inconsistent with ExtKeyUsage serverAuth	1
KeyUsage [ContentCommitment DataEncipherment DigitalSignature KeyAgreement KeyEncipherment] (00011111) inconsistent with multiple purpose ExtKeyUsage [clientAuth serverAuth]	1
Grand Total	29960

CC: @sandorszoke

[vanbroup]

@christopher-henderson any comments on this PR?

[christopher-henderson]

@vanbroup thank you for your patience. I have been under some extreme duress outside of ZLint in the past month. This, coupled with not getting a push notification on this PR, left me somewhat derelict on the issue.

There are a lot of corrections to the expectations in the test corpus, which are typically a fair deal of work on me to independently verify vis-a-vis governing requirements. I will likely start there as the code itself is rarely a blocking issue.

[vanbroup]

Thanks for the review, I have not forgotten this but need to free some time to address the comments.

[vanbroup]

@christopher-henderson sorry for the delay, I think that your comments have been addressed

[chrisbn]

@vanbroup dataEncipherment is currently permitted by the TLS BRs for RSA keys (7.1.2.7.11 Subscriber Certificate Key Usage) but rejected by this lint. Although it's highlighted that this KU is Pending Prohibition, I'm not sure if this was intentional?

Perhaps the TLS BRs are overriding RFC5280 on purpose, or it's an error. Either way, the lint will block a currently permitted value by the BRs.

[vanbroup]

The lint follows RFC 5280 and by checking against the major CT logs we tried to identify any inconsistent implementations, we did not explicitly check the CA/Browser Forum requirements.

We checked this lint to hundreds of millions of certificates in the CT log's without finding any issues, do you know how often this happens across the ecosystem or are you running into this problem in a new certificate profile?

[christopher-henderson]

@chrisbn hmmm...it's unfortunate that BRs and RFC5280 seem to be disagreeing here.

With regards to getting infra working again, there may be several options. The not-so-great option is to utilize zlint -excludeSources=RFC5280 cert.pem in some way (unfortunately, we do not have anything setup that can skip individual lints...this may be a nice feature enhancement).

Alternatively, consumers of the CLI tool can choose to parse out the printed JSON and decide if a failure in this lint is ok-or-not.

Consumers of the library can similarly choose whether-or-not they prefer the BRs interpretation over 5280.