Hi folks--
(no hats on, this message is as an implementer, a tester, and a WG
participant)
The ECC point encoding rules introduced in crypto-refresh-02 (taken from
RFC 6637) seem fragile and easy to get wrong, especially as expanded
from the introduction of Curve25519's representation.
I think it would be worthwhile to try to write down the rules for point
encoding clearly and deliberately, and to treat the ECC point
compression "flag byte" as its own registry, rather than throwing it in
as an aside in the appendix. By asking IANA to register a table of
these "flag bytes", we'll probably help clarify our own thinking about
what belongs in that table (e.g. are there specific things that need to
be known about each flag, how can it be used), and maybe some of the
other tables as well (e.g. in the ECC Curve OIDs table, maybe we want to
refer to the preferred representation for each curve?)
The initial values of the "flag byte" registry should probably just
include 0x04 and 0x40 (the only two directly contemplated by the draft),
and leave speculative uses like 0x41 and 0x42 for later definitions.
The draft suggests that applications should only use special encodings
("conversion formats") if they are not "in doubt that any recipient can
support it", but offers no mechanism for signalling or detecting that
support, which itself is a bit problematic.
I've noted this as https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/21
and i'm willing to try to draft some text to try to address it, but
haven't done so yet.
Please let me know if you think this seems off-base.
--dkg
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp