SSlibKey: consider stronger validation of keytype/scheme for keyval

[lukpueh]

The consistency of SSlibKey instances is mainly "validated" at usage time. That is, in SSlibKey.verify_signature, when keyval is deserialised based on scheme, unknown schemes and undeserializable keyvals are filtered out. This validation is incomplete and also happens late.

For comparison, at creation time inputs are hardly validated (see e.g. in from_dict or in the base constructor). Note that an additional safeguard exists in the Key.from_dict deserialisation interface, which filters out unregistered keytype, scheme pairs.

Let's consider:

• adding more comprehensive validation, most notably check consistency of keytype, scheme, and keyval, and
• validating earlier, e.g. already in the constructor

See related issues related to invalid SSlibKey instances and validation: #764 #765, #669, #559

[lukpueh]

An argument against more comprehensive and/or earlier validation is that a key might be deserialized but never used for signature verification. In that case it might not matter if the key is invalid.

Similarly, a key might be inconsistent, but still manage to verify a signature. This is likely the case for ecdsa keys, e.g. if the keyval contains a nistp256 key, but scheme is "ecdsa-sha2-nistp384" (or vice-versa).

I lean towards checking early and comprehensively, and failing hard if an SSlibKey is inconsistent. If we want to support deserialisation of unknown keys, we should implement this in the Key.from_dict interface.