Re: [COSE] draft-ietf-cose-rfc8152bis-algs-06: Incompatible encoding of EdDSA public keys

Neil Madden <neil.madden@forgerock.com> Thu, 27 February 2020 16:23 UTC

Return-Path: <neil.madden@forgerock.com>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62013A0C2D for <cose@ietfa.amsl.com>; Thu, 27 Feb 2020 08:23:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
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 zlv2YtM9WzjI for <cose@ietfa.amsl.com>; Thu, 27 Feb 2020 08:23:47 -0800 (PST)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62AEE3A0C0E for <cose@ietf.org>; Thu, 27 Feb 2020 08:23:47 -0800 (PST)
Received: by mail-wr1-x42b.google.com with SMTP id m16so4102237wrx.11 for <cose@ietf.org>; Thu, 27 Feb 2020 08:23:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5luvqM2/o7CHoUwlo5YdAulHYckfHLJrJnGp6y7K9as=; b=TbOcXdDPsHM9WkhxHGaq718wFPgP+onkICXgd27ZP/KEBq0mQYeYDkV1uZvZvwQmvA rT0ZkybPArS4G4xXttjZ5NtECmFbOXs/hs5lmt+SJHJMn8g3ZtHyH55tsx5GJJ8BKSKo cUIlPidvLFGyMSpts+ILhYhjpw6Pw5J2b2bTM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5luvqM2/o7CHoUwlo5YdAulHYckfHLJrJnGp6y7K9as=; b=EgCKD7cEi+qMp2qqyoSb08Ed193ftZVSsnlJ7FjrvCQWmd9xTY4oBW9IyrwOdqqIEP BDeJeKlu8T4VobzZ2MqvHkRknxg9t21fp0XmfWR+rrQeYLl4Z1H5EInwMBbgG7eTh9+C RZwET7QD5A5EuAt7QrQo/wQBr1gEp/Ge785dkOCfE87ewB+8EVfT3zhURPG5Qt5vMVSs s0NBbWZ0kgryy4mEPJVSdOEglGcbDDO3YrJDByng8pvltKZXS8ZwFlSmSLdNPFoTU2Gs PbV4iYJrh5bDHRu/S6ZliJQsWz7soso9tawz2IDweY7IUfAIks7Shdj9IEE+sy1n+8pz vM2A==
X-Gm-Message-State: APjAAAVwajeXJX8/KPwRy9LpBDKKTpZV11/PdfIHqeNJCpgv7wAeefCo oVUepHF2R7RsIHXS2S4OFvO4dTiBXsQ9Hw==
X-Google-Smtp-Source: APXvYqyq3jUYM6E0GQVppA8J+gjUeMQqUaB2BPBqe5hmDpK/8qKnQmfvyZvlhb7+3kGNTGz3+UGmXw==
X-Received: by 2002:adf:e68b:: with SMTP id r11mr2814903wrm.138.1582820625175; Thu, 27 Feb 2020 08:23:45 -0800 (PST)
Received: from [192.168.1.64] (24.248.90.146.dyn.plus.net. [146.90.248.24]) by smtp.gmail.com with ESMTPSA id 90sm6742353wro.79.2020.02.27.08.23.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Feb 2020 08:23:44 -0800 (PST)
From: Neil Madden <neil.madden@forgerock.com>
Message-Id: <14708E54-D934-4D74-BF4D-DF75AE549163@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DE13CF75-D1AD-449E-9072-1D1641286474"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Thu, 27 Feb 2020 16:23:27 +0000
In-Reply-To: <CACvH2enmaEC4TRmP27iCMMtnPmpuO1othFwoaR7z0zgu9D8iAQ@mail.gmail.com>
Cc: cose <cose@ietf.org>
To: Andrew Kozlik <andrew.kozlik=40satoshilabs.com@dmarc.ietf.org>
References: <CACvH2enmaEC4TRmP27iCMMtnPmpuO1othFwoaR7z0zgu9D8iAQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/rsKhw-GforRphWBNBCJEA4DSw2E>
Subject: Re: [COSE] draft-ietf-cose-rfc8152bis-algs-06: Incompatible encoding of EdDSA public keys
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2020 16:23:57 -0000

This seems to be an unfortunate choice (mistake?) in RFC 8152. The OKP key type for JOSE (https://tools.ietf.org/html/rfc8037#section-2 <https://tools.ietf.org/html/rfc8037#section-2>) uses the "x" field for the public key (however encoded), so for EdDSA keys the "x" field in an OKP is actually the encoded form specified in RFC 8032: a y-coordinate and the sign bit of the x-coordinate.

IMO the OKP key type in JOSE is a bit of a mess. It would have been better to define separate key types for Montgomery x-only public keys vs EdDSA keys, or else otherwise call that field "pub" or something less likely to be misinterpreted. I'm not sure trying to cram Edwards curves into the EC2 key type makes things any better and may break assumptions in code about EC2 keys always being used for Weierstrass-form curves only.

I think it would be best to either register an errata against RFC 8152 (and fix in the draft) that brings the COSE OKP type into alignment with JOSE and state that the "x" field for EdDSA keys is the RFC 8032 encoded form. Or otherwise define an entirely new key type and deprecate the use of OKP for EdDSA keys.

> On 27 Feb 2020, at 15:14, Andrew Kozlik <andrew.kozlik=40satoshilabs.com@dmarc.ietf.org> wrote:
> 
> Hello everyone,
> 
> I encountered a bug in libfido2 (https://github.com/Yubico/libfido2/issues/136 <https://github.com/Yubico/libfido2/issues/136>), which leads me to propose some changes in COSE encoding of EdDSA public keys. Here is the problem: 
> 
> The standard encoding of EdDSA public keys as defined in https://tools.ietf.org/html/rfc8032#section-5.1.2 <https://tools.ietf.org/html/rfc8032#section-5.1..2> encodes the y-coordinate and the sign of the x-coordinate of the EC point as the public key. COSE on the other hand encodes only the x-coordinate as the public key, see https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-06#section-7.2 <https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-06#section-7.2>. There are two problems with this discrepancy:
> 
> 1. As far as I know, all libraries support only the standard RFC 8032 encoding of public EdDSA keys. Computing the y-coordinate from the x-coordinate and vice versa is not straightforward, because it involves some multi-precision modular arithmetic, making it very problematic to use the COSE format for anyone who is not well versed in the mathematics of ECC. Even if libraries were to support both encodings in the future, it would cause a lot of pointless confusion to developers.
> 
> 2. There is no way to determine the sign of the y-coordinate from knowing only the x-coordinate. Thus when verifying a signature, one has to try both signs for the y-coordinate of the public key and accept the signature if either of the two signature verifications passes.
> 
> To resolve these issues, I propose the following changes:
> 
> 1. In Table 18, https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-06#section-7.1 <https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-06#section-7.1>, the key type of Ed25519 and Ed448 keys should be changed to EC2.
> 
> 2. In Section 7.1.1, https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-06#section-7.1.1 <https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-06#section-7.1.1>, the 'x' parameter of EC2 keys should be allowed to contain either the sign bit or the value of the x-coordinate for the EC point. In addition there should be a requirement stating that if the 'x' or 'y' parameter is present in the structure, then at least one of them MUST be of CBOR type bstr.
> 
> Cheers,
> Andrew Kozlik
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose