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

[Tadahiko Ito <[e-mail]>]

I might fail to trace discussion, and it might be outside the scope of this
I-D, but this composite certificate is assuming

“composite root - composite ICA – composite EE” structure?



I was thinking

“composite root - composite ICA – traditional EE” structure may help
migration (to switch EE cert from a non-composite traditional algorithm to
a non-composite PQC algorithm), or to support multi purposes root (we might
use different PQC algorithms for different purposes, and root which support
different purpose might support multiple PQC algorithms) with OR mode.
Revocation checking of such a use cases in same time would be even
complexed.



If you have any comment, I would love to hear that.



Regards Tadahiko

2022年10月25日(火) 11:42 Kampanakis, Panos <kpanos=[e-mail]>:

> Hi Mike,
>
> > *Question 2*
>
> I don’t think picking all possible combinations of algorithms is a good
> idea. I suggest to include Dilithium+ECDSA. The Dilithium and ECDSA
> parameters should be of equivalent security level. Similarly for Kyber+ECDH
> and Kyber+X25519.
>
> I think SPHINCS+ usecases will be most in sw/firmware signing or CMS which
> already allow including multiple signer infos and signatures, so I would
> argue we don’t need SPHINCS+ combinations.
>
> For Falcon combinations I am not sure there are many usecases that can
> generally assume FPUs are available, so I would shy against it for now.
>
>
>
> -----Original Message-----
> From: Spasm <[e-mail]> On Behalf Of Mike Ounsworth
> Sent: Saturday, October 22, 2022 11:20 AM
> To: 'LAMPS' <[e-mail]>
> Subject: [lamps] FW: [EXTERNAL] New Version Notification for
> draft-ounsworth-pq-composite-keys-03.txt
>
> 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.
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>