[openpgp] ECC point encoding and "flag byte"

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Sat, 27 February 2021 17:47 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 544A13A10A7 for <openpgp@ietfa.amsl.com>; Sat, 27 Feb 2021 09:47:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.295
X-Spam-Level:
X-Spam-Status: No, score=-1.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=4SjaySIk; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=KQnJebs2
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ay2WIOb6rBpR for <openpgp@ietfa.amsl.com>; Sat, 27 Feb 2021 09:46:58 -0800 (PST)
Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9CF3A104E for <openpgp@ietf.org>; Sat, 27 Feb 2021 09:46:57 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1614448016; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=mQ3kh1tfsXeCG2zTaC8BSHCAcNXhzTKmyorRsOVaUXE=; b=4SjaySIktAHRyKBerVz1pl7XG/JorwHP4qZaU9wkJ2L53DMTKfi1g13A9xSt9tGN7qc/B 6tN/hH3w5e+7p2tAg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1614448016; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=mQ3kh1tfsXeCG2zTaC8BSHCAcNXhzTKmyorRsOVaUXE=; b=KQnJebs2f8L/EmWj/yhcPhyIAcaWiTQTMIh8Y15pA/Qs/aa5bZMZuoeI94yd4/XKyhyj6 iqWFDvfOGDhtgrgkjiR1oYKA5zahLFN+A/JUfmFLNU7N7hzW9Jb6h3JphvGQb36OmoPdFzs o7q7xW6IBf131QLoTQkQfAcRdYvdJDR1TnKUowXfbQxTWbl0jEMYzpk9KYTepvsiDvc9mRu M14X9IAnS7v1sUatqpe8N0vOLv4gWsxoyov3FS/R3Tr+3GCI1BJ7ESqWLGyKXvD8KYZYqsR SZUJZwQg6LBR//PisZ3I4FJRNk48gUx1zxSRzS4jg99PwOi0q/8yEi8epaJQ==
Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 3C614F9A7 for <openpgp@ietf.org>; Sat, 27 Feb 2021 12:46:55 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 7BB4C20BA1; Sat, 27 Feb 2021 00:17:28 -0500 (EST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: openpgp@ietf.org
Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH
Date: Sat, 27 Feb 2021 00:17:27 -0500
Message-ID: <87h7lyccns.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/QtvTIH7mIN0dE34Oih5zZa-XAuk>
Subject: [openpgp] ECC point encoding and "flag byte"
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Feb 2021 17:47:05 -0000

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