Re: [Secdispatch] Can Composite sigs move back to LAMPS?

"Markku-Juhani O. Saarinen" <> Thu, 16 January 2020 21:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93783120026 for <>; Thu, 16 Jan 2020 13:21:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zZ895iBTuJVf for <>; Thu, 16 Jan 2020 13:21:33 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB68312004A for <>; Thu, 16 Jan 2020 13:21:32 -0800 (PST)
Received: by with SMTP id p2so9782691qvo.10 for <>; Thu, 16 Jan 2020 13:21:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fKDAuzyhKxqTHXJJ2CC0m4LJfvxFbY8FU2dHwK4d+kU=; b=x1/ccfJU/o+PQQgGBSFHcSc3nfKcj7gaDEfwKDUdUkhKjSlDOHdl+iMqLT0XhQAJKA RHv1YVEQJLJL3ib/7WHF08yuy+pgH9W9AWVloT6URF3rBTi6H9RgOeZVfjFDligoFqdo T+9u1JmTYcTZ9828s1AyOO5Zn49sZUeklEucNQy0ZYT1fKxEcTWSjeYjui4i9DjZBOUv K7Pjogw30atmw5NHkTpLT7TV5T5ztZH1yqHT6SYzZjbqLqkB96+TydxP8Akru8oi5Pws gM/vGeNdwqgld6yppQ8sH001HOyqS9Uc5jrmeqUZlgRPspgIOQeT0aoJZMhnW/DomS70 hV5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fKDAuzyhKxqTHXJJ2CC0m4LJfvxFbY8FU2dHwK4d+kU=; b=WTbaAl5Nf91P/b6J0PLoOj6juCNpNyNGg39W7pyUoS8W0coOFV8O3Kk7pb7uVVUlWp BnE7O6yQYKS+jQWfMk4iOMdlJQyxsZUVLIQVHMf5WOmWref0lerKXft0Z1wPbQUA7UPz 8eb5qoQJd0pBJO8OM8JEJ7Ep45+ayYGzR0ZjD+WPTcq21lrM7a9AnQrzcYQDMwAPwLOp zpncx0rd4qpXTUCw6lS2HEDJ+tTxUXGeqQXN9Tf8amyb+uvORG7s6A2l6Foe8CkUkK6U 83rto9UJp1F9GRoR0Re7PCwuuCtr/sPrycaT7dJEs4lS4b1z9pSVBa3Hvcmj+ywfIkLB Cxmw==
X-Gm-Message-State: APjAAAWKLGVZla1tqngUh2c6uUipSAMND47pI3d6x6eahevxQRm1Xcl0 zxoFAqJhHWgUN7sCPnH8yJ91lH3KnA1fSUzI1TILXexzjmI=
X-Google-Smtp-Source: APXvYqyaScsshZGD+6+TwFJaj7wCsBCPiaO2e30GLpPlikpgLgxVYHhsORVtkJFHk1uGRVXyiZLVxfhyY6Wo5I1tc5o=
X-Received: by 2002:a05:6214:14b3:: with SMTP id bo19mr4619082qvb.93.1579209692012; Thu, 16 Jan 2020 13:21:32 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: "Markku-Juhani O. Saarinen" <>
Date: Thu, 16 Jan 2020 21:21:21 +0000
Message-ID: <>
To: Mike Ounsworth <>
Cc: IETF SecDispatch <>
Content-Type: multipart/alternative; boundary="000000000000b7f88e059c4868c1"
Archived-At: <>
Subject: Re: [Secdispatch] Can Composite sigs move back to LAMPS?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Jan 2020 21:21:37 -0000

On Thu, Jan 16, 2020 at 7:13 PM Mike Ounsworth <> wrote:

> Following up on in-room discussions at 106, and the ensuing list
> discussions, I'd like to ask for confirmation of the following points:
> 1. There is enough interest in an obvious-and-straightforward
> implementation of composite signatures to continue working on it?
>    1a. The current draft for this is draft-ounsworth-pq-composite-sigs-02

I'd certainly like this to proceed as it the only document of this type
that is currently alive in IETF (as far as I know).

As everyone knows, the NIST PQC process will soon be in its final
third-round stretch and we're not the only vendor who is already quite
familiar with the various proposals, has implemented them, and are in the
process of making them commercially available in cooperation with PKI
vendors. We don't want to end up in a nightmare scenario where each vendor
pushing their own kind of dual/hybrid/composite/twin/double/mixed signature
solution of highly variable design quality.

In some ways IETF is perhaps behind the curve here as FIPS certification
guidelines are being created for exactly the types of technologies that
"draft-ounsworth-pq-composite-sigs-02" discusses. See e.g. "In
particular, a hybrid mode for signatures consists of two signatures. The
mode is valid if and only if both signatures are valid." Hence the need for
standardization of composite signatures.

Stephen Farrell referred to CVE-2020-0601 --  I don't see how composite
signatures is related to specific parameter representations. That has not
been proposed, apart from OID identifiers for a type of composite
signature. The composite can even be made up of ECC and RSA signatures. It
is just an abstraction intended to help with the transition to the next set
of standards, which is very much happening as it has been on e.g. the USG
roadmap at least since the CNSA announcement in 2015.

> 2. SecDispatch is assigning this back to LAMPS?
>    2a. The current draft might not be the most obvious-and-straightforward
> implementation; we're willing to simplify until it's in-scope for LAMPS.

This bouncing back and forth seems symptomatic of IETF. Those of use who
are working on this technology will just have to "follow the specification
around" if that happens.

Anyway let's keep working on it. I'd be even ready to help push it through
as "informational" on the strength of having interoperable industry
implementations. Currently the level of detail is not sufficient for that,
but we should be able to iterate enough detail in there if we do a little
bit of engineering interop. As to what is the most appropriate forum for
that, I'm open to suggestions.

- markku

Dr. Markku-Juhani O. Saarinen <> PQShield, Oxford UK.