[lamps] FW: [EXTERNAL] New Version Notification for draft-ounsworth-pq-composite-keys-03.txt

[Mike Ounsworth <[e-mail]>]

Hi LAMPS!

The main feedback about composite that we took away from LAMPS 114 is that the WG would like our composite draft to provide an actual list of composite algorithms, rather than hand-waving about generic containers and defining your own. While we very much do not feel like the authority here for mandating algorithm choices, we have attempted to choose a variety of combinations to fit different use cases, hopefully without going too far overboard on the number of combinations. See keys-03 changelog below.


*Question 1*: Is this the general direction that the WG is looking for from this draft?

*Question 2*: Feedback on our selection of combinations? – Note usage guidance on each explicit composite combination is provided in Section 4, and PEM samples in Appendix B. (yes, the document is now a walloping 66 pages, with the PEM samples being 34 of those pages (and we only put in half of the samples so far!!) -- don't blame composite, blame Dilithium, and the combinatorial explosion of alg pairs ).

*Question 3*: We have marked “generic composite” for prototyping; to be removed in final publication. Is this the will of the WG? At 114 we heard vocal support for removing it, but we want to give a change for people to voice support for leaving it in. Are there enduring (ie non-prototyping) usecases that benefit from generic composite?

If we receive positive feedback on this approach at 115, then we will complete the remaining TODOs in composite-keys-03, and will make the same changes to the corresponding composite-sigs and composite-kems drafts.


Changes in version -03

   *  Added the following explicit composite key types
      -  Explicit Composite Signature Keys
         o  id-Dilithium3-ECDSA-P256
         o  id-Dilithium3-RSA
         o  id-Falcon512-ECDSA-P256
         o  id-Falcon512-Ed25519
         o  id-SPHINCSXXX-ECDSA-P256
         o  id-Dilithium5-Falcon1024-ECDSA-P521
         o  id-Dilithium5-Falcon1024-RSA
      -  Explicit Composite KEM Keys
         o  id-Kyber512-RSA
         o  id-Kyber512-ECDH-P256
         o  id-Kyber512-x25519
   *  Added samples of (most of) the above explicit composites in
      appendices.
   *  Marked generic composite for prototyping; to be removed in final
      publication.
   *  Sycronized terminology with I-D.draft-driscoll-pqt-hybrid-
      terminology-01.
   *  Removed the section "Implementation Considerations > Asymmetric
      Key Packages (CMS)" since private key formats are now fully
      covered in the body and examples.


PS I can't wait to get to signature samples where a single PEM SPHICNS+ signature will be half the freaking document!

---
Mike Ounsworth
Software Security Architect, Entrust

-----Original Message-----
From: [e-mail] <[e-mail]>
Sent: October 22, 2022 10:04 AM
To: Jan Klaussner <[e-mail]>; Massimiliano Pala <[e-mail]>; Mike Ounsworth <[e-mail]>
Subject: [EXTERNAL] New Version Notification for draft-ounsworth-pq-composite-keys-03.txt

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________

A new version of I-D, draft-ounsworth-pq-composite-keys-03.txt
has been successfully submitted by Mike Ounsworth and posted to the IETF repository.

Name:           draft-ounsworth-pq-composite-keys
Revision:       03
Title:          Composite Public and Private Keys For Use In Internet PKI
Document date:  2022-10-22
Group:          Individual Submission
Pages:          66
URL:            https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ounsworth-pq-composite-keys-03.txt__;!!FJ-Y8qCqXTj2!dzHCwAGGM0LgPt_i2zPFQriI_OCRMdvJHmtbv07HVD1ubVXx6eccN_emkUwQ3ridYEmSmOlOwHs1Q4mkJwry-LqCh0ybFQ$
Status:         https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-keys/__;!!FJ-Y8qCqXTj2!dzHCwAGGM0LgPt_i2zPFQriI_OCRMdvJHmtbv07HVD1ubVXx6eccN_emkUwQ3ridYEmSmOlOwHs1Q4mkJwry-LrdGPWb-w$
Htmlized:       https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ounsworth-pq-composite-keys__;!!FJ-Y8qCqXTj2!dzHCwAGGM0LgPt_i2zPFQriI_OCRMdvJHmtbv07HVD1ubVXx6eccN_emkUwQ3ridYEmSmOlOwHs1Q4mkJwry-LrMH4dmLQ$
Diff:           https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ounsworth-pq-composite-keys-03__;!!FJ-Y8qCqXTj2!dzHCwAGGM0LgPt_i2zPFQriI_OCRMdvJHmtbv07HVD1ubVXx6eccN_emkUwQ3ridYEmSmOlOwHs1Q4mkJwry-Lqk-1lU-A$

Abstract:
   The migration to post-quantum cryptography is unique in the history
   of modern digital cryptography in that neither the old outgoing nor
   the new incoming algorithms are fully trusted to protect data for the
   required data lifetimes.  The outgoing algorithms, such as RSA and
   elliptic curve, may fall to quantum cryptalanysis, while the incoming
   post-quantum algorithms face uncertainty about both the underlying
   mathematics as well as hardware and software implementations that
   have not had sufficient maturing time to rule out classical
   cryptanalytic attacks and implementation bugs.

   Cautious implementors may wish to layer cryptographic algorithms such
   that an attacker would need to break all of them in order to
   compromise the data being protected using either a Post-Quantum /
   Traditional Hybrid, Post-Quantum / Post-Quantum Hybrid, or
   combinations thereof.  This document, and its companions, defines a
   specific instantiation of hybrid paradigm called "composite" where
   multiple cryptographic algorithms are combined to form a single key,
   signature, or key encapsulation mechanism (KEM) such that they can be
   treated as a single atomic object at the protocol level.

   This document defines the structures CompositePublicKey and
   CompositePrivateKey, which are sequences of the respective structure
   for each component algorithm.  The generic composite variant is
   defined which allows arbitrary combinations of key types to be placed
   in the CompositePublicKey and CompositePrivateKey structures without
   needing the combination to be pre-registered or pre-agreed.  The
   explicit variant is alxso defined which allows for a set of algorithm
   identifier OIDs to be registered together as an explicit composite
   algorithm and assigned an OID.

   This document is intended to be coupled with corresponding documents
   that define the structure and semantics of composite signatures and
   encryption, such as [I-D.ounsworth-pq-composite-sigs] and
   [I-D.ounsworth-pq-composite-kem].




The IETF Secretariat


Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.