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

You seem to be confusing the certificate policy and the signature policy.  Please see RFC 3125 and RFC 3126 for a discussion and specification of signature policy in the context of a CMS signature.

Russ

On Wed, May 4, 2022 at 5:37 AM Klaußner, Jan <Jan.Klaussner@d-trust.net <mailto:Jan.Klaussner@d-trust.net>> wrote:
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 <mailto:kpanos@amazon.com>>
> Gesendet: Mittwoch, 27. April 2022 16:13
> An: Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>>; Klaußner, Jan <Jan.Klaussner@d-
> trust.net <http://trust.net/>>
> Cc: LAMPS <spasm@ietf.org <mailto: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 <mailto: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 <mailto:Jan.Klaussner@d-trust.net>>
> Cc: LAMPS <spasm@ietf.org <mailto: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 <mailto: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 <mailto:spasm-bounces@ietf.org>> Im Auftrag von Michael
> Richardson
> >> Gesendet: Samstag, 23. April 2022 19:02
> >> An: LAMPS <spasm@ietf.org <mailto: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 <mailto:mcr%2BIETF@sandelman.ca>>, Sandelman Software
> Works
> >> -= IPv6 IoT consulting =-
> >>
> >>
> >
> > _______________________________________________
> > Spasm mailing list
> > Spasm@ietf.org <mailto:Spasm@ietf.org>
> > https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>

_______________________________________________
Spasm mailing list
Spasm@ietf.org <mailto:Spasm@ietf.org>
https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>

-- 
Mike Jenkins
mjjenki@cyber.nsa.gov <mailto:mjjenki@tycho.ncsc.mil> 
443-598-7837
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm