[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.