Currently, when we instantiate a Verifier we do not check that the supplied public key EC point is on the supposed curve.
This is not best practice. See for example BCP225 in the JWS/JWT context:
"Some cryptographic operations [...] take inputs that may contain invalid values. This includes points not on the specified elliptic curve or other invalid points (e.g., [Valenta], Section 7.1). The JWS/JWE library itself must validate these inputs before using them, or it must use underlying cryptographic libraries that do so (or both!)."
It'd also result in a panic when the go-cose application is built against go1.19. See go1.19 release notes:
"Operating on invalid curve points (those for which the IsOnCurve method returns false, and which are never returned by Unmarshal or by a Curve method operating on a valid point) has always been undefined behavior and can lead to key recovery attacks. If an invalid point is supplied to Marshal, MarshalCompressed, Add, Double, or ScalarMult, they will now panic."
This can potentially widen the DoS surface of a go-cose application. Users should be shielded from such situation.
Currently, when we instantiate a Verifier we do not check that the supplied public key EC point is on the supposed curve.
This is not best practice. See for example BCP225 in the JWS/JWT context:
It'd also result in a
panicwhen the go-cose application is built against go1.19. See go1.19 release notes:This can potentially widen the DoS surface of a go-cose application. Users should be shielded from such situation.