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

"Klaußner, Jan" <Jan.Klaussner@d-trust.net> Wed, 27 April 2022 08:37 UTC

Return-Path: <prvs=109b1fd7c=Jan.Klaussner@d-trust.net>
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 3DB9AC075DEE for <spasm@ietfa.amsl.com>; Wed, 27 Apr 2022 01:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 OImQY22z73pt for <spasm@ietfa.amsl.com>; Wed, 27 Apr 2022 01:37:04 -0700 (PDT)
Received: from mail-out.d-trust.net (mail-out.d-trust.net [213.61.227.200]) (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 97C99C075DE1 for <spasm@ietf.org>; Wed, 27 Apr 2022 01:37:03 -0700 (PDT)
Received: from progov-n2.bln.d-trust.de (localhost [127.0.0.1]) by progov-n2.bln.d-trust.de (Postfix) with ESMTPS id 6C99020F50A for <spasm@ietf.org>; Wed, 27 Apr 2022 10:36:56 +0200 (CEST)
Received: from dtr-xc-bp02.d-trust.de (lb-107.bln.d-trust.de [192.168.107.250]) by progov-n2.bln.d-trust.de (Postfix) with ESMTPS id 6415020F509 for <spasm@ietf.org>; Wed, 27 Apr 2022 10:36:56 +0200 (CEST)
From: "Klaußner, Jan" <Jan.Klaussner@d-trust.net>
To: LAMPS <spasm@ietf.org>
Thread-Topic: [lamps] PQ-composite OR or K-of-N logic
Thread-Index: AdhV9Rf0dKtEp6K7TUGSt7lMX+2VvwBLfdcAAJLl7gA=
Date: Wed, 27 Apr 2022 08:36:55 +0000
Message-ID: <ca18a6bf6cb74756ac942fb514c82d78@d-trust.net>
References: <f2fb2b2459fe42818348838eb14cc2ac@EX13D01ANC003.ant.amazon.com> <1312273.1650733310@dooku>
In-Reply-To: <1312273.1650733310@dooku>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [172.16.171.67]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0127_01D85A22.B6ACDE80"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/nFeEZCMi0cj27Ayow_ft-qgY3BI>
Subject: Re: [lamps] 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: Wed, 27 Apr 2022 08:37:05 -0000

Hi all,

First I completely agree with Michaels view on verification policies.
Especially in open PKIs that are not under control of one company there is a
need to signal how verification should be done.

On the question about use cases beside the PQ transition: We believe there
is a high probability that new algorithms are successfully attacked during
the next decades. 

Therefore we want establish some agility in an PKI to more easily switch
algorithms without an immediate PKI rollover. In our case we are also
talking about use cases for document signing or long term encryption, where
digital signatures need to be valid for longer periods, sometimes up to 50
years.

So in case one algorithm is broken, the documents still remain secure/valid.
There would be an immediate need to reconfigure or update verifier/signing
software not to use this algorithm anymore, but there is some more time to
replace the algorithm in the PKI.
Once again, this is even more important in an open PKI.

The k-of-n mode here is providing this agility and also the increased
security of the AND mode, simply put.

I hope our point is now more clear to the group

Br
Jan
> -----Ursprüngliche Nachricht-----
> Von: Spasm <spasm-bounces@ietf.org> Im Auftrag von Michael Richardson
> Gesendet: Samstag, 23. April 2022 19:02
> An: LAMPS <spasm@ietf.org>
> Betreff: Re: [lamps] PQ-composite OR or K-of-N logic
> 
> 
> I read through the list and the slides.  I couldn't be at the meeting on
> Wednesday as I was travelling.
> 
> The document starts off with:
>  "Even after the migration period, it may be advantageous for an entity's
>   cryptographic identity to be composed of multiple public-key
algorithms."
> 
> Panos and a few others have complained that the document attempts to
> have signers tell verifiers what to do, and this should really a verifier
policy.
> Well, that would make a lot of sense for a CMS signature on your Mortgage,
> or your MUA verifying my email.
> 
> But, signers REGULARLY tell verifiers what they've done and how to verify
> things, and that's in the context of Certificates.  We have all these
policy
> OIDs, and CSPs, and Path Constraints, and ...  These are all signals from
the
> signer to the verifier.  The verifier can, of course, have a policy that
says that
> they ignore CSPs or Path Constraints, or...
> 
> I guess that the k-of-n part was in the slides only, as it's not in the
document
> that I could see.
> 
> I go back to the text I quoted above, and thinking about k-of-n.
> I'm thinking that if there are more uses for the Composite-Or and
> Composite-AND structures than *just* PQ transition, that the ROI on
> implementing them may be much higher.  And thus the likelyhood that we'll
> discovery and fix bugs relating to the new constructs is much higher.
> 
> I think that we can agree that the last thing we want is a widespread bug
in
> validation, at the point where we find it critical to transition.
> 
> ps: I giggled when I read ~~~ BEGIN EDNOTE 10~~~
> 
> 
> 
> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
>