Re: [lamps] PQ-composite OR or K-of-N logic

Russ Housley <housley@vigilsec.com> Fri, 22 April 2022 16:41 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8CA03A1882 for <spasm@ietfa.amsl.com>; Fri, 22 Apr 2022 09:41:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 cJwCP60FTXMI for <spasm@ietfa.amsl.com>; Fri, 22 Apr 2022 09:41:01 -0700 (PDT)
Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78C53A18FD for <spasm@ietf.org>; Fri, 22 Apr 2022 09:40:52 -0700 (PDT)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 3AB9C144929; Fri, 22 Apr 2022 12:40:50 -0400 (EDT)
Received: from [10.0.1.2] (pfs.iad.rg.net [198.180.150.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 2C5D114485A; Fri, 22 Apr 2022 12:40:50 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <f2fb2b2459fe42818348838eb14cc2ac@EX13D01ANC003.ant.amazon.com>
Date: Fri, 22 Apr 2022 12:40:49 -0400
Cc: LAMPS <spasm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <29E39FB1-D8E5-40E9-AFC0-5A8EBBB705DF@vigilsec.com>
References: <f2fb2b2459fe42818348838eb14cc2ac@EX13D01ANC003.ant.amazon.com>
To: "Kampanakis, Panos" <kpanos=40amazon.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/6oHkZlh8CCJHia12byawlx6mQyo>
Subject: Re: [lamps] PQ-composite OR or K-of-N logic
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2022 16:41:06 -0000

(No hats)

On the call, many people expressed concern that the approach in the I-D tries to bind the signature verification policy to a public key.  These people prefer an approach where the relying party applies their own policy.  I tend to agree that the verifier should determine the policy.

Russ

> On Apr 21, 2022, at 11:00 PM, Kampanakis, Panos <kpanos=40amazon.com@dmarc.ietf.org> wrote:
> 
> Hi all,
> 
> This was discussed in the interim meeting yesterday, but I promised to also bring it up to the list. 
> 
> https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/ includes a Composite-OR and a Composite-OR-Legacy mode. And Mike also mentioned K-of-N logic in the meeting. These allow for the signer to define the verification logic of the composite signature. As many pointed out in the interim meeting yesterday, it is counter intuitive for the signer to tell the verifier what to verify. If the verifier does not trust one of the signatures in the composite signature it can make a decision on what to do based on its policy. It could fail unless all sigs verify or do something else. 
> 
> Adding granularity in the signature to tell the signer what to do not only changes what we know and use today, but it also opens cans of worms with complexity and mistakes that could happen in implementations. 
> 
> I suggest to just define one mode. That is a composite sig is two signatures of the same thing with two algorithms using two keys. The signer is supposed to verify the composite signature. How it does that is beyond this draft. 
> 
> Rgs, 
> Panos