Re: [Suit] Manifest authentication field ordering

Michael Richardson <> Mon, 25 November 2019 23:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C460C120F9F for <>; Mon, 25 Nov 2019 15:16:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A3AS3imngCFl for <>; Mon, 25 Nov 2019 15:16:16 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CF12E120024 for <>; Mon, 25 Nov 2019 15:16:15 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTPS id CADB51F47D; Mon, 25 Nov 2019 23:16:13 +0000 (UTC)
Received: by (Postfix, from userid 179) id C73871422; Tue, 26 Nov 2019 07:16:08 +0800 (+08)
From: Michael Richardson <>
To: Brendan Moran <>
cc: suit <>
In-reply-to: <>
References: <>
Comments: In-reply-to Brendan Moran <> message dated "Mon, 25 Nov 2019 12:10:57 +0000."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Tue, 26 Nov 2019 00:16:08 +0100
Message-ID: <>
Archived-At: <>
Subject: Re: [Suit] Manifest authentication field ordering
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Nov 2019 23:16:18 -0000

Brendan Moran <> wrote:
    > I’ve been looking at PQC authentication primitives, particularly
    > HSS/LMS [1] and XMSS [2]. These signature schemes require the
    > processing of quite large signature blocks: I expect a Winternitz
    > parameter of w=8 to be common, which makes the signature size 1088
    > bytes just for the Winternitz signature, without the Merkle tree
    > components.

    > These large signatures can easily cause the manifest to violate
    > REQ.SEC.MFST.CONST if the authentication section and the manifest are
    > treated as a single unit, specifically:

Thank you for thinking about this now!

    > However, I think we should apply a slightly more relaxed approach here:
    > Only the manifest itself, not the authentication wrapper, needs to fit
    > in internal memory. Conveniently, most of these signature schemes can
    > support a modular processing scheme, where the whole signature does not
    > need to be loaded into RAM at once in order to validate a signature,
    > with no loss of security.

I agree with this idea.

    > 1.  Parse COSE_Sign/COSE_Sign1 object
    > 2.  Construct & digest the Sig_structure
    > 3.  Validate the Sig_structure digest with the COSE_Signature object

I suspect that many will need an illustration.

    > There is another option, but it inflates the size of the authentication
    > wrapper by one digest: instead of using COSE_Sign in detached mode, we
    > place a digest in the COSE_Sign as the payload. That digest is, in
    > turn, the digest of the manifest.

So, we would run a digest (say, SHA256) of the manifest, and then sign that.
The signining operation would (implicitely) create a second digest in the
signature block, which is why you are saying it costs an extra digest.

The problem that I see with this is that we are forced to select a digest at
least as strong as the security of the HSS/LMS/XMSS or future PQC primitive.
With the doubly-signed COSE_Sign payload (once with ECDSA+SHA256, the second
time with the PQC method), then we don't have any specific dependancy in
the PQC path on the SHA256.

Is this a serious concern?  I don't know, because I don't know if SHA256 will
survive.  I think that it will, and there are hash-based signatures that
assume it will, but it seems imprudent to assume this.

    > My recommendation is to make two changes:

    > 1.  Order of fields:
    > *   CWT List
    > *   List of COSE_Sign/COSE_Sign1/COSE_Mac
    > *   Manifest
    > 2.  COSE_Sign contains a SUIT_Digest of the Manifest.

    > This would allow seek-free, fully modular processing of the manifest,
    > without the need to hold both the manifest and any signature primitives
    > in RAM at the same time.

This seems reasonable to me.

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-