Check Extended Key Usage if present

[DDvO]

So far, when checking signature-based message protection, CMP_verify_signature() ignores the EKU extension of the server certificate entirely. If this extension is present and does not include serverAuth the certificate should be rejected.

[mpeylo]

I don't think that there is any Extended Key Usage extension which would fit in case of signature-based message protection. E.g. a CA or RA (or EE) is in this context not a "TLS WWW server" which would be identified by id-kp-serverAuth as per RFC 5280, 4.2.1.12.

Standard-conforming behavior would likely be to reject any certificate used to sign a PKIMessage with any Extended Key Usage other than anyExtendedKeyUsage.

[HBrock]

At least with kur we need to use the certificate to be updated for signature based CMP message protection. This will include certificates that have different EKU for their original target application and not necessarily anyExtendedKeyUsage set.
I think it is wise not too be to strict with EKU checking with certificates used for CMP message protection.

[DDvO]

The kur case is indeed specifically problematic, at least at the conceptual level and for server implementations, while for CMPforOpenSSL, as long as it focuses on client implementations, it has no effect on CMP_verify_signature(). Note that this issue not only pertains to the EKU, but also the (more basic) key usage such as digitalSignature.

CMP servers will need to implement an exception that ignores any key usage and extended key usage entries when verifying the protection of a kur that is signed with the certificate to be updated.

[DDvO]

If we take RFC 5280 strict/serious and the EKU extension is present in a CMP peer's signer cert, I agree that (apart for the special kur case mentioned above) the inclusion of anyExtendedKeyUsage would be a way out, yet note that this effectively defeats the whole purpose of defining restrictions via the EKU extension.

The cleanest way would be to include in CMP signer certs (in analogy to id-kp-emailProtection) some id-kp-cmpProtection, but apparently this has not been defined.

A further way out in my opinion is to interpret id-kp-serverAuth a bit wider to cover not only HTTPS servers, but also CMP servers. Note that also the usual interpretation of id-kp-serverAuth is a bit wider than what is literally written in the RFC ("TLS WWW server"): if one takes this term strict, it only allows for use in TLS web servers but not the use in other TLS servers. Re-using id-kp-serverAuth for CMP servers would be at least more secure than including anyExtendedKeyUsage.

[DDvO]

BTW, adding any EKU checks to CMP_verify_signature() would not lead to compatibility problems if we extend the effect of our OSSL_CMP_CTX_OPT_IGNORE_KEYUSAGE flag to disable also EKU checking.

[mpeylo]

Re-using id-kp-serverAuth for CMP servers would be at least more secure than including anyExtendedKeyUsage.

Quite the contrary. Having Extended Key Usage at all would actually expand the permitted usage for most certificates. There is usually no need to use extended key usage extension in RA/CA certificates used to sign server-side CMP messages. A CA certificate would usually not be used e.g. for a TLS server. Whether an RA certificate used for that should be used for another purpose should be very closely evaluated by the user - and I would generally not recommend it.

A further way out in my opinion is to interpret id-kp-serverAuth a bit wider...

I am not in favor of interpreting very clear standard texts wider. That can lead to extreme confusion and might lead to relying parties accepting the certificate falsely... as TLS server certificate. ;-)

But then, why is this EKU even needed - what's the actual benefit, and it is not AFAIK not even a requirement that it is set for TLS web servers... The clean and actually secure solution is for the peers to check the Policy OID and verify that the use case is defined in the Certificate Policy in the context of the relevant PKI.

There is this open question what to do in case of KUR if extendedKey usage is needed present in (most realistically) EE certificates. E.g. if the entity requesting a new certificate is an OCSP responder only having one single certificate for fulfilling its duty and doing KUR. In order to solve that cleanly, it would be beneficial to get such cmpProtection EKU registered/standardized.

As RFC5280 says:

Key purposes may be defined by any organization with a need. Object
identifiers used to identify key purposes MUST be assigned in
accordance with IANA or ITU-T Recommendation X.660 [X.660].

So, the organization running the PKI may define a privately used key extension, or it could be checked with IETF whether 5280 or 4210 can be updated with a dedicated CMP signing key purpose in the id-kp OID arch. The PKIX group is concluded, but we could anyway write a short RFC for discussion and consideration in the security area.

[HBrock]

I agree with Martin not to use the id-kp-serverAuth EKU for CMP signer certificates on the RA. I would also recommend not using any EKU for CMP signer certificates on an RA. If any EKU is needed than the anyExtendedKeyUsage should be used.

[HBrock]

I think the clean way is to register a specific EKU for cmpProtection. Similarly CMC has a specific EKU to identify an RA (id-kp-cmcRA).
Finally this would mean that each certificate, regardless of its regular purpose, that is to be updated via CMP needs this extension. I feel it is too much to require such cmcProtection EKU in all certificates that are to be managed with CMP. Therefore I would be happy to go with the solution not to check on the EKU of the certificate that signs the kur.

[DDvO]

CMP-specific EKUs are under discussion for the current update to CMP RFC 4210.

[HBrock]

In current version of https://datatracker.ietf.org/doc/draft-brockhaus-lamps-cmp-updates/ three EKUs are introduced:

• id-kp-cmpRA; supposed to use the same OID as id-kp-cmcRA
• id-kp-cmpCA; supposed to use the same OID as id-kp-cmcCA
• id-kp-cmpKGA; identifies a key generation authority authorized to centrally generate key pairs on behalf of EEs; OID TBD