Re: [core] draft-ietf-core-oscore-groupcomm: Question signature length

Jim Schaad <ietf@augustcellars.com> Wed, 23 January 2019 04:13 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703D5130E1C; Tue, 22 Jan 2019 20:13:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 PtH9G4GmsWGG; Tue, 22 Jan 2019 20:13:48 -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 04281130E13; Tue, 22 Jan 2019 20:13:47 -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; Tue, 22 Jan 2019 20:13:41 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Marco Tiloca' <marco.tiloca@ri.se>, draft-ietf-core-oscore-groupcomm@ietf.org
CC: core@ietf.org
References: <000601d4a896$c298edb0$47cac910$@augustcellars.com> <f6dcbd45-8f20-62d4-bd56-0fe65a3a1658@ri.se>
In-Reply-To: <f6dcbd45-8f20-62d4-bd56-0fe65a3a1658@ri.se>
Date: Tue, 22 Jan 2019 20:13:40 -0800
Message-ID: <085301d4b2d2$073bc1a0$15b344e0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQJoze0VeTYOIUpoM5k41nS9VL6J/gGiGkBCpIb1m/A=
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/ee149hXdIg1vM_qWc-8xkDnsSG0>
Subject: Re: [core] draft-ietf-core-oscore-groupcomm: Question signature length
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jan 2019 04:13:50 -0000


> -----Original Message-----
> From: Marco Tiloca <marco.tiloca@ri.se>
> Sent: Wednesday, January 16, 2019 7:06 AM
> To: Jim Schaad <ietf@augustcellars.com>; draft-ietf-core-oscore-
> groupcomm@ietf.org
> Cc: core@ietf.org
> Subject: Re: draft-ietf-core-oscore-groupcomm: Question signature length
> 
> Hello Jim,
> 
> Thanks for your comment!
> 
> We have considered it and plan the following updates:
> 
> 1) In Section 2, the Common Security Context can include a further optional
> parameter "Counter Signature Curve", with value from the COSE Elliptic
> Curves registry. This parameter indicates the curve to use for the algorithm
> specified in the "Counter Signature Algorithm" parameter.
> 
> 2) In Section 3, the "algorithms" array of the external_aad would be further
> extended as:
> 
> algorithms : [alg_aead : int / tstr , alg_countersign : int / tstr ,
> ?crv_countersign : int / tstr]
> 
> where "crv_countersign" contains the Counter Signature Curve from the
> Common Security Context.

Ok - so there are a couple of questions that following out from this.

How does one treat RSA as a counter signature?  It does not have a curve.

How does one treat the hash signature algorithm that is being brought into the COSE working group?

How does one treat my new QUARK signature algorithm.  It has the property that it uses Quantum entanglement and you need only look at one Qbit in validating the signature.  After it has been examined the signature is going to be shorter.  This means that the length of the signature is always changing depending on how many times it has been validated. 

The last three items don't have the property of having a curve so there is nothing to put into that proposed new field.

Jim


> 
> 
> Best,
> /Marco
> 
> On 1/10/19 4:44 AM, Jim Schaad wrote:
> > I want to verify that you understand the following is true.
> >
> > It is not possible based on just the content of the message to
> > determine where the encrypted body ends and the signature begins.
> >
> > To see why this is the case, if the signature algorithm in the context
> > is EdDSA then it could be either signed with the x25519 curve or the
> > x448 curve.  The same thing is true with ECDSA signatures as the value
> > ES256 implies that the hash used is SHA-256 but it does not require
> > that the curve used to sign is P-256.  It can be any of the curves
> > that would be valid for this hash function.
> >
> > It might be nicer if there was a signature length encoded someplace so
> > that the two values can easily be separated.
> >
> > Jim
> >
> >
> 
> --
> Marco Tiloca
> Ph.D., Senior Researcher
> 
> RISE Research Institutes of Sweden
> Division ICT
> Isafjordsgatan 22 / Kistagången 16
> SE-164 40 Kista (Sweden)
> 
> Phone: +46 (0)70 60 46 501
> https://www.ri.se
>