From nobody Tue Feb 4 07:25:15 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26791120130; Tue, 4 Feb 2020 07:25:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ivaylo Petrov via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Cc: Ivaylo Petrov , ivaylo@ackl.io, cose-chairs@ietf.org, iesg-secretary@ietf.org, cose@ietf.org Message-ID: <158082991415.15743.1426981446999578067.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2020 07:25:14 -0800 Archived-At: Subject: [COSE] Publication has been requested for draft-ietf-cose-webauthn-algorithms-05 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 15:25:14 -0000 Ivaylo Petrov has requested publication of draft-ietf-cose-webauthn-algorithms-05 as Proposed Standard on behalf of the COSE working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-cose-webauthn-algorithms/ From nobody Fri Feb 21 22:21:51 2020 Return-Path: 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 7907E120125; Fri, 21 Feb 2020 22:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 jrVerdp7WFPq; Fri, 21 Feb 2020 22:21:23 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5128F12006D; Fri, 21 Feb 2020 22:21:23 -0800 (PST) Received: from [172.16.42.113] (p548DC4D8.dip0.t-ipconnect.de [84.141.196.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48PdWP672dz183C; Sat, 22 Feb 2020 07:21:21 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 604045281.409403-48d283213530afe9b09ae2a1c8a06238 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Sat, 22 Feb 2020 07:21:21 +0100 Message-Id: To: ace@ietf.org, Core , cose@ietf.org, cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: [COSE] Constrained Node/Network Cluster @ IETF107: DRAFT AGENDA X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 06:21:27 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF107. Remember that there is still quite some potential for changes. Conflicts that meet the eye: ROLL vs. COSE/TEEP, LPWAN vs. RATS, and LAKE vs. RATS, WPACK vs. ACE. The latter two might be a bigger problem, while the first two are displaying the inevitable split between security vs. other IoT issues, as is MODEL-T vs. CORE and TXAUTH vs. T2TRG. All times are in PDT =3D=3D UTC - 7 hours. Note that North America is = on DST already during the IETF, while Europe will only go there on March 29, so we are in the three-week period of DST confusion (where the US is one hour closer to the EU than the rest of the year). (Pure UTC times at https://datatracker.ietf.org/meeting/agenda-utc are useful for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten FRIDAY, March 20, 2020 0900-1800 T2TRG/W3C WoT Workshop = https://github.com/t2trg/2020-03-vancouver SATURDAY, March 21, 2020 0830-2200 IETF Hackathon - Plaza Ballroom SUNDAY, March 22, 2020 0830-1600 IETF Hackathon - Plaza Ballroom 1700-1900 Welcome Reception - Regency A/B/C/D 1800-2000 Hot RFC Lightning Talks -- Plaza B/C MONDAY, March 23, 2020 1000-1200 Morning Session I Regency D ART dispatch Dispatch WG - Joint with ARTAREA Regency C INT 6man IPv6 Maintenance WG Plaza B/C IRTF pearg Privacy Enhancements and Assessments = Research Group Regency E SEC *** suit Software Updates for Internet of Things = WG 1330-1530 Afternoon Session I Regency C INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Regency D IRTF irtfopen IRTF Open Meeting Georgia A SEC mls Messaging Layer Security WG Georgia B SEC oauth Web Authorization Protocol WG Plaza A SEC *** rats Remote ATtestation ProcedureS WG 1550-1750 Afternoon Session II Regency F ART webtrans WebTransport WG Regency C IRTF maprg Measurement and Analysis for Protocols Regency E OPS anima Autonomic Networking Integrated Model = and Approach WG Plaza A RTG raw Reliable and Available Wireless WG Plaza B/C SEC secdispatch Security Dispatch WG 1810-1910 Afternoon Session III Georgia A RTG *** roll Routing Over Low power and Lossy = networks WG Georgia B SEC *** cose CBOR Object Signing and Encryption WG Plaza B/C SEC tls Transport Layer Security WG Regency C TSV tsvarea Transport Area Open Meeting TUESDAY, March 24, 2020 1000-1200 Morning Session I Georgia A INT add Adaptive DNS Discovery WG Regency D IRTF*** dinrg Decentralized Internet Infrastructure Regency F SEC acme Automated Certificate Management = Environment WG Regency E SEC *** teep Trusted Execution Environment = Provisioning WG Plaza B/C TSV quic QUIC WG 1330-1530 Afternoon Session I Regency C INT masque Multiplexed Application Substrate over = QUIC Encryption BOF Regency D IRTF coinrg Computing in the Network Research Group Georgia B RTG *** roll Routing Over Low power and Lossy = networks WG Georgia A SEC emu EAP Method Update WG Plaza A SEC *** teep Trusted Execution Environment = Provisioning WG 1550-1720 Afternoon Session II Regency F ART *** core Constrained RESTful Environments WG Plaza A IRTF qirg Quantum Internet Proposed Research Group Georgia B SEC oauth Web Authorization Protocol WG Regency C TSV tsvwg Transport Area Working Group WG 1740-1840 Afternoon Session III Plaza B/C INT 6man IPv6 Maintenance WG Georgia A RTG babel Babel routing protocol WG Regency D RTG detnet Deterministic Networking WG Regency E RTG rift Routing In Fat Trees WG Regency C TSV quic QUIC WG WEDNESDAY, March 25, 2020 0830-0945 Side Meetings / Open Time Regency C tdd Technology Deep Dive 1000-1200 Morning Session I Regency F IRTF*** t2trg Thing-to-Thing Georgia B RTG bier Bit Indexed Explicit Replication WG Regency D SEC txauth Transactional Authorization and = Delegation BOF Regency C TSV quic QUIC WG 1330-1500 Afternoon Session I Regency C ART wpack Web Packaging BOF Regency E IRTF panrg Path Aware Networking RG Georgia A SEC *** ace Authentication and Authorization for = Constrained Environments WG 1520-1650 Afternoon Session II Georgia A model-t Internet Threat Model Plaza A ART *** core Constrained RESTful Environments WG Plaza B/C RTG rtgarea Routing Area Open Meeting 1710-1940 IETF Plenary - Regency C/D/E/F THURSDAY, March 26, 2020 1000-1200 Morning Session I Georgia A ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Georgia B INT dnssd Extensions for Scalable DNS Service = Discovery WG - Joint with HOMENET Georgia B INT homenet Home Networking WG - Joint with DNSSD Regency E IRTF icnrg Information-Centric Networking Regency C SEC privacypass privacy-pass BOF Plaza B/C TSV tsvwg Transport Area Working Group WG 1330-1530 Afternoon Session I Regency F OPS v6ops IPv6 Operations WG Regency D SEC saag Security Area Open Meeting Georgia B TSV taps Transport Services WG 1550-1720 Afternoon Session II Regency C ART httpbis HTTP WG Regency F INT intarea Internet Area Working Group WG Regency E IRTF cfrg Crypto Forum Plaza B/C RTG detnet Deterministic Networking WG 1740-1840 Afternoon Session III Regency E ART uta Using TLS in Applications WG Georgia B INT *** drip Drone Remote ID Protocol WG Regency D OPS anima Autonomic Networking Integrated Model = and Approach WG FRIDAY, March 27, 2020 1000-1200 Morning Session I Plaza B/C INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Regency C SEC tls Transport Layer Security WG 1220-1350 Morning Session II Regency D ART httpbis HTTP WG Regency C IRTF coinrg Computing in the Network Research Group Regency F SEC *** lake Lightweight Authenticated Key Exchange = WG Georgia A SEC *** rats Remote ATtestation ProcedureS WG From nobody Tue Feb 25 06:46:17 2020 Return-Path: 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 403793A0E26 for ; Tue, 25 Feb 2020 06:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.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 85ykjH7AU0z7 for ; Tue, 25 Feb 2020 06:46:13 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 939533A0E28 for ; Tue, 25 Feb 2020 06:46:13 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id v4so2181686wrs.8 for ; Tue, 25 Feb 2020 06:46:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=mwk06RFiGX38qPYWBP8EBcPo9CP6x7KicXLOJ+gGKFM=; b=nDJAuPuBJi0S6tB5FnsEYDoO/nzqmzueR7FhZeXZaJag84wQkBVEvAhYrrXTMINpMX QPHeBFDgzAR4shzghDnSlUhv3y2mLIncOBAv3RI7kk2h6QkOJadezZ3N2bm+pRg5A1WM wdufjcHMmP5qWogo2pQhF3WCgafEgWdI9gPMXg9mBqWD1uaugLpfxVj+jb0qyrdc1nPC RJ8fZILwwSZL3kccFZkLauzy6HMoRAWuW42aez90HjRyJ1ugfZZ1pcXVAXo9VKpy5Ns6 s/2n7FiZBiS+dW2DqG3MDBvUjqF5FwvCe8NreV/7xczQB9cMVuwKZoXooViPKajBM09u tosg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=mwk06RFiGX38qPYWBP8EBcPo9CP6x7KicXLOJ+gGKFM=; b=bWBIQOv0+QgN+zw3rp45VshKNpwZeHZuyn6z49KtgVHNBSnkx2OFEN7SWgLuBLoLUZ uSSE1si/7ksHirGwXjVsVbSlGNjwSFT1zLRS/h5s9bHjVInRtBUJCzC2Smqpds+x2vIP V/wihaFjRu28UBihCtEzhhcQgbV7SDQQ/HUVb2D8c00bQp4/+aLRBesifWmB6xrPp128 9oD2dxiOxrwQ2+uaI+pPpnSge0TUsME9Ecf+XA3vqZvnhHIwXJuv2IsZrGsOOKqm0v/6 0e3JnB5j/y+AQ+5ZZZlqg1FeOH+hPw7ovm+KnB3ME8V/oaqkihXl5QYPuCCBHXEcL+Wd zTsg== X-Gm-Message-State: APjAAAUMiIfkUikQn2DHWr3ikq+lbkUwR7SWWM6BJj+Z3zVUUAZhxnB1 Fd2TyTazvlNHT8uJk/Creql5sNt/jOAL2iKskocRwOaPxxs= X-Google-Smtp-Source: APXvYqz6GylkKUxCUs/tr0cfPMBxJvDB3CBsQWBsLMBMVaj2Gx16LeCAx7OLYkQpyowVVHfXm+z+yqo1S7i854CIoyI= X-Received: by 2002:a5d:4ac8:: with SMTP id y8mr72898263wrs.272.1582641971828; Tue, 25 Feb 2020 06:46:11 -0800 (PST) MIME-Version: 1.0 From: Ivaylo Petrov Date: Tue, 25 Feb 2020 15:45:45 +0100 Message-ID: To: cose Cc: draft-ietf-cose-x509.authors@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [COSE] WGLC of draft-ietf-cose-x509 ENDED X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 14:46:15 -0000 Dear all, The working group last call for [COSE-X509] has ended; thank you to everyone that commented. As no objections were raised, we believe there is consensus that after some minor items are fixed, this document can move forward. Therefore, we will be expecting an updated version of the draft, after which we will provide the shepherd writeup, which would then be followed by a request for publication. - Matthew and Ivaylo COSE Chairs [COSE-X509]: < https://datatracker.ietf.org/doc/draft-ietf-cose-x509/ > From andrew.kozlik@satoshilabs.com Thu Feb 27 07:14:16 2020 Return-Path: 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 AAD0B3A07D0 for ; Thu, 27 Feb 2020 07:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=satoshilabs.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 0iN4tC8y8sAE for ; Thu, 27 Feb 2020 07:14:14 -0800 (PST) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 A15EC3A0B36 for ; Thu, 27 Feb 2020 07:14:14 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id e25so748767edq.5 for ; Thu, 27 Feb 2020 07:14:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=satoshilabs.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=/Y4DuWxYOJhIMFdkFNHQyi5ONZM97IRectPN9how+IA=; b=L5mPK+9LIuUBH+t0jXMMYclFqz2W7gXrupyAV4dAR/NQKbzPap7MUfRdQcru6OuDQJ PKLNYHDEeT520G3tAirAHgRGesPWci10fgnBsQqoR7SSl3rp+aJW0rbyTc6Q+OjaGU7u D5hEaI7dwMWxne5ujYlEvAOF0IQPRt1OhprAZX+BsxdhR+6Agyn38CBkeLGyDZE9D7M1 0gqSWdpe/3k/rujIqlxYJgkPVGxRJr71WuFOJOKffzUEselBbfCKS3DGzEfpMI2/bnNz 8HXCvWfliE4qT25qKCfDySjsPoSpaR1GsesjbDG+bYbIdNyqYGutYgivtDumoww62VB5 EP1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/Y4DuWxYOJhIMFdkFNHQyi5ONZM97IRectPN9how+IA=; b=cof59vgvbNz/cMeWKhCF8VLNGoKXCf7YLLYzMJ8svQak7dH6S/JOZ1UDVlp99W3j/A PL2Mbl8QjMQuKBMHfpamc0YfO22AY5Ik+6rOFBZyh9GiipivQIvBoS9xvLNEFT+vycOm ZU1/Mx8wKWUYanm3mX2aOxqs92v1OVbib1Zw8puxxL8uLOP/lew2A/FMozUn7+dLzWi9 Bbh8IqNoKs5RvPcjDyOvY6zvrq7J4kbUFiMwlbV4BpzR66OdJJmuAUUTGJJpKRMNlnqi eQDFxavNGaxqTV8mGiv6lwr9IVzWBe/W8MVZfXoA5x/6+3hncVEycspIKgD5Ldwglhvi aXqQ== X-Gm-Message-State: APjAAAWlRjOfiP/pfmousdwAMBhd8Xo/LsghijM5Me9vSTbVGocrHkZV 6DOuIfBhRYzM5QYQ2wj2jncW4URcPBjTH0eHwJXQU1QnABwsjQ== X-Google-Smtp-Source: APXvYqyTb6YCe4ZzVGkzjVFKWVCHGU55IDiTT4gUEF+UOeJpur/0RHQVqP6Om5ak6amsRTjQa2RLGGsi8i9yhc+8aGM= X-Received: by 2002:aa7:c5d2:: with SMTP id h18mr4587411eds.182.1582816452697; Thu, 27 Feb 2020 07:14:12 -0800 (PST) MIME-Version: 1.0 From: Andrew Kozlik Date: Thu, 27 Feb 2020 16:14:01 +0100 Message-ID: To: cose@ietf.org Content-Type: multipart/alternative; boundary="000000000000688f28059f902c6f" Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 15:17:20 -0000 --000000000000688f28059f902c6f Content-Type: text/plain; charset="UTF-8" Hello everyone, I encountered a bug in libfido2 ( 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 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. 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, 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, 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 --000000000000688f28059f902c6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

I encountere= d a bug in libfido2 (https://github.com/Yubico/libfido2/issues/136), which leads me to p= ropose some changes in COSE encoding of EdDSA public keys. Here is the prob= lem:

The standard encoding of EdDSA public ke= ys as defined in https://tools.ietf.org/html/rfc8032#section-5.1.2 encodes the y-coo= rdinate 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, se= e https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-0= 6#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-c= oordinate and vice versa is not straightforward, because it involves some m= ulti-precision modular arithmetic, making it very problematic to use the CO= SE 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 fo= r 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#sect= ion-7.1, the key type of Ed25519 and Ed448 keys should be changed to EC= 2.

2. In Section 7.1.1, https://tool= s.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-06#section-7.1.1, the &= #39;x' parameter of EC2 keys should be allowed to contain either the si= gn 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' par= ameter is present in the structure, then at least one of them MUST be of CB= OR type bstr.

Cheers,
Andrew Kozlik
<= /div>
--000000000000688f28059f902c6f-- From nobody Thu Feb 27 08:23:58 2020 Return-Path: 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 ; 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 ; 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 ; Thu, 27 Feb 2020 08:23:47 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id m16so4102237wrx.11 for ; 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 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: Cc: cose To: Andrew Kozlik References: X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 16:23:57 -0000 --Apple-Mail=_DE13CF75-D1AD-449E-9072-1D1641286474 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 = ) 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 = wrote: >=20 > Hello everyone, >=20 > I encountered a bug in libfido2 = (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:=20 >=20 > The standard encoding of EdDSA public keys as defined in = 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= = . There are two problems with this discrepancy: >=20 > 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. >=20 > 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. >=20 > To resolve these issues, I propose the following changes: >=20 > 1. In Table 18, = 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. >=20 > 2. In 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. >=20 > Cheers, > Andrew Kozlik > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose --Apple-Mail=_DE13CF75-D1AD-449E-9072-1D1641286474 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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) 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=3D40satoshilabs.com@dmarc.ietf.org> = wrote:

Hello everyone,

I encountered a bug in = libfido2 (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 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. 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, 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, 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

= --Apple-Mail=_DE13CF75-D1AD-449E-9072-1D1641286474-- From nobody Fri Feb 28 10:25:14 2020 Return-Path: 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 E39773A0E0C for ; Fri, 28 Feb 2020 10:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GDT1TxJqfvKN for ; Fri, 28 Feb 2020 10:25:04 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E153A0E01 for ; Fri, 28 Feb 2020 10:25:03 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 28 Feb 2020 10:24:48 -0800 From: Jim Schaad To: 'Neil Madden' , 'Andrew Kozlik' CC: 'cose' References: <14708E54-D934-4D74-BF4D-DF75AE549163@forgerock.com> In-Reply-To: <14708E54-D934-4D74-BF4D-DF75AE549163@forgerock.com> Date: Fri, 28 Feb 2020 10:24:46 -0800 Message-ID: <036601d5ee64$5c75c520$15614f60$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0367_01D5EE21.4E539690" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLZxn/MzwHIKW6utgQec6Ba19Uf+gJ68ZLophVhh6A= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 18:25:12 -0000 ------=_NextPart_000_0367_01D5EE21.4E539690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This would seem to be more of an issue of what the text label in the OKP key type is. I have no problems with changing this is the COSE document as the text label is completely arbitrary. On the other hand, keeping the correspondence to what is in the JOSE draft also seems to be of importance. It would be easy to make the change and have a note that dealt with the differences however. Andrew, I completely disagree with you that there are two fields are the result of encoding a public key in the EdDSA draft. Section 5.1.2 makes it clear that when you are finished you only have an integer value of 32 octets. There is no separate sign bit so changing it to EC2 would be completely inappropriate. If you look at the examples in section 7 you will see that the Public Key is clearly just a single 32 octet value with no place for a sign bit. I believe that the correct result that has been implemented for both JOSE and COSE is to take encoding that is specified in RFC 8152 and use that as the public key. I know that I compared all of my code with the text vectors in RFC 8152 so that I will be shocked if this is not true. If this is not clear in either document then we need to change that text. Jim From: COSE On Behalf Of Neil Madden Sent: Thursday, February 27, 2020 8:23 AM To: Andrew Kozlik Cc: cose Subject: Re: [COSE] draft-ietf-cose-rfc8152bis-algs-06: Incompatible encoding of EdDSA public keys 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) 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 > wrote: Hello everyone, I encountered a bug in libfido2 (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 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. 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, 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 , 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 ------=_NextPart_000_0367_01D5EE21.4E539690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This would = seem to be more of an issue of what the text label in the OKP key type = is.  I have no problems with changing this is the COSE document as = the text label is completely arbitrary.   On the other hand, = keeping the correspondence to what is in the JOSE draft also seems to be = of importance.  It would be easy to make the change and have a note = that dealt with the differences however.

 

Andrew, I = completely disagree with you that there are two fields are the result of = encoding a public key in the EdDSA draft.  Section 5.1.2 makes it = clear that when you are finished you only have an integer value of 32 = octets.  There is no separate sign bit so changing it to EC2 would = be completely inappropriate.     If you look at the = examples in section 7 you will see that the Public Key is clearly just a = single 32 octet value with no place for a sign bit.

 

I believe = that the correct result that has been implemented for both JOSE and COSE = is to take encoding that is specified in RFC 8152 and use that as the = public key.  I know that I compared all of my code with the text = vectors in RFC 8152 so that I will be shocked if this is not true.  = If this is not clear in either document then we need to change that = text.

 

Jim

 

 

From: COSE = <cose-bounces@ietf.org> On Behalf Of Neil = Madden
Sent: Thursday, February 27, 2020 8:23 AM
To: = Andrew Kozlik = <andrew.kozlik=3D40satoshilabs.com@dmarc.ietf.org>
Cc: = cose <cose@ietf.org>
Subject: Re: [COSE] = draft-ietf-cose-rfc8152bis-algs-06: Incompatible encoding of EdDSA = public keys

 

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) 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.k= ozlik=3D40satoshilabs.com@dmarc.ietf.org> = wrote:

 

Hello everyone,

 

I = encountered a bug in libfido2 (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 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. 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, 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, 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

 

------=_NextPart_000_0367_01D5EE21.4E539690-- From nobody Fri Feb 28 14:41:02 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83CBB3A1F8A; Fri, 28 Feb 2020 14:35:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: kaduk@mit.edu, cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292933152.19931.6594999607859457992@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:31 -0800 Archived-At: Subject: [COSE] cose - Requested session has been scheduled for IETF 107 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:35:40 -0000 Dear Ivaylo Petrov, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. cose Session 1 (1:00 requested) Monday, 23 March 2020, Afternoon Session III 1810-1910 Room Name: Georgia B size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/cose.ics Request Information: --------------------------------------------------------- Working Group Name: CBOR Object Signing and Encryption Area Name: Security Area Session Requester: Ivaylo Petrov Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 60 Conflicts to Avoid: Chair Conflict: core dispatch lamps lpwan saag secdispatch t2trg Technology Overlap: cfrg rats teep Key Participant Conflict: ace cbor People who must be present: Matthew A. Miller Benjamin Kaduk Ivaylo Petrov Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Feb 28 15:14:22 2020 Return-Path: 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 5B6AD3A1D7B; Fri, 28 Feb 2020 15:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 ES3ef0pgZ7Ge; Fri, 28 Feb 2020 15:14:02 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3B93A1E33; Fri, 28 Feb 2020 15:14:01 -0800 (PST) Received: from [172.16.42.113] (p548DC4D8.dip0.t-ipconnect.de [84.141.196.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48Tlj32lpmz1802; Sat, 29 Feb 2020 00:13:59 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 604624438.807252-ba49cb160872526025462a7291810c55 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Sat, 29 Feb 2020 00:13:58 +0100 Message-Id: <0CE57F79-ADE0-45D5-9142-D79F687DC2A1@tzi.org> To: Ace Wg , "core@ietf.org WG" , cose@ietf.org, cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: [COSE] Constrained Node/Network Cluster @ IETF107: FINAL AGENDA X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 23:14:06 -0000 Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF107. Remember that, occasionally, futher agenda changes do happen. Not much change from the DRAFT AGENDA. SUIT has moved to Friday, now on top of 6lo. The other security/not-so-much-security conflicts in the IoT space remain or have just been rearranged: ROLL vs. COSE/TEEP, LPWAN vs. SAAG, and LAKE vs. RATS, WPACK vs. ACE; as are MODEL-T vs. CORE and TXAUTH vs. T2TRG. (A lot of the rooms have changed.) All times are in PDT =3D=3D UTC - 7 hours. Note that North America is = on DST already during the IETF, while Europe will only go there on March 29, so we are in the three-week period of DST confusion (where the US is one hour closer to the EU than the rest of the year). (Pure UTC times at https://datatracker.ietf.org/meeting/agenda-utc are useful for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten FRIDAY, March 20, 2020 0900-1800 T2TRG/W3C WoT Workshop = https://github.com/t2trg/2020-03-vancouver SATURDAY, March 21, 2020 0830-2200 IETF Hackathon - Plaza Ballroom SUNDAY, March 22, 2020 0830-1600 IETF Hackathon - Plaza Ballroom 1700-1900 Welcome Reception - Regency A/B/C/D 1800-2000 Hot RFC Lightning Talks -- Plaza B/C MONDAY, March 23, 2020 1000-1200 Morning Session I Regency D ART dispatch Dispatch WG - Joint with ARTAREA Regency C INT 6man IPv6 Maintenance WG Plaza B/C IRTF pearg Privacy Enhancements and Assessments = Research Group 1330-1530 Afternoon Session I Regency C ART webtrans WebTransport WG Regency D IRTF maprg Measurement and Analysis for Protocols Georgia B SEC mls Messaging Layer Security WG Regency E SEC oauth Web Authorization Protocol WG Plaza A SEC *** rats Remote ATtestation ProcedureS WG 1550-1750 Afternoon Session II Regency F INT add Adaptive DNS Discovery WG Regency C IRTF irtfopen IRTF Open Meeting Regency E OPS anima Autonomic Networking Integrated Model = and Approach WG Plaza A RTG raw Reliable and Available Wireless WG Plaza B/C SEC secdispatch Security Dispatch WG 1810-1910 Afternoon Session III Plaza A RTG *** roll Routing Over Low power and Lossy = networks WG Georgia B SEC *** cose CBOR Object Signing and Encryption WG Plaza B/C SEC tls Transport Layer Security WG Regency C TSV tsvarea Transport Area Open Meeting TUESDAY, March 24, 2020 0830-0945 Side Meetings / Open Time Regency C tdd Technology Deep Dive 1000-1200 Morning Session I Regency D IRTF*** dinrg Decentralized Internet Infrastructure Regency F SEC acme Automated Certificate Management = Environment WG Regency E SEC *** teep Trusted Execution Environment = Provisioning WG Plaza B/C TSV quic QUIC WG 1330-1530 Afternoon Session I Regency C INT masque Multiplexed Application Substrate over = QUIC Encryption BOF Regency D IRTF coinrg Computing in the Network Research Group Georgia A RTG *** roll Routing Over Low power and Lossy = networks WG Regency E SEC emu EAP Method Update WG Georgia B SEC *** teep Trusted Execution Environment = Provisioning WG 1550-1720 Afternoon Session II Regency F ART *** core Constrained RESTful Environments WG Plaza A IRTF qirg Quantum Internet Proposed Research Group Georgia B SEC oauth Web Authorization Protocol WG Regency C TSV tsvwg Transport Area Working Group WG 1740-1840 Afternoon Session III Regency C INT 6man IPv6 Maintenance WG Georgia B INT *** drip Drone Remote ID Protocol WG Georgia A RTG babel Babel routing protocol WG Regency D RTG detnet Deterministic Networking WG Regency E RTG rift Routing In Fat Trees WG Plaza B/C TSV quic QUIC WG WEDNESDAY, March 25, 2020 1000-1200 Morning Session I Georgia B IRTF*** t2trg Thing-to-Thing Georgia A RTG bier Bit Indexed Explicit Replication WG Regency D SEC txauth Transactional Authorization and = Delegation BOF Plaza B/C TSV quic QUIC WG 1330-1500 Afternoon Session I Regency C ART wpack Web Packaging BOF Regency E IRTF panrg Path Aware Networking RG Georgia A SEC *** ace Authentication and Authorization for = Constrained Environments WG 1520-1650 Afternoon Session II Plaza A ART *** core Constrained RESTful Environments WG Georgia A IAB model-t Internet Threat Model Plaza B/C RTG rtgarea Routing Area Open Meeting 1710-1940 IETF Plenary - Regency C/D/E/F THURSDAY, March 26, 2020 1000-1200 Morning Session I Georgia A ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Georgia B INT dnssd Extensions for Scalable DNS Service = Discovery WG - Joint with HOMENET Georgia B INT homenet Home Networking WG - Joint with DNSSD Regency E IRTF icnrg Information-Centric Networking Regency C SEC privacypass privacy-pass BOF Plaza B/C TSV taps Transport Services WG 1330-1530 Afternoon Session I Regency E INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Regency F OPS v6ops IPv6 Operations WG Regency D SEC saag Security Area Open Meeting 1550-1720 Afternoon Session II Regency C ART httpbis HTTP WG Regency E INT intarea Internet Area Working Group WG Regency D IRTF cfrg Crypto Forum Plaza B/C RTG detnet Deterministic Networking WG 1740-1840 Afternoon Session III Plaza A ART uta Using TLS in Applications WG Regency D OPS anima Autonomic Networking Integrated Model = and Approach WG FRIDAY, March 27, 2020 1000-1200 Morning Session I Regency F INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Regency E SEC *** suit Software Updates for Internet of Things = WG Regency C SEC tls Transport Layer Security WG Plaza B/C TSV tsvwg Transport Area Working Group WG 1220-1350 Morning Session II Regency D ART httpbis HTTP WG Regency C IRTF coinrg Computing in the Network Research Group Regency F SEC *** lake Lightweight Authenticated Key Exchange = WG Plaza A SEC *** rats Remote ATtestation ProcedureS WG From nobody Sat Feb 29 01:52:37 2020 Return-Path: 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 531EC3A0D83 for ; Sat, 29 Feb 2020 01:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 MwJ08qF_KJiE for ; Sat, 29 Feb 2020 01:52:33 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A08B13A0D82 for ; Sat, 29 Feb 2020 01:52:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 0815D4EC; Sat, 29 Feb 2020 11:52:31 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id CqbB63-kBe2V; Sat, 29 Feb 2020 11:52:30 +0200 (EET) Received: from LK-Perkele-VII (87-100-246-37.bb.dnainternet.fi [87.100.246.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id D12552308; Sat, 29 Feb 2020 11:52:25 +0200 (EET) Date: Sat, 29 Feb 2020 11:52:25 +0200 From: Ilari Liusvaara To: Jim Schaad Cc: 'Neil Madden' , 'Andrew Kozlik' , 'cose' Message-ID: <20200229095225.GA1903405@LK-Perkele-VII> References: <14708E54-D934-4D74-BF4D-DF75AE549163@forgerock.com> <036601d5ee64$5c75c520$15614f60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <036601d5ee64$5c75c520$15614f60$@augustcellars.com> Sender: ilariliusvaara@welho.com Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 09:52:35 -0000 On Fri, Feb 28, 2020 at 10:24:46AM -0800, Jim Schaad wrote: > > I believe that the correct result that has been implemented for both JOSE > and COSE is to take encoding that is specified in RFC 8152 and use that as > the public key. I know that I compared all of my code with the text vectors > in RFC 8152 so that I will be shocked if this is not true. If this is not > clear in either document then we need to change that text. I am not sure I agree. The correct interpretation for JOSE is to take the contents of "x" field, base64url decode it, and stuff the result raw into Ed25519 signing/verification (as defined by RFC 8032) as an octet string (and "d" is base64url decoded and stuffed raw into Ed25519 signing). I can take the keypair test vector from RFC 8037 and stuff it into program that definitely takes the above interpretation (I wrote it) and it both passes key consistency check and passes signature self- verify check. Now, the same program also supports COSE keys. When coding that support, I assumed that COSE way is straightforward port of JOSE (encode constants as integers, encode base64url'd string as raw bstr), and thus the code just stuffs whatever is in "x" field raw into Ed25519 signing/ verification (as defined by RFC 8032) as an octet string (and "d" is another bstr and stuffed raw into Ed25519 signing as octet string). Now RFC 8152 says: "This contains the x-coordinate for the EC point. The octet string represents a little-endian encoding of x." Which is just plain wrong for Ed25519 and Ed448. As the public key is encoding of y coordinate together with sign bit of x coordinate. And even that COSE should not be concerned with: It should treat RFC 8032 public keys as octet strings. And even for X25519 and X448, it is not quite correct, because the X25519 and X448 public keys are not integers, they are octet strings (which happen to be little-endian encoding of x coordinate of an elliptic-curve point). Now, it is possible to recover the y coordinate of Ed25519 and Ed448 keys from the x coordinate, but the algorithm is fairly slow (due to calculating the lth multiple), and I do not think it has ever been implemented. What I think all COSE implementations of EdDSA do is to stuff the bstr x raw into RFC 8032 EdDSA implementations as octet string (that is definitely what my code is doing). -Ilari From nobody Sat Feb 29 03:32:45 2020 Return-Path: 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 785013A0815 for ; Sat, 29 Feb 2020 03:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=satoshilabs.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 H4Qr_lEXYob4 for ; Sat, 29 Feb 2020 03:32:41 -0800 (PST) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 4169C3A0814 for ; Sat, 29 Feb 2020 03:32:41 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id g19so6668992eds.11 for ; Sat, 29 Feb 2020 03:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=satoshilabs.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sU5yb5VX7HBla2EYzLZiTcRh7YdQz55w4j72dMZi0dQ=; b=i9FSowoKed46xjr3nmJJuXnJsvLcFYGnkFxLu4IY4JIm0N29g66c3IwxcMluFziF8L 0qXATKZ01zdmXfgVUIcIYddPqN2Cqr18vZbLJuOOB7G+IH/ge5+Pd0R62DZmsME+wmJq ThqZh7Wup9SmjwCyeNT3WZKsqtJjWcus0EiPgp4DnSSHldrcFQSxUBJHBc+QpAvC9Ze+ yNS/GO5UWH0uzthNIyMkrWPPOqNXLxsBb0ntz6m5j/347eYlIW9uXMb2xU6Cst/Jz+e3 KoFiwAlTFdfhUTNCuVGxfM7gchLjZpX6NNIFSW2ND17IVCzKl4hJ89+HmWJcBsGRG+tz Qdfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sU5yb5VX7HBla2EYzLZiTcRh7YdQz55w4j72dMZi0dQ=; b=c7KCbzFuE5S3x62y+tzXI4/pKBCkY9DGl8X/aYq9W7FUwGgzfr0si5geAkPtpOrUmp cBd5jsKjRjnPuQ7J/86AS1jL4RFN68MDNBKjRA+wxd0s2mUJ3Jg2cKVkcyBRJBq5IHqT LSO+nL3L+iNCUzpUwT7sZpxyH2qDRBnwpMDzgDeOekFZFsXthRsl33TYAlcHzSs2DNwn tbkzjtwz0c5OFvCvh5RskYHRsEqd4+39ICsCA4delYTce2R3FbgYIsCid6T4mgbv5LZB OhHZOJ8Ohpo9OEXFAEpbfP/a1/oWaWjnbJe5faSlslY1jPkkhdsmEC+fkTeOR6/Us7kh sD+Q== X-Gm-Message-State: APjAAAVr80YddVJrQtwvQ7vkkzofeJVJb6Ax49+em8Zziy3rVRbI8/Bt KT6cckuGIs9/SAJcFZCH1/FpbXLZfVtp6arqv06FcA== X-Google-Smtp-Source: APXvYqyjUv1Gx5sstkf7VEGawA2wJ0kAucrDMXRrS1oMS/KpTiduGFECDNe2S/8OKcixuxn/vlqs/+bKQr5mpRcdlPs= X-Received: by 2002:aa7:d94d:: with SMTP id l13mr7946708eds.328.1582975959569; Sat, 29 Feb 2020 03:32:39 -0800 (PST) MIME-Version: 1.0 References: <14708E54-D934-4D74-BF4D-DF75AE549163@forgerock.com> <036601d5ee64$5c75c520$15614f60$@augustcellars.com> <20200229095225.GA1903405@LK-Perkele-VII> In-Reply-To: <20200229095225.GA1903405@LK-Perkele-VII> From: Andrew Kozlik Date: Sat, 29 Feb 2020 12:32:28 +0100 Message-ID: To: Ilari Liusvaara Cc: Jim Schaad , Neil Madden , cose Content-Type: multipart/alternative; boundary="000000000000c24441059fb54f51" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 11:32:44 -0000 --000000000000c24441059fb54f51 Content-Type: text/plain; charset="UTF-8" Neil and Ilari, thank you for your feedback, you have identified the problem correctly. Based on all of the responses I see that the intention was to define the OKP key type in COSE to be compatible with the JOSE definition, which is something that I wholeheartedly support. I therefore retract my initial proposal of changing the key type to EC2. Clearly then, the COSE definition of OKP which is currently given in RFC 8152 is completely wrong for Ed25519 and Ed448 and needs to be fixed. Neil, I don't think it's necessary to define a separate type for x-only public keys. Changing the name of the 'x' parameter to something more generic like 'pub' would make a lot of sense though, especially seeing as it got Jim so terribly confused. Andrew On Sat, Feb 29, 2020 at 10:52 AM Ilari Liusvaara wrote: > On Fri, Feb 28, 2020 at 10:24:46AM -0800, Jim Schaad wrote: > > > > I believe that the correct result that has been implemented for both JOSE > > and COSE is to take encoding that is specified in RFC 8152 and use that > as > > the public key. I know that I compared all of my code with the text > vectors > > in RFC 8152 so that I will be shocked if this is not true. If this is > not > > clear in either document then we need to change that text. > > I am not sure I agree. > > The correct interpretation for JOSE is to take the contents of "x" > field, base64url decode it, and stuff the result raw into Ed25519 > signing/verification (as defined by RFC 8032) as an octet string > (and "d" is base64url decoded and stuffed raw into Ed25519 signing). > > I can take the keypair test vector from RFC 8037 and stuff it into > program that definitely takes the above interpretation (I wrote it) > and it both passes key consistency check and passes signature self- > verify check. > > Now, the same program also supports COSE keys. When coding that support, > I assumed that COSE way is straightforward port of JOSE (encode > constants as integers, encode base64url'd string as raw bstr), and thus > the code just stuffs whatever is in "x" field raw into Ed25519 signing/ > verification (as defined by RFC 8032) as an octet string (and "d" is > another bstr and stuffed raw into Ed25519 signing as octet string). > > > Now RFC 8152 says: > > "This contains the x-coordinate for the EC point. The octet string > represents a little-endian encoding of x." > > Which is just plain wrong for Ed25519 and Ed448. As the public key is > encoding of y coordinate together with sign bit of x coordinate. And > even that COSE should not be concerned with: It should treat RFC 8032 > public keys as octet strings. > > And even for X25519 and X448, it is not quite correct, because the > X25519 and X448 public keys are not integers, they are octet strings > (which happen to be little-endian encoding of x coordinate of an > elliptic-curve point). > > Now, it is possible to recover the y coordinate of Ed25519 and Ed448 > keys from the x coordinate, but the algorithm is fairly slow (due to > calculating the lth multiple), and I do not think it has ever been > implemented. > > What I think all COSE implementations of EdDSA do is to stuff the > bstr x raw into RFC 8032 EdDSA implementations as octet string (that is > definitely what my code is doing). > > > -Ilari > --000000000000c24441059fb54f51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Neil and Ilari, thank you for your feedback, you have= identified the problem correctly. Based on all of the responses I see that= the intention was to define the OKP key type in COSE to be compatible with= the JOSE definition, which is something that I wholeheartedly support. I t= herefore retract my initial proposal of changing the key type to EC2.
=

Clearly then, the COSE definition of OKP which is curre= ntly given in RFC 8152 is completely wrong for Ed25519 and Ed448 and needs = to be fixed. Neil, I don't think it's necessary to define a separat= e type for x-only public keys. Changing the name of the 'x' paramet= er to something more generic like 'pub' would make a lot of sense t= hough, especially seeing as it got Jim so terribly confused.

Andre= w

On Sat, Feb 29, 2020 at 10:52 AM Ilari Liusvaara <ilariliusvaara@welho.com> w= rote:
On Fri, Fe= b 28, 2020 at 10:24:46AM -0800, Jim Schaad wrote:
>
> I believe that the correct result that has been implemented for both J= OSE
> and COSE is to take encoding that is specified in RFC 8152 and use tha= t as
> the public key.=C2=A0 I know that I compared all of my code with the t= ext vectors
> in RFC 8152 so that I will be shocked if this is not true.=C2=A0 If th= is is not
> clear in either document then we need to change that text.

I am not sure I agree.

The correct interpretation for JOSE is to take the contents of "x"= ;
field, base64url decode it, and stuff the result raw into Ed25519
signing/verification (as defined by RFC 8032) as an octet string
(and "d" is base64url decoded and stuffed raw into Ed25519 signin= g).

I can take the keypair test vector from RFC 8037 and stuff it into
program that definitely takes the above interpretation (I wrote it)
and it both passes key consistency check and passes signature self-
verify check.

Now, the same program also supports COSE keys. When coding that support, I assumed that COSE way is straightforward port of JOSE (encode
constants as integers, encode base64url'd string as raw bstr), and thus=
the code just stuffs whatever is in "x" field raw into Ed25519 si= gning/
verification (as defined by RFC 8032) as an octet string (and "d"= is
another bstr and stuffed raw into Ed25519 signing as octet string).


Now RFC 8152 says:

"This contains the x-coordinate for the EC point.=C2=A0 The octet stri= ng
represents a little-endian encoding of x."

Which is just plain wrong for Ed25519 and Ed448. As the public key is
encoding of y coordinate together with sign bit of x coordinate. And
even that COSE should not be concerned with: It should treat RFC 8032
public keys as octet strings.

And even for X25519 and X448, it is not quite correct, because the
X25519 and X448 public keys are not integers, they are octet strings
(which happen to be little-endian encoding of x coordinate of an
elliptic-curve point).

Now, it is possible to recover the y coordinate of Ed25519 and Ed448
keys from the x coordinate, but the algorithm is fairly slow (due to
calculating the lth multiple), and I do not think it has ever been
implemented.

What I think all COSE implementations of EdDSA do is to stuff the
bstr x raw into RFC 8032 EdDSA implementations as octet string (that is
definitely what my code is doing).


-Ilari
--000000000000c24441059fb54f51--