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

Hi Jan, 

> in the non-repudiation or content commitment use case the signer must hint how the verification should be done in order to be held accountable.

For my benefit, how does that work? 
The signer sings with n private keys. Are you saying that only when the verifier can verify k of these signatures, can the verifier be certain that the signer signed the object? 
Why will 1-of-n (for a trusted by the verifier signature algorithm) suffice for these scenarios?

-----Original Message-----
From: Spasm <spasm-bounces@ietf.org> On Behalf Of Klaußner, Jan
Sent: Wednesday, May 4, 2022 5:37 AM
To: LAMPS <spasm@ietf.org>
Subject: RE: [EXTERNAL][lamps] PQ-composite OR or K-of-N logic

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

Hi Panos,

as I stated in another post in this thread, in the non-repudiation or content commitment use case the signer must hint how the verification should be done in order to be held accountable.

> -----Ursprüngliche Nachricht-----
> Von: Kampanakis, Panos <kpanos@amazon.com>
> Gesendet: Mittwoch, 27. April 2022 16:13
> An: Russ Housley <housley@vigilsec.com>; Klaußner, Jan 
> <Jan.Klaussner@d- trust.net>
> Cc: LAMPS <spasm@ietf.org>
> Betreff: RE: [lamps] PQ-composite OR or K-of-N logic
>
> +1 to Russ' point about RFC4998.
>
> And to reiterate:
>
> > 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.
> > The k-of-n mode here is providing this agility and also the 
> > increased
> security of the AND mode, simply put.
>
> 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.
>
>
>
> -----Original Message-----
> From: Spasm <spasm-bounces@ietf.org> On Behalf Of Russ Housley
> Sent: Wednesday, April 27, 2022 9:44 AM
> To: "Klaußner, Jan" <Jan.Klaussner@d-trust.net>
> Cc: LAMPS <spasm@ietf.org>
> Subject: RE: [EXTERNAL][lamps] PQ-composite OR or K-of-N logic
>
> CAUTION: This email originated from outside of the organization. Do 
> not click links or open attachments unless you can confirm the sender 
> and know the content is safe.
>
>
>
> 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