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

Tadahiko Ito <tadahiko.ito.public@gmail.com> Wed, 04 May 2022 12:36 UTC

Return-Path: <tadahiko.ito.public@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 B4DB7C15948C for <spasm@ietfa.amsl.com>; Wed, 4 May 2022 05:36:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 YDNiKZ8Dm07h for <spasm@ietfa.amsl.com>; Wed, 4 May 2022 05:36:15 -0700 (PDT)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 A724FC157B5D for <spasm@ietf.org>; Wed, 4 May 2022 05:36:15 -0700 (PDT)
Received: by mail-il1-x133.google.com with SMTP id r17so757210iln.9 for <spasm@ietf.org>; Wed, 04 May 2022 05:36:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SOPujXKQolZoBR5U+pjpE23PXjIJzrdUudR5VND1DBE=; b=RWoMzo0Ard++p0WyXQb9H6VeUS5HUJYw44CDY8qz0aQH6YBx8Pv0JVwgius5zwLC+N qwGadKHWfrT+TlhI85wA0Tj0kEMha/5EojCsQ36i/ttfdyliEr9ma6LrbcpC8iXoTjsh PJ3vOoZEeUqdupF3CMVfYnm9+QRKrp57J23gnZ3lyZzRMVq4bjD0ye23xSpuFb60QGxy 6bpkgZDMKFarW4KD1Z6SdIHCTMKJewJ35xdm23X52qP7gxu21yMOexoSwc99Q9/JcWs6 foYgM4EwjAC6ZHG9M8a0DQ0cSRpr7VN9QVn3/capEiowyJQU7NFro2JEseh/0M50ZtUd K0Fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SOPujXKQolZoBR5U+pjpE23PXjIJzrdUudR5VND1DBE=; b=QLHatqcQSAF8u3sh4VsCsqtu16L6EYrFFPpyuckAI2w8RVoMJUds7o8CR9MlbnQdEl aNvSzUdoCLnMO8litoCtT+/k961eijEhf991cKB4RPS8g6ruGuFIPfhRiCfz8BGBA1ck B9BmaoE9jA2oBj+E3sqVPmPhpfZJx6HjTnpwYKMEGb+0sASOh5fFsh1lFevLNF2GFS4G G+twV/JAVSCVYqUsx66un6QeHB+BExiRCvjr0Bhf3IRcX+EMxT2xADjujtYUzjMARa3l 70SEs+p4bbgAmibxsTNGV05aJ2hWj5qRZUqBKsriyTD/Nv/ou3dY2cjsAOKx6FNkxqif gObg==
X-Gm-Message-State: AOAM5333VGLpse1hHn/v7rrWCOYT7eaMwwB/qpZwxifVgUeGneZs3ykA A6yAMSFn2rrgKBFgf8CjJzxooAslLI/88paFrBE=
X-Google-Smtp-Source: ABdhPJzQG/0DqkTBGDQF1QZpkfsADlt23PmbX6FolzpAv5/JADB44k4qCrp/fWwa4yQ4zcV7UZznnzVcPBTQnEvNHvA=
X-Received: by 2002:a05:6e02:1a86:b0:2cf:5846:29b3 with SMTP id k6-20020a056e021a8600b002cf584629b3mr304653ilv.232.1651667774693; Wed, 04 May 2022 05:36:14 -0700 (PDT)
MIME-Version: 1.0
References: <f2fb2b2459fe42818348838eb14cc2ac@EX13D01ANC003.ant.amazon.com> <1312273.1650733310@dooku> <ca18a6bf6cb74756ac942fb514c82d78@d-trust.net> <F24836DA-1304-4379-B91D-BBB4F012A888@vigilsec.com> <1f7f7bfdacbc4185a30a9232851a954c@d-trust.net>
In-Reply-To: <1f7f7bfdacbc4185a30a9232851a954c@d-trust.net>
From: Tadahiko Ito <tadahiko.ito.public@gmail.com>
Date: Wed, 04 May 2022 21:36:03 +0900
Message-ID: <CAFTXyYDinUEZqc8xrVj7S7MRqRWdzh=au2aY6b=7+LWzFbWW3A@mail.gmail.com>
To: "Klaußner, Jan" <Jan.Klaussner@d-trust.net>
Cc: LAMPS <spasm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ff687005de2edeeb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/krUl-_Foz16iqt5sLXBtzrTCJsE>
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, 04 May 2022 12:36:16 -0000

Hi Jan

> In reality that's mostly the case when something is very valuable or
important
> so you want an additional neutral witness and safe repository.

I believe, some companies or CAs extend protection period of data longer
than their certificates validity period with notary services.
At least our company does, and In our case, It is because of the
Certificate for document signing or timestamping has shorter validity
period compare with required lifetime of data

Your known environment prohibit extension of protection period by using
other mechanism (e.g. notary service), even that service is run by same
company as issuing authority?
If it were not case, notary service might be worth to consider.

> But as it comes not for free, I do not see how this could help for e.g.
signatures you give in your normal life,
> e.g. to sign contracts, tax declaration etc.

your suggestion sound like, try to implement single certificates, which can
be secure for long period.
In the reality, building mechanism which is secure for 50years should be
very costly,
much more than building 5 mechanisms secure for 10 years (I am ignoring
switching period, but it does not change conclusion).
It means,  even if CA provide notary service by themselves, notary approach
can be cost effective than providing very long validity period certificates
(It may be related to how strictly mechanism deal with uncertainty etc.).

your claim might be true for some environment, but It does not sound quite
general environment for me.

Regards Tadahiko

2022年5月4日(水) 20:18 Klaußner, Jan <Jan.Klaussner@d-trust.net>:

> Russ:
>
> Yes, a notary can be used. In reality that's mostly the case when
> something is very valuable or important so you want an additional neutral
> witness and safe repository. But as it comes not for free, I do not see how
> this could help for e.g. signatures you give in your normal life, e.g. to
> sign contracts, tax declaration etc. They also are legally valid for
> lifetime, so I think we need to have other mechanism to solve algorithm
> obsolescence.
>
> > -----Ursprüngliche Nachricht-----
> > Von: Russ Housley <housley@vigilsec.com>
> > Gesendet: Mittwoch, 27. April 2022 15:44
> > An: Klaußner, Jan <Jan.Klaussner@d-trust.net>
> > Cc: LAMPS <spasm@ietf.org>
> > Betreff: Re: [lamps] PQ-composite OR or K-of-N logic
> >
> > Jan:
> >
> > A notary is often used when a signature needs to be verifiable for many
> > decades. RFC 4998 specifies the Evidence Record Syntax (ERS), which can
> be
> > used to apply additional signatures by a notary.
> >
> > Russ
> >
> > > On Apr 27, 2022, at 4:36 AM, Klaußner, Jan <Jan.Klaussner@d-trust.net>
> > wrote:
> > >
> > > 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 =-
> > >>
> > >>
> > >
> > > _______________________________________________
> > > Spasm mailing list
> > > Spasm@ietf.org
> > > https://www.ietf.org/mailman/listinfo/spasm
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>