Subject: [Cfrg] draft-irtf-cfrg-curves-11: Lack of requirement for canonical encoding of public key

From: Brian Smith <[email-masked]>
Date: Sun, 20 Dec 2015 12:09:34 -1000

Draft 11 says: "Implementations MUST accept non-canonical values and
process them as if they had been reduced modulo the field prime." In other
words, X25519 implementations must accept non-canonical encodings of public
key coordinates. There is no requirement that an X25519 implementation
transmit its public key in the canonical encoding. Is this intentional?

I don't think that this will work too well in practice. Other public key
formats, like the public key formats for RSA and NIST ECDSA/ECDH public
keys, specify a canonical encoding. Having a canonical encoding is very
useful because it allows keys to be correctly compared bytewise and/or by
their hash, if (and only if) long as the application only accepts the
canonical encoding. This is useful for revocation checking of public keys,
in particular.

I don't know whether or not it is too late to change draft-irtf-cfrg-curves
to specify that public keys MUST be encoded and sent only in the canonical
form and to remove the requirement that the recipient of a non-canonical
encoding of a public key must reduce it mod q. If not, I suggest changing
it. Otherwise, I hope that we can require that a canonical encoding be
used, and that an implementation may reject non-canonical encodings of
public keys in the specifications that build on top of this spec.

Cheers,
Brian
-- 
https://briansmith.org/