Prevent explicitly encoded curves for ECDSA keys via C API (FFI)

[tobiasbrunner]

Apparently, there is a relatively recent NIAP requirement that demands that certificates with ECDSA keys that have the curve parameters explicitly encoded should get rejected (TD0527, Test 8b).

In OpenSSL this is now enforced (openssl/openssl#12683) and with 1.1.1h a function was added to check if the curve params of an EC key were parsed from an explicit encoding (EC_KEY_decoded_from_explicit_params), which was later replaced by OSSL_PKEY_PARAM_EC_DECODED_FROM_EXPLICIT_PARAMS with OpenSSL 3. Other libraries like wolfSSL don't allow explicit params, by default, but even when compiled with support for it make it easy to check the encoding after parsing a key to reject it then.

With Botan's FFI interface I haven't found a way to do the same. Would it be possible to expose the param encoding in that API (I guess EC_PublicKey::domain_format() or maybe EC_PublicKey::DER_domain() - however, I'm not sure if that actually represents the actual information after parsing a key or if it's rather how it would get encoded if the key is exported later, which we can't seem to be able to control via FFI either, by the way)? I saw that support for explicitly encoded params is actually on the list of deprecated features, so maybe an option to build Botan without support for it would be preferable?

[randombit]

Currently that information is not exposed anywhere. In particular if you use an explicit encoding of a known group (say P-256) then the EC_Group is completely indistinguishable from an EC_Group that was created as a result of the OID encoding.

Given the NIAP requirement we'll need some way of detecting this. #3664

[randombit]

Can you take a look at #3665 and see if this would suffice?

This change is just for tracking the source of the group information and additionally exposing it on the FFI layer. We may also want to add a flag to validation that indicates if such a key was seen in the chain but that would come in a followup.

[tobiasbrunner]

Thanks a lot and sorry for the delay. Yes, this change works fine for us.

[randombit]

I believe this is addressed by #3665 but certainly reopen or open a new issue if it does not cover your use case.

Next release (3.2) is planned for October 9.