PoP scheme: recommendation for hash_pubkey_to_point serialization

[mratsim]

Currently (draft 14) the section about the PoP schemes makes the following recommendation:

The RECOMMENDED way of instantiating hash_pubkey_to_point is to
use the same hash-to-curve function as hash_to_point, with a
different domain separation tag (see
[I-D.irtf-cfrg-hash-to-curve], Section 3.1). Section 4.1
discusses the RECOMMENDED way to construct the domain separation
tag.

In section 1.3 we have

• PK: The public key for the signature scheme.

[...]

• point_to_octets(P) -> ostr: returns the canonical
  representation of the point P as an octet string. This
  operation is also known as serialization.

• octets_to_point(ostr) -> P: returns the point P corresponding
  to the canonical representation ostr, or INVALID if ostr is not
  a valid output of point_to_octets. This operation is also
  known as deserialization.

Curve points usually admits both a compressed and an uncompressed representation.
For example Weierstrass pairing curves with equation y² = ax³ + b might only store x+sign(y) and Edwards curve points are usually compressed by storing just y and the sign of x (https://eprint.iacr.org/2015/677.pdf, Encoding and parsing curve points p2, for pairings on Edwards curves: https://eprint.iacr.org/2009/155.pdf)

For instance BLS12-381 admits 2 "canonical" serialization format (https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-pairing-friendly-curves-10#appendix-C). It should be clearer that the application should enforce a single representation for PopProve and PopVerify purposes.