Support enforcement of additional required and allowed extended key usages (EKUs)

[christopherincanada]

NOT A CONTRIBUTION

The CABF requirements for SMIME states the following for Subscriber certificates in terms of extended key usage:

Generation: Strict
KeyPurposeId: "id-kp-emailProtection SHALL be present. Other values SHALL NOT be present."

Generation: Multipurpose and Legacy
KeyPurposeId: "id-kp-emailProtection SHALL be present. Other values MAY be present."

We would like to see pkilint enhanced to be able to also check additional extended key usages that may be present in certificates of the Multipurpose and Legacy generations. Specifically, the ability to configure the tool with one or more of the following inputs:

• Additional Required Extended Key Usage (perhaps via a new command option: [--additional-required-eku EKU_OID])
• Additional Allowed Extended Key Usage (perhaps via a new command option: [--additional-allowed-eku EKU_OID])

When provided, the tool would ensure that all additional required extended key usage OIDs were present in the Extended Key Usages extension, and that any remaining extended key usage OIDs found are allowed. This would only apply to Multipurpose and Legacy certificates.

The CABF requirements for TLS contains similar statements/requirements around extended key usages, so it would be ideal if similar capability could be added there as well. The only difference is there are a list that are explicitly disallowed that would need to be accounted for.

Note: Longer term, instead of (or perhaps in addition to) specifying these inputs via the command line, you might consider an input configuration file (perhaps in YAML) that could contain these values (and more).