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

"Markku-Juhani O. Saarinen" <> Mon, 20 January 2020 14:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB88F1200B7 for <>; Mon, 20 Jan 2020 06:40:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Q7FRhX4hCuhc for <>; Mon, 20 Jan 2020 06:40:27 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 43073120041 for <>; Mon, 20 Jan 2020 06:40:27 -0800 (PST)
Received: by with SMTP id w8so13393116qts.11 for <>; Mon, 20 Jan 2020 06:40:27 -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=mNLJ+gmBPcKcXzRZFET842T42sHAD21sLULZnObxKEQ=; b=Sq9TX+KaWUM1o71C1OIonmiD8Ye3KNlLSCmVO3aUf69bzhBCKDl/gjSIBekPpnEgpe d6dJj2FXB581kiECEQJdDGHilJJYINSKnBGZth9Tw5QPVrqDjp6rcA3OhAovvIBgX82X xSh8O3/W35bZfuON6/M3x18DHhNx7+dqSPqj+FehtmRkkNld/zzxkBOvOnb+u9zLgaxC rKtA90aKjvwd3BAhZMKoH8hDF5HfEdxBGzi+wlizMvknZY+KNnfXNvif0+KIDO40JICY e1fJeIJGHMnZ8EsrEWcjWCCjRXxsPulmXOQPw7xMEmY7UEjMCXcGPOAs7UTNeCaspiQg MfKg==
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=mNLJ+gmBPcKcXzRZFET842T42sHAD21sLULZnObxKEQ=; b=Cq+mryMaEw7Sog7bHumINB7t1joUB8UYP4ZRHuCVQ7u+pZrqeFuP/V0q8tddmxX/zF fU9st6lIxlfPVnmkX+YLtJJ8Nk0ifpzkM8pMiZ1HGgIElOTkWoF2GRCFxsShILf56N4v woBdEs5QsNWnr+/25T1tGUs9CgUcpkPhuDa4EHUy9fqjtB/H1fL9OMsiqU8xFOzfdafO e5pQfq+dBnWPt497VI99K0v6j4qg6kPazF4ZzwgZ8Zd6Rfpsw45Zx5K4rxDwRAZ39sF2 LV+C1xixAr8QzxwA0r2ojGmosLVeJIOY4DhfTeXYlchaXTG8aJq1W7LELfYQSRxQnSkK Mt8g==
X-Gm-Message-State: APjAAAUsl9OMOlKWndo4nIos3wenH2Kkib7cuEjF3mAMu3sPV5AM2dBx LvBnaA7nzyJe9/P8DvyouPMp3liN5Y6eTfB6Xrn/nw==
X-Google-Smtp-Source: APXvYqxE+SNhuohNnbBSJ4PtDLfaG3W5WIr1uCdWzTKTBO02oVRBAWOY31Rr/YtikWg1U2DYlhSBbeQiOBk+z6CmUb8=
X-Received: by 2002:ac8:21ec:: with SMTP id 41mr21319185qtz.242.1579531226305; Mon, 20 Jan 2020 06:40:26 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <3140.1579364674@localhost> <> <15967.1579382030@localhost> <> <24181.1579453158@localhost> <> <>
In-Reply-To: <>
From: "Markku-Juhani O. Saarinen" <>
Date: Mon, 20 Jan 2020 14:40:15 +0000
Message-ID: <>
To: Eric Rescorla <>
Cc: Michael Richardson <>, IETF SecDispatch <>
Content-Type: multipart/alternative; boundary="000000000000a7e823059c934553"
Archived-At: <>
Subject: Re: [Secdispatch] [EXTERNAL]Re: 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: Mon, 20 Jan 2020 14:40:34 -0000

On Mon, Jan 20, 2020 at 1:12 PM Eric Rescorla <> wrote:

> The OQS implementation seems to currently treat hybrid keys and signatures
>> simply as OCTET STRING blobs and assigns an arbitrary OID for each such
>> pair; I got 1.3.9999.2.2 for a  p256_dilithium2 cert I just created. They
>> emphasize that this is research code and not for production; the OID is of
>> course not valid and the key/signature format is not properly documented as
>> far as I know.
>> This kind of solution would require n*m OIDs -- perhaps this is
>> manageable, perhaps not -- the number of ciphersuites we used to have in
>> TLS is an indication that things may get out of hand, especially if we
>> further consider different hash functions used for signatures. Anyway, the
>> additional ASN.1 structure bytes introduced by the draft would essentially
>> document the structure of such blobs and put them under a single and/or a
>> small number of OIDs. (Correct me if I'm wrong.)
> It's not clear to me that this level of complexity is required. At least
> on the Web, each algorithm would need to be individually considered by CABF
> and the browser vendors, so having a lot of flexibility here isn't that
> much of an asset, and having multiple tiers of parameters is not great. So,
> absent some evidence that we need this level of flexibility, I tend to
> think the one-oid-per-combo approach is fine.
> It might still be worth having an RFC which defined how to mint new oids,
> but that need not have complex on-the-wire internal structure.


I'd be fine with either way (on the hardware firmware front) and colleagues
working on the TLS code comment that they don't see much difference in
implementation complexity either. The additional structure is certainly
helpful in the experimentation phase and is there to make things easier and
more robust, not harder. We would just like to have at least one open
specification for this thing, and preferably not more than one.

Basically the only additional structure carried here is the OIDs for the
key and signature components. Their lengths need to be encoded anyway, so
some structure is needed.

The PQC binary formats don't define what kind of keys/signatures they are
or how long they are. So I see the advantage of having that information
available at least somewhere. Combining several OIDS directly into a single
OID, or having to go through IANA to get a one or two dozen new OIDs for
each variant or hash function combination seems clumsy.

A couple of additional technical points:
- The reason why I mentioned SHA3/SHAKE for RSA and ECC is that this would
seem to allow message hashing to be performed only once, rather than twice
(at least for Dilithium and Falcon).
 - We don't see this as being as widely used for TLS server authentication
as for smart cards, secure elements and similar applications that can't
just switch or negotiate certificate chains on the fly. I work on the
hardware side myself and especially there we have additional considerations
such as hardcoded cert chains and FIPS certification, which is currently
only available for the hybrid case. I wouldn't want to leave the issuance
of OIDs for this purpose at the mercy of TLS folks, which is just one of
many applications of this format.

- markku

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