Add Implementation Guidance to Recommend Compressed Point Encoding

[frankhinek]

Summary

This PR will:

• Add implementation guidance that recommends using compressed point encoding to nearly halve the payload space occupied by each EC public key (e.g., secp256k1, secp256r1).
• Updates test vector to demonstrate a DID Document containing a secp256k1 key optimally encoded as a DNS packet.
• Fix two minor typos in § Services and the accompanying example.

Context

Elliptic-curve points (e.g., secp256k1, secp256r1) can be encoded as either the x-coordinate and y-coordinate or the x-coordinate and a sign bit for the y-coordinate. The latter encoding, called compressed point encoding, can be used to shrink the size of the DNS packet encoded representation of a DID DHT document by nearly half (65 -> 33 bytes). It also serves to align the payload size of Ed25519 (32 bytes) and secp256k1/secp256r1 (33 bytes) keys.

It's also worth noting that the public keys are unpadded Base64URL-encoded such that the each uncompressed secp256k1/secp256r1 key actually consumes 87 bytes in the DNS packet. Using compressed point encoding decreases the size to 44 bytes.

The added note includes guidance that the DID Document representation must include the x- and y-coordinate pair for all EC JWKs. As noted in RFC 8812:

...a compressed point encoding representation is not defined for JWK elliptic curve points, the uncompressed point encoding defined there MUST be used.

Prior Art

Compressed point encoding has also been used in:

• COSE and JOSE Registrations for WebAuthn Algorithms
• ECDH Compact Representation
• DID Key Decode Public Key Algorithm and Encode JWK Algorithm

Additional References

• RFC 6090: Fundamental Elliptic Curve Cryptography Algorithms
  • § 4.2 Compact Representation
  • Appendix C Why Compact Representation Works
• SEC 1: Elliptic Curve Cryptography
  • § 2.3.3 Elliptic-Curve-Point-to-Octet-String Conversion
  • § 2.3.4 Octet-String-to-Elliptic-Curve-Point Conversion

[decentralgabe]

is this true for all key types?

[frankhinek]

@decentralgabe it is true for all EC key types. In terms of current key types in the DID DHT Registry, that includes secp256k1 and secp256r1.

It is not relevant for OKP keys such as Ed25519 since compressed encoding (only the 32-byte x-coordinate) is always used.

[decentralgabe]

two small ones feel free to merge