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

Eric Rescorla <> Mon, 20 January 2020 13:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D2E012011C for <>; Mon, 20 Jan 2020 05:12:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 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_NONE=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 SctgO03QHQv4 for <>; Mon, 20 Jan 2020 05:12:44 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE0A7120090 for <>; Mon, 20 Jan 2020 05:12:43 -0800 (PST)
Received: by with SMTP id y4so33786817ljj.9 for <>; Mon, 20 Jan 2020 05:12:43 -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=otvvvWDPyrN/+pbWsPwoEuewDWcnjhCOJCEiIouQME0=; b=gmmWVz4t9slV0Tk+Ej980mjUNltbwqitWyD4GOC6MRW6Bfb/w/JOBktQNW2A3LpuNj /oH3Fi9o+FQiAHVtqZkJ+wtrylyZ36XP5JfPRC5xoJBxyYGhc8g+0IKmtZ8cmkXhvPao QVZA0U+yXRyerCrX3ZMatESQ3hRIdHldNzBaT2/Z5JAPXUneXOWnAO2jPpVrsYyuvKrr xcVGtrJBJo8DBzqfZTMfYfRGfGAcNkNBEV0u2g1Xde5VUG5NJE4MW7pjhFOBb3YVh/ED xvzoLRjDRffvJZ44QXMAe3AFRcQASpmp4teMHrJFX6pHDfz9C2yhMx1nF+vQPcXh9IgU 237g==
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=otvvvWDPyrN/+pbWsPwoEuewDWcnjhCOJCEiIouQME0=; b=Qhrh1MXLqOwkpRxXd5YJ3g6xAMyIwIYCCntKwHcJc3oDAh5L5bYcmDD7QWTq9+ykPH HbEIPoGrtaLXjHzyzVHKbs8e30BaPT2EI/6DVBsuTJDUuxS7JiIZZHK+3xgoC84n8GHH 9uG/aXjfAdO6OG2hRRGgtjriJcpRazSaBXiOpxoXdYTLqwGWWJf6mrf0x59q/qMkFDrZ Nc6CTx0CIuZNOmIndpy1BBaVZ5aWFWHpAg+Gn//qQisuJRGJz62ufSMeWoy8ZmRGB7He L5dXMSgAFSpyL4GYfHVASLZ9W/BBO7g3r5vhQryjEm/4P5QB3aeuyyj1BjlKoKMbdf9o 5XfQ==
X-Gm-Message-State: APjAAAUGEe7/Il93lwX9PizpvCaRzkSoy8Fs/RZlpCRlfwNlfZxc4mlo JMgJlMLwLhojYHj9hnPGkLdW6xnljQAO9+KIwR9aMQ==
X-Google-Smtp-Source: APXvYqwzPwwSL69FtVhEVn4xHUh0oTt7HCvIdfiAHcoFwczajTv13lHPRBghgSaSouYl7NHSTdWwaFs+vLjW780bemI=
X-Received: by 2002:a2e:9510:: with SMTP id f16mr13568938ljh.249.1579525962084; Mon, 20 Jan 2020 05:12:42 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <3140.1579364674@localhost> <> <15967.1579382030@localhost> <> <24181.1579453158@localhost> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Mon, 20 Jan 2020 05:12:04 -0800
Message-ID: <>
To: "Markku-Juhani O. Saarinen" <>
Cc: Michael Richardson <>, IETF SecDispatch <>
Content-Type: multipart/alternative; boundary="000000000000e24378059c920bd7"
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 13:12:50 -0000

On Sun, Jan 19, 2020 at 11:22 AM Markku-Juhani O. Saarinen <> wrote:

> On Sun, Jan 19, 2020 at 4:59 PM Michael Richardson <>
> wrote: hybrid fall-back because it was already being shipped out.

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