If we always use secp256k1 then I don't think it is necessary to include the curve parameters as they are static for this (or any other) specific curve choice.
I believe that it should be possible to craft such a malicious message since PER requires knowledge of the encoding rules/schema used when encoding the message. Thus a PER message will be decoded into different data structures depending on which schema the decoder is holding. I think this problem could be avoided by including a hash digest of decoded message in the PER encoded message. Thus when PER is decoded, the decoding (reflecting the full schema description) is hashed and verified to ensure that the client uses the same, unique schema, used by the server.
There might be some issues by still allowing '=' in the URL encoding since it already has a semantic meaning in a URL.
As far as I can see there are only two public keys because an elliptic curve will have an equation y^2=x^3+ax+b, meaning that for a choice of x there is two possible options for y fulfilling the equation. However, there might be more than one choice of x. To be precise there is a single choice of 0 < r < n where n is the curve order, but x can be larger than n and so there are two key options for each c being a positive integer constant such that x=r+cn. But as far as I can see the verification should still pass no matter what x has been used because of the rest of the math involved work modulo n. To conclude; we can assume there are at most two choices and we are fine by simply testing the two possible options. Finally for public key extraction to work we must still have a digest of the real public key externally to verify the extraction against. Otherwise we cannot verify where the signature came from.