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

Santosh Chokhani <santosh.chokhani@gmail.com> Tue, 03 May 2022 17:49 UTC

Return-Path: <santosh.chokhani@gmail.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 72140C1595E4 for <spasm@ietfa.amsl.com>; Tue, 3 May 2022 10:49:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ov3Euc68XZkf for <spasm@ietfa.amsl.com>; Tue, 3 May 2022 10:49:07 -0700 (PDT)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0DAC159824 for <spasm@ietf.org>; Tue, 3 May 2022 10:49:07 -0700 (PDT)
Received: by mail-qk1-x730.google.com with SMTP id z126so14351514qkb.2 for <spasm@ietf.org>; Tue, 03 May 2022 10:49:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=czipJZbytB1Fm6NR1yUyyAoJ2B/L/OzqdxE6r3Ek4dc=; b=nX7du6L8rtc1KVIXVPPBft/5jFzilO/C5T3WURcY+nEyzXwZy5nH3PNoIenittIhBv 7IQz+7NjRIibM+pgrYxxwZ1zgx4DEoMxqGuJN2A5AuzqSNcqKXzuOw4YVyfhnyv+VdnB eXwtEUMNLe27595WKxxveR1Nw3qb9GV8nqWQk88KuviSu8r22VrsmVZQvrJryk6i5ltq MBHDeME8pKl5bLVjB97nzCA16t0Lr7P+aUciuWLkFMaRKAO9gS+Nkw4KknFrPPiBUov7 tLg7fCdhB8TG8wxIjknc0YITeabFbjZWs2AES8F/f5wtlqF7M6LPpqUIaaKpCnv8CL4T ps9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=czipJZbytB1Fm6NR1yUyyAoJ2B/L/OzqdxE6r3Ek4dc=; b=3A4YEVxgAlRymT9VmvaMx5p311vG1fKoKethGikPWTY2T/xyuZ2QraQaVXrcWrPjuF 4EoW0Trd3qInGwd590a6Pk2vgwwXadfAAnjQYGGzzJD38YG6MuNQhkPj4W17jrHtF0Uv ttjpPNPzcAKzU4nBhGHrRGgi2DLnr6eeCJ8TqqawlJPDRjwmWSlz27Bm/jrE13kIQujh h3S9gvudVQiIiASJpKFiZLpT6ZtKO07oGtkOJxXp07RPVonqPTI6fubrNeorWSn9s6gb uiq25rPUNxa5KDf8TWz1CLY/m+8SGlz6FEusQvFxzphxggF0ejaXp7O7BvE611keU8Qc oDEA==
X-Gm-Message-State: AOAM531i53wbIKzZkf5ahOBkdK2gdXZgatUn+LwxP58GjXkeIjyfHKsZ jSafF3rULv0Q3O/oN/kPFItb5BS1fOHMKA==
X-Google-Smtp-Source: ABdhPJy4nFIC+uvE+5FJYHS7MQTVPr/c371tJrP4ZQUQzB4j/ZAuY1CKDW4asPMrSAEQznYIQWpUjw==
X-Received: by 2002:a05:620a:2988:b0:69c:712c:6230 with SMTP id r8-20020a05620a298800b0069c712c6230mr13363154qkp.278.1651600145994; Tue, 03 May 2022 10:49:05 -0700 (PDT)
Received: from SantoshBrain (pool-96-255-230-78.washdc.fios.verizon.net. [96.255.230.78]) by smtp.gmail.com with ESMTPSA id t28-20020a05620a005c00b0069fc13ce20asm6090420qkt.59.2022.05.03.10.49.04 for <spasm@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 May 2022 10:49:05 -0700 (PDT)
From: Santosh Chokhani <santosh.chokhani@gmail.com>
To: 'LAMPS' <spasm@ietf.org>
References: <f2fb2b2459fe42818348838eb14cc2ac@EX13D01ANC003.ant.amazon.com> <1312273.1650733310@dooku> <ca18a6bf6cb74756ac942fb514c82d78@d-trust.net> <F24836DA-1304-4379-B91D-BBB4F012A888@vigilsec.com> <6cff3100963349cb8399bbe853e2186f@EX13D01ANC003.ant.amazon.com> <14588.1651247617@localhost> <CH0PR11MB5739E392E0DB4347B9F0ED6A9FFE9@CH0PR11MB5739.namprd11.prod.outlook.com>
In-Reply-To: <CH0PR11MB5739E392E0DB4347B9F0ED6A9FFE9@CH0PR11MB5739.namprd11.prod.outlook.com>
Date: Tue, 03 May 2022 13:49:03 -0400
Message-ID: <071301d85f16$1481a6b0$3d84f410$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQMuRBb3498nUlRS8F9HsF3VDOunhAHKqhN5AaxtS/gCNsoCgwHU9uELAmbTtwoCfuGnian+W2QQ
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/ihAa0tTqZ2NVQX4GpYX74UJjs7g>
Subject: Re: [lamps] [EXTERNAL] Re: PQ-composite OR or K-of-N logic
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.34
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: Tue, 03 May 2022 17:49:09 -0000

Thanks Mike.

After looking at the encryption draft and reflecting on your questions, for encryption also, which keys to use and what encryption algorithms to use should be relying party decision.  And that is the creator of encrypted payload and not the holder of the private key(s).

Payload may need to identify which algorithms/keys were used, but that is not in certificates.

-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Mike Ounsworth
Sent: Sunday, May 1, 2022 1:27 PM
To: Michael Richardson <mcr+ietf@sandelman.ca>; Kampanakis, Panos <kpanos=40amazon.com@dmarc.ietf.org>; Russ Housley <housley@vigilsec.com>; "Klaußner, Jan" <Jan.Klaussner@d-trust.net>; LAMPS <spasm@ietf.org>
Subject: Re: [lamps] [EXTERNAL] Re: PQ-composite OR or K-of-N logic

Hi Panos and Michael,

Putting on my Editor hat -- just trying to see if I've understood this discussion correctly.

"Subset signatures" := when the signer uses only some of their component keys, and emits a "null signature" in place of the others.

This has been in the draft since draft-ounsworth-pq-composite-sigs-05 (July 2021). Currently this is " 3.4.1.  Composite-OR Legacy Mode" in sigs-06. This is the source of a lot of complexity and confusion in design discussions (for both composite signatures and composite content encryption).

Other than some handwaving about saving bandwidth, I don't think I've heard anyone say that this is actually useful, so I think at this point we can remove it from the draft and leave only signature and encryption modes where the signer / encryptor use all available keys.

Currently, draft-ounsworth-pq-composite-encryption-01 sections 2.2.1, 3.2.1, and 4.2.1 define Composite-OR as a subset algorithm, so we would need to change it there too.


"OR mode" := When listed in a public key / signature algorithm (draft-ounsworth-pq-composite-sigs-06 sections 3.2 and 3.3) it means that the verifier is allowed to pick its favourite signature from those provided and ignore the rest. When listed in a public key / encryption algorithm, it means ... what? that the CEK has been encrypted independently for each component key? (seems a bit redundant when used inside CMS)

QUESTION: Is there value in defining OIDs to specify OR mode in A) a public key, B) a signature algorithm, C) an encryption algorithm?



"K of N mode" := When listed in a public key / signature algorithm, it means that the verifier is allowed to pick its favourite k signatures from those provided and ignore the rest. When listed in a public key / encryption algorithm, it means ... what? that the CEK was encrypted under some sort of secret sharing scheme?

It seems like this IS NOT valuable for public key / signature algorithms, and should be left up to verifier local policy.

QUESTION: is that valuable for public key / encryption algorithm?

---
Mike Ounsworth

-----Original Message-----
From: Spasm <spasm-bounces@ietf.org> On Behalf Of Michael Richardson
Sent: April 29, 2022 10:54 AM
To: Kampanakis, Panos <kpanos=40amazon.com@dmarc.ietf.org>; Russ Housley <housley@vigilsec.com>; =?utf-8?B?IktsYXXDn25lciwgSmFuIg==?= <Jan.Klaussner@d-trust.net>; LAMPS <spasm@ietf.org>
Subject: [EXTERNAL] Re: [lamps] PQ-composite OR or K-of-N logic

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________

Kampanakis, Panos <kpanos=40amazon.com@dmarc.ietf.org> wrote:
    > That does not need the signer to define the k-of-n logic. The signer
    > will just create n signatures and put them in a composite one. The
    > verifier will verify k-of-n and pass verification. No need for
    > upgrades. And no need for the AND, OR, K-OF-N logic to be added in the
    > composite signature or public key to complicate things.

I agree, the value of k is probably Verifier policy.
The signer could express a hint via a policy OID, but ultimately, it's the verifier that needs to implement something.


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm