[COSE] Updated message recovery algorithm text
Jim Schaad <ietf@augustcellars.com> Fri, 11 September 2020 03:10 UTC
Return-Path: <ietf@augustcellars.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 08C593A0AA0 for <cose@ietfa.amsl.com>; Thu, 10 Sep 2020 20:10:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NRKS18u5wDlS for <cose@ietfa.amsl.com>; Thu, 10 Sep 2020 20:10:03 -0700 (PDT)
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 A50CD3A0A82 for <cose@ietf.org>; Thu, 10 Sep 2020 20:10:02 -0700 (PDT)
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; Thu, 10 Sep 2020 20:09:56 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: cose@ietf.org, 'Benjamin Kaduk' <kaduk@mit.edu>
Date: Thu, 10 Sep 2020 20:09:54 -0700
Message-ID: <008c01d687e9$074a7c20$15df7460$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdaH6NTMr9f6g8mBT3GPFR+CirdIfg==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/vmaGZMixJa6kyCP_zCk7NO4yqN4>
Subject: [COSE] Updated message recovery algorithm text
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: Fri, 11 Sep 2020 03:10:05 -0000
Below is the text that I am proposing for COSE Struct. The changes are all in the last 5 paragraphs. Jim The second scheme is signature with message recovery (an example of such an algorithm is [PVSig]). In this scheme, the message content is processed, but part of it is included in the signature. Moving bytes of the message content into the signature allows for smaller signatures; the signature size is still potentially large, but the message content has shrunk. This has implications for systems implementing these algorithms and for applications that use them. The first is that the message content is not fully available until after a signature has been validated. Until that point, the part of the message contained inside of the signature is unrecoverable. The second is that the security analysis of the strength of the signature is very much based on the structure of the message content. Messages that are highly predictable require additional randomness to be supplied as part of the signature process. In the worst case, it becomes the same as doing a signature with appendix. Finally, in the event that multiple signatures are applied to a message, all of the signature algorithms are going to be required to consume the same number of bytes of message content. This means that the mixing of the different schemes in a single message is not supported, and if a recovery signature scheme is used, then the same amount of content needs to be consumed by all of the signatures. The signature functions for this scheme are: signature, message sent = Sign(message content, key) valid, message content = Verification(message sent, key, signature) Since there have not yet been any message recovery signature algorithms formally defined for COSE, it is very likely that there are going to be issues that arise that have not been anticipated yet. There are some issues that have been identified that the first such algorithm is going to need to make decisions about. These issues include: * The message content being signed is not the same as the message content that is transported. This is because we build a larger message for the signature process. The number of bytes contained in the message may exceed the number of bytes of payload, but not the number of bytes signed. This may lead to privacy considerations if, for example, the application external data contains confidential information. * There may be difficulties in determining where the recovered message matches up with the to be signed value because bytes other than the payload are included in the recovered message. One possible option would be to create a padding scheme to prevent that. * Not all of these signature algorithms take the recovered bytes from the end of the message. If the recovered bytes are taken from the start of the message then, by default, none of the signature payload may be included in the message recovery data. One possible option to deal with this is to reverse the to-be- signed data in the event that bytes are taken from the start rather than end of the message. Signature algorithms are used with the COSE_Signature and COSE_Sign1 structures. At this time, only signatures with appendixes are defined for use with COSE; however, considerable interest has been expressed in using a signature with message recovery algorithm due to the effective size reduction that is possible.
- [COSE] Updated message recovery algorithm text Jim Schaad
- Re: [COSE] Updated message recovery algorithm text Matthew Miller
- Re: [COSE] Updated message recovery algorithm text Benjamin Kaduk
- Re: [COSE] Updated message recovery algorithm text Jim Schaad
- Re: [COSE] Updated message recovery algorithm text Benjamin Kaduk
- Re: [COSE] Updated message recovery algorithm text Rene Struik