spec should be clear about validation of public keys

[rolfyone]

ref. Consensys/teku#4787

Basically providing an invalid public key to teku as a filter will result in a 400 error, but it would appear not all clients are consistent on the handling of invalid query parameters.

This is probably the best spot to track any discussion on how these query parameters should be dealt with.

If you supply an invalid key, should a 400 error be returned? 400 in this api is described as 'invalid state or validator ID, or status'

The public key validation in my mind is akin to validating index '-1', which teku returns a 400 for, where as over the end of the array is at least a valid index value so it's just 'not found' in the list of validators...

[mcdee]

If the public key is invalid then yes I think that the API should return a 400 error.

To be clear, by invalid I mean "not a valid encoding of a public key" rather than "a public key not linked to a known validator". The latter should simply return no result for the given public key, which I believe is consistent behavior across all clients.

[ajsutton]

The other question here is what invalid means. Is a key valid or invalid if it isn't on the g2 curve?

[rolfyone]

True, a valid byte array not on the g2 curve we're treating as invalid, and I mean it technically is invalid, but is that what we want...

[mratsim]

The other question here is what invalid means. Is a key valid or invalid if it isn't on the g2 curve?

There is no legitimate reason to pass a key that is not in the correct subgroup.

We can refer to KeyValidate for the definition: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04#section-2.5
and discussion
https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04#section-5.1

KeyValidate requires all public keys to represent valid, non-identity
points in the correct subgroup. A valid point and subgroup
membership are required to ensure that the pairing operation is
defined (Section 5.2).

A non-identity point is required because the identity public key has
the property that the corresponding secret key is equal to zero,
which means that the identity point is the unique valid signature for
every message under this key. A malicious signer could take
advantage of this fact to equivocate about which message he signed.
While non-equivocation is not a required property for a signature
scheme, equivocation is infeasible for BLS signatures under any
nonzero secret key because it would require finding colliding inputs
to the hash_to_point function, which is assumed to be collision
resistant. Prohibiting SK == 0 eliminates the exceptional case,
which may help to prevent equivocation-related security issues in
protocols that use BLS signatures.

Regarding the subgroup, we don't want to end up vulnerable to small subgroup attacks like Monero, see appendix (https://www.getmonero.org/2017/05/17/disclosure-of-a-major-bug-in-cryptonote-based-currencies.html )

[arnetheduck]

I would stay clear of a mandatory on-point verification - making this verification is expensive CPU-wise, if the key is compressed which opens the server to trivial DoS attacks - in the current architecture, the key is just an array of bytes that you compare against known byte arrays and that's it.