Relax the permitted-algorithm policy for ECDSA

[athoelke]

Fixes #278

[mpg]

Pre-existing: I don't think "the length of the base point" is correct. I believe you mean the length of the order of the base point.

[athoelke]

Correct. How to fix though - the 'bit size' or 'octet size' of an integer is an odd concept and I'd quite like to not use that.

I might use the same style as I used for the WPA3 password token keys (but adjusted to refer to the group order):

$N$ is the integer for which $2^{8(N-1)} \leq r < 2^{8N}$, where $r$ is the order [of the base point]* of the curve.

* This is not strictly necessary as 'order of the curve' typically menas the same thing?

Or I could go with the SEC1 style, which has equivalent results (as $p$ is not a power of 2):

Where $N = \lceil{\log_2{r}/8}\rceil$, where $r$ is the order of the elliptic curve.

[mpg]

the 'bit size' or 'octet size' of an integer is an odd concept

Agreed, writing this felt weird.

I think I like the first option a bit better, but both are fine IMO.

Unless I'm mistaken all of the curves standardised for use with ECDSA have cofactor 1, so indeed the order of the curve and the order of its base point are the same thing.

[mpg]

Nit: it is impossible unless you have access to the private key ;)

[athoelke]

Also pre-existing. But do I really need to qualify this with 'Without the private key, it is impossible ...'?

[mpg]

Honestly that's probably just me being too picky here, and I'm not insisting on fixing this. But perhaps we could avoid the word "impossible" and just say "Signature verification can't determine ..."?

[gilles-peskine-arm]

LGTM for the new text, but I think the section on policies also needs to be adapted.

[gilles-peskine-arm]

I think these exceptions should be mentioned in the “Permitted algorithms” section of the chapter on policies. Not necessarily the full list, but at least the general ideas that some algorithms are considered partially equivalent. Maybe just say that it's the case for some signature algorithms, which are only considered equivalent for verification? According to the current text, “A specific algorithm value permits exactly that particular algorithm” (plus NONE and various wildcard cases), which rules out the ML-DSA, SLH-DSA and now ECDSA verification relaxation.

[athoelke]

Good point - the PQC extension didn't actually modify that text, because it is outside the main spec for now.

[gilles-peskine-arm]

That text should also make it clear that the policy enforcement there depends not only on the key metadata and the requested algorithm for the operation, but also on the nature of the operation.

When a key is used in a cryptographic operation, the application must supply the algorithm to use for the operation. This algorithm is checked against the key's permitted-algorithm policy.

That doesn't completely rule out the fact that a policy of PSA_ALG_ECDSA(PSA_ALG_SHA_256) allows PSA_ALG_DETERMINISTIC_ECDSA(PSA_ALG_SHA_256) for verification but not for signature, but it strongly hints that only the algorithm matters.

This is reflected architecturally, for example, in Mbed TLS/TF-PSA-Crypto, where the policy check is implemented as a function

static psa_status_t psa_key_policy_permits(const psa_key_policy_t *policy,
                                           psa_key_type_t key_type,
                                           psa_algorithm_t alg)

which will need to take an extra argument that allows distinguishing signature from verification. (The key type is not enough since a key pair can be used to verify a signature.)

[athoelke]

This approaches what we have described for psa_check_key_usage - where the role the key takes in the algorithm matters, not just the algorithm itself.

[athoelke]

I've tried to capture this in a rewording of the permitted algorithm policy introduction.

[gilles-peskine-arm]

LGTM

[MarcusJGStreets]

I am happy the intro includes the relaxation - which I also think is sensible.
So I think this answers Giles point.
Therefore, I am happy