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

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 18 January 2020 16:24 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0213120077 for <secdispatch@ietfa.amsl.com>; Sat, 18 Jan 2020 08:24:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 6PzMxT-mAKee for <secdispatch@ietfa.amsl.com>; Sat, 18 Jan 2020 08:24:36 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08B312002F for <secdispatch@ietf.org>; Sat, 18 Jan 2020 08:24:35 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 363BC3897A for <secdispatch@ietf.org>; Sat, 18 Jan 2020 11:24:05 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 54764C4C for <secdispatch@ietf.org>; Sat, 18 Jan 2020 11:24:34 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: IETF SecDispatch <secdispatch@ietf.org>
In-Reply-To: <DM6PR11MB3883DB8289E4EE1CDEFE7BA89B310@DM6PR11MB3883.namprd11.prod.outlook.com>
References: <DM6PR11MB388377406A1AAEDCA397749C9B360@DM6PR11MB3883.namprd11.prod.outlook.com> <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> <c0f620d7-4e22-18a5-c168-f66b737cae86@cs.tcd.ie> <CAPwdP4PG3i5-_BuVMdH0iMcJCT40xejoM=J3dH=pPO61T-F4Aw@mail.gmail.com> <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> <BYAPR11MB3478E8F964A34EDD232CFB03EE310@BYAPR11MB3478.namprd11.prod.outlook.com> <052d3ee0-41ae-c4f4-7013-6286942c468a@cs.tcd.ie> <DM6PR11MB3883DB8289E4EE1CDEFE7BA89B310@DM6PR11MB3883.namprd11.prod.outlook.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Sat, 18 Jan 2020 11:24:34 -0500
Message-ID: <3140.1579364674@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/k-KKP2BPK1ZIP-Tn4w4q9jy8hl4>
Subject: Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS?
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Jan 2020 16:24:38 -0000

Mike Ounsworth <Mike.Ounsworth@entrustdatacard.com> wrote:
    > Draft-ounsworth-pq-composite-sigs defines ASN.1 structures for carrying
    > multiple SubjectPublicKeyInfo, AlgorithmIdentifier, and BIT STRING
    > (signature values), in a way that will be drop-in for PKIX-like
    > protocols.

    > You keep mentioning parameter sets and "what if they change?". I really
    > don't see why that's relevant. Draft-ounsworth-pq-composite-sigs is
    > algorithm-agnostic; orthogonal to the choice of algorithms by NIST or
    > their encodings.

In particular, it seems to me that we could add these multiple entries to
certificates, using dummy algorithms, and test them in the field against
existing browsers, web servers, IDS, firewalls, etc.

We know that this system has to work with systems that don't understand it
yet.

I don't know if LAMPS is the right group though.
It feels like it needs a new WG.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-