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

Something like the related DSSC spec (https://datatracker.ietf.org/doc/html/rfc5698) could be useful in this scenario.

On 4/27/22, 9:43 AM, "Spasm on behalf of Russ Housley" <spasm-bounces@ietf.org on behalf of housley@vigilsec.com> wrote:

    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