Skip to main content

Post-quantum cryptography migration use cases
draft-vaira-pquip-pqc-use-cases-02

Document Type Active Internet-Draft (individual)
Authors Antonio Vaira , Hendrik Brockhaus , Alexander Railean , John Gray , Mike Ounsworth
Last updated 2024-07-08
RFC stream (None)
Intended RFC status (None)
Formats
Additional resources GitHub Repository
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-vaira-pquip-pqc-use-cases-02
Post-Quantum Use In Protocols                                   A. Vaira
Internet-Draft                                              H. Brockhaus
Intended status: Informational                                A. Railean
Expires: 9 January 2025                                          Siemens
                                                                 J. Gray
                                                            M. Ounsworth
                                                                 Entrust
                                                             8 July 2024

             Post-quantum cryptography migration use cases
                   draft-vaira-pquip-pqc-use-cases-02

Abstract

   This document is meant to be continuously updated, to incorporate
   emerging Post-Quantum Cryptography (PQC) migration use cases, with a
   focus on the migration from traditional signature algorithms (e.g.,
   RSA, DSA, ECDSA) to PQC signature algorithms (e.g., LMS, XMSS, ML-
   DSA, SLH-DSA).  This document aims at categorizing real-world
   scenarios based on a set of distinctive features.  The primary goal
   is to facilitate discussions on migration strategies by offering a
   systematic taxonomy and a shared understanding among stakeholders.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://avaira77.github.io/pq-ietf-usecase/draft-vaira-pquip-pq-use-
   cases.html.  Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-vaira-pquip-pqc-use-cases/.

   Discussion of this document takes place on the Post-Quantum Use In
   Protocols Working Group mailing list (mailto:pqc@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/pqc/.  Subscribe
   at https://www.ietf.org/mailman/listinfo/pqc/.

   Source for this draft and an issue tracker can be found at
   https://github.com/avaira77/pq-ietf-usecase.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

Vaira, et al.            Expires 9 January 2025                 [Page 1]
Internet-Draft                PQC use cases                    July 2024

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 9 January 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Reference Use Cases . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Industrial communication protocols  . . . . . . . . . . .   4
     2.2.  Software and Firmware update  . . . . . . . . . . . . . .   5
     2.3.  Trust Anchor deployment . . . . . . . . . . . . . . . . .   6
     2.4.  CMS (S/MIME)  . . . . . . . . . . . . . . . . . . . . . .   7
     2.5.  Timestamping  . . . . . . . . . . . . . . . . . . . . . .   8
     2.6.  Additional use cases  . . . . . . . . . . . . . . . . . .   9
   3.  Post-quantum Migration Strategies for Signing . . . . . . . .   9
     3.1.  Multiple Signatures . . . . . . . . . . . . . . . . . . .   9
     3.2.  Composite Signatures  . . . . . . . . . . . . . . . . . .   9
     3.3.  Employing Stateful Hash-based Signature Schemes . . . . .  10
     3.4.  Employing Stateless Hash-based Signature Schemes  . . . .  10
     3.5.  Employing Module-Lattice-Based Digital Signature
           Schemes . . . . . . . . . . . . . . . . . . . . . . . . .  11
     3.6.  Cryptographic Agility . . . . . . . . . . . . . . . . . .  11
   4.  Map of Migration Strategies to Reference Use Cases  . . . . .  12
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13

Vaira, et al.            Expires 9 January 2025                 [Page 2]
Internet-Draft                PQC use cases                    July 2024

   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Appendix A.  Post-Quantum Migration Properties  . . . . . . . . .  18
     A.1.  Lifetime  . . . . . . . . . . . . . . . . . . . . . . . .  18
     A.2.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . .  18
     A.3.  Backward compatibility  . . . . . . . . . . . . . . . . .  19
   Appendix B.  Composite Signature individual and organization
           position statements . . . . . . . . . . . . . . . . . . .  19
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   How to transition to post-quantum cryptography is a question likely
   to stay with us for a considerable period.  Within several working
   groups at the IETF, a variety of strategies are under discussion,
   gradually finding their way into RFCs.  The existence of multiple
   choices makes it more difficult to select the most suitable approach
   for any given use case.

   For example, an Original Equipment Manufacturer (OEM) must issue its
   products today with manufacturer X.509 certificates that might be
   used at any time during their lifespan.  These certificates will
   eventually be utilized to enroll in a domain PKI (Public Key
   Infrastructure), therefore the choice of algorithms is critical.

   In this document, intended to be a dynamic resource, our main
   objective is to compile a list of digital signature use cases and
   categorize them based on prominent features.  Examples include
   distinguishing between long-lived and short-lived scenarios, whether
   they include a negotiated protocol, or if backward compatibility is
   required.

   We also explore the migration strategies that have appeared so far,
   proposing the most suitable fit for each of the properties identified
   in each use case.  Some of these migration strategies make use of
   hybrid cryptography, i.e., use both traditional and post-quantum
   cryptography.

   The consideration of hybrid cryptography is motivated by: (1) the
   need of having long-lived assertions, i.e., digital signatures that
   require long term validation, (2) the uncertainty surrounding the
   longevity of traditional cryptographic methods, (3) the lack of
   complete trust in emerging PQC algorithms, and (4) the time pressure
   to launch a product soon.

Vaira, et al.            Expires 9 January 2025                 [Page 3]
Internet-Draft                PQC use cases                    July 2024

   An additional factor to consider is rooted in the requirements from
   regulatory bodies, which, in several cases will differ in regard to
   post-quantum algorithms and acceptable migration strategies.  For
   example [bsi.quantum-safe.crypto], recommends the incorporation of
   post-quantum cryptographic algorithms within hybrid cryptographic
   schemes, as a proactive response to the quantum threat.  On the
   contrary, [CNSA2-0] recommends specific post-quantum cryptographic
   algorithms for each use case.

   The use of hybrids potentially comes at the cost of increased
   complexity, or that of an implied second migration that must occur
   when a component algorithm becomes obsolete.  These arguments need to
   be taken into account when considering hybrids.  A key advantage of
   hybrids is that they accommodate a bias for action, enabling an
   organization to act now (e.g., to avoid piling up of inventory, to
   meet contractual commitments, gain first-mover advantage, etc.), and
   apply course corrections later.  Note that hybrids defer the problem
   to a future date, without eliminating the need to address it
   altogether.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Reference Use Cases

   This section is the core of this document.  For each use case, we
   present a concise overview and highlight the features that can help
   to categorize it.  This list is not exhaustive, and if you think we
   have missed some important use case please consider contributing to
   it.

2.1.  Industrial communication protocols

   Several industrial communication protocols, traditionally do not use
   IP network infrastructure, are progressively being updated to make
   use of standard IP network infrastructure hence rely on standard
   security mechanisms, like for example TLS 1.3 [RFC8446].

   The protocol 'Building Automation and Control Networks / Secure
   Connect' (BACnet/SC) [ANSI_ASHRAE.Standard.135-2016] is a good
   example.  BACnet was defined before 1995, when the TCP/IP protocol
   suite was expensive and not available for smaller devices common in
   building automation.  BACnet/SC proposes a new datalink layer option

Vaira, et al.            Expires 9 January 2025                 [Page 4]
Internet-Draft                PQC use cases                    July 2024

   that makes full use of TLS secured WebSocket connections.  This new
   BACnet/SC datalink layer option uses a virtual hub-and-spoke topology
   where the spokes are WebSocket connections from the nodes to the hub.

   BACnet/SC's implementation adheres to established industry standards
   defined in IETF RFCs.  Specifically the
   [Addendum.bj.to.ANSI_ASHRAE.Standard.135-2016] references to text
   encoding of PKIX, PKCS, and CMS structures in [RFC7468], when
   defining the format in which operational certificates and signing CA
   should be installed onto the target device at configuration time.

   The security of the BACnet/SC protocol, as well as of similar
   industrial protocols, relies on TLS 1.3 [RFC8446], therefore
   implications of post-quantum cryptography have to be considered in
   both the TLS handshake and in the X.509 certificates used for the
   authentication.

   Lifetime: Long-lived.

   Protocol: Active Negotiation.

   Backward compatibility: Limited.

2.2.  Software and Firmware update

   Secure firmware updates are crucial for ensuring long-term security
   of the device, especially in industrial, and critical infrastructure
   fields, where devices can stay active for decades.  Such updates
   encompass tasks like introducing new trust anchors and upgrading
   cryptographic algorithm capabilities.  However, upgrading every
   device's security capabilities isn't always feasible due to resource,
   accessibility, and cost constraints.  Some devices may not support
   secure firmware updates at all.

   Firmware updates are typically authenticated by the Original
   Equipment Manufacturer (OEM) by means of a digital signing process.
   An update is distributed to target devices, which will validate its
   signature against a Trust Anchor (TA).  The TA can be an X.509
   certificate, a public key, or a hash of a combination of both,
   depending on the OEM's security measures.

Vaira, et al.            Expires 9 January 2025                 [Page 5]
Internet-Draft                PQC use cases                    July 2024

   These devices are typically deployed in highly regulated
   environments, in remote or physically constrained locations where
   performing upgrades is challenging, or in cases where the cost of
   upgrading is prohibitively high.  The immutability of these devices
   can also be viewed as a security feature, as it restricts potential
   attack vectors associated with over-the-air updates.  These devices
   are designed with a long operational lifetime in mind, often spanning
   several decades.  Notable examples of such devices encompass:

   *  Vehicles - scale of deployment or vehicle recall difficulties.

   *  Satellites - no 'on-site' service reasonably possible.

   *  Servers and network devices - air-gapped, locked-down DCs,
      geographically distributed.

   *  Government infrastructure - power grids, nuclear power station
      equipment, etc.

   *  Smart meters - device owned by the utility company, deployed in
      private homes.

   *  Smart cards – used for authenticating to workstations and
      buildings, or electronic document signing.

   *  Security Tokens – such as FIDO2, cheap devices that users will
      typically not patch.

   Lifetime: Long-lived.

   Protocol: Passive Negotiation.

   Backward compatibility: Limited.

2.3.  Trust Anchor deployment

   Trust Anchors, such as X.509 Root CA certificates and raw public
   keys, must be made accessible before they can be used for signature
   validation.  In scenarios like remote software updates, a Trust
   Anchor X.509 certificate, for instance, must be installed on a target
   device to enable the validation of certificate chains.  While
   deployment of Trust Anchors may be relatively straightforward for
   "corporate IT" and "public web" applications, it can still be a time-
   consuming process to ensure that a new Trust Anchor X.509 certificate
   is propagated throughout the entire ecosystem.  Additionally, when
   dealing with post-quantum Trust Anchors, an extra layer of complexity
   arises as the desired underlying cryptography may not yet be
   supported by the target platform.

Vaira, et al.            Expires 9 January 2025                 [Page 6]
Internet-Draft                PQC use cases                    July 2024

   There are two common variations of this use case.

   *  Injection within a factory: in industrial contexts, Trust Anchors
      are typically injected into target devices during the
      manufacturing phase.  To bootstrap a Trust Anchor, the device is
      placed in a physically secure environment accessible only to
      trusted personnel.  This injection can occur during manufacturing
      or when a device is being resold.  It is important to note that
      some devices might not support updating the Trust Anchor in the
      field, requiring the return of the device to the OEM for post-
      quantum Trust Anchor injection or, in some cases, it may be even
      not supported at all, because, for example, the Trust Anchor is
      burnt onto the device at manufacturing time.

   *  Injection via software and firmware updates: for devices where the
      Trust Anchor is not burned onto the device, for example in less
      constrained devices and IT equipment, post-quantum Trust Anchors
      can be injected through software or firmware update mechanisms.
      The deployment of these Trust Anchors may leverage existing update
      mechanisms and traditional cryptography to minimize effort.
      However, this approach necessitates the distribution of the new
      Trust Anchors well in advance of any suspicion that traditional
      cryptography may become vulnerable.  Given the lead time required
      to ensure widespread distribution, the time window where this
      mechanism is suitable is further reduced.

   Lifetime: Long-lived.

   Protocol: Passive Negotiation.

   Backward compatibility: Limited.

2.4.  CMS (S/MIME)

   The Cryptographic Message Syntax (CMS) [RFC5652] establishes a
   standard syntax for creating secure messages, incorporating digital
   signatures, encryption, and authentication codes.  In practical
   terms, CMS finds application in scenarios such as secure email
   communication, document signing, and PKI-based security services.
   Organizations use CMS for secure file transfers and end-to-end
   encryption of documents, ensuring confidentiality and integrity.  It
   is a key component in secure messaging protocols, contributing to the
   confidentiality, integrity, and authenticity of communication over
   networks.  One of the notable features of CMS is flexibility,
   allowing the choice of cryptographic algorithms based on specific
   security requirements.  An important consideration to be made is the
   non-uniform adoption and potential challenges in implementing CMS,
   particularly in the context of email clients.  Varying levels of

Vaira, et al.            Expires 9 January 2025                 [Page 7]
Internet-Draft                PQC use cases                    July 2024

   maturity and maintenance among email clients will slow down the
   adoption of post-quantum algorithms, which will not be uniform across
   different clients.

   It is worth noting that, similarly to CMS, JOSE and (JSON Object
   Signing and Encryption) and COSE (CBOR Object Signing and Encryption)
   are data structures used to support signing and encryption of data,
   respectively, in JSON and CBOR format.  Therefore, several
   considerations that are applicable for CMS will extend to JOSE and
   COSE as well.

   Lifetime: Short-lived and long-lived.

   Protocol: Passive Negotiation.

   Backward compatibility: Mandatory.

2.5.  Timestamping

   A time-stamping service supports assertions of proof that a datum
   existed before a particular time, as defined in [RFC3161].
   Timestamps, are particularly important in the following scenarios.

   *  Code and Document Signing: In code and document signing use cases,
      timestamps play a critical role in ensuring the ongoing validity
      of digital signatures.  It is not sufficient to validate the
      signature at the time of creation; it must be verifiable even
      after the signature certificate has expired.  This is particularly
      important for long-term archival and verification purposes, where
      the historical integrity of the signed code or document needs to
      be maintained over time.  The timestamp is stored in a CMS data
      structure, cf. Section 2.4.

   *  Non-repudiation: timestamps enhance non-repudiation by preventing
      parties from later denying the authenticity or validity of their
      digital signatures.  Non-repudiation plays a major role in Legal
      and regulatory compliance, Intellectual property protection and
      Electronic commerce, where the reliability of timestamps is key
      for establishing clear timelines with legal and financial
      implications.

   Lifetime: Long-lived.

   Protocol: Passive Negotiation.

   Backward compatibility: Optional.

Vaira, et al.            Expires 9 January 2025                 [Page 8]
Internet-Draft                PQC use cases                    July 2024

2.6.  Additional use cases

   Future updates of this document may include use cases which cover
   additional aspects, such as FAA airworthiness certifications, medical
   records, etc.

3.  Post-quantum Migration Strategies for Signing

   People are considering which technological concepts are suitable to
   solve the problem of a secure migration from classical cryptography
   to quantum computer safe cryptographic algorithms.  A variety of
   approaches are being discussed.  In the following, we would like to
   briefly introduce the approaches under discussion and refer to the
   respective relevant documents for further details.  For a general
   introduction, we also refer to [I-D.ietf-pquip-pqc-engineers].

3.1.  Multiple Signatures

   Several signatures have the approach of defining a second alternative
   signature in addition to the primary signature in the protocol or
   format, which can be transported in the protocol or format.  In
   addition to the definition of the alternative signature, the
   associated signing algorithm and, if applicable, the associated
   public key or a reference to it must also be transferred.  For X.509
   public key certificates, this is defined in [X.509].  Work is also
   underway for other protocols and formats.  This approach overlaps
   with the protocol and format extension approach described in
   Section 3.6.

   An alternative approach is to encode a second signature in a second
   certificate and bind it to the first one by a reference.  For
   example, an implementation can decide based on its policy whether
   only the first certificate or the second or both certificates should
   be used for authentication.  Further descriptions of this approach
   can be found in A Mechanism for Encoding Differences in Paired
   Certificates [I-D.bonnell-lamps-chameleon-certs] and Related
   Certificates for Use in Multiple Authentications within a Protocol
   [I-D.ietf-lamps-cert-binding-for-multi-auth].

3.2.  Composite Signatures

   The goal of composite signatures is to define a signature object to
   be used with any protocol or format.  It contains two signatures in a
   single atomic container that have been generated using two different
   cryptographic algorithms.  The goal of this approach is to define a
   signature format which requires both contained signatures to be
   verified.  In this way, the security properties of the classical
   signature and another signature that is secure when attacked by a

Vaira, et al.            Expires 9 January 2025                 [Page 9]
Internet-Draft                PQC use cases                    July 2024

   quantum computer are used in the protocol or format without having to
   adapt them.

   In order for this approach to be applicable in arbitrary protocols
   and formats, a composite key must be defined in addition to the
   composite signature.  According to the definition of composite
   signatures, a composite public is a single atomic container composed
   of two public keys.  The associated composite private key is a single
   atomic private key that is composed of the two private keys which
   correspond to the two public keys contained in the composite public
   key.

   This concept is described in Composite Signatures For Use In Internet
   PKI [I-D.draft-ietf-lamps-pq-composite-sigs] in more detail.

3.3.  Employing Stateful Hash-based Signature Schemes

   Stateful hash-based signature (HBS) schemes, such as XMSS [RFC8391]
   and LMS [RFC8554], including their multi-tree variants, have been the
   first post-quantum algorithms to be standardized by NIST in
   [NIST.SP.800-208].  Stateful HBS algorithms offer better key and
   signature sizes than stateless HBS algorithms, and the underlying
   cryptographic building blocks are generally considered well-
   understood.  However, a critical consideration is the management of
   state, which is a fundamental aspect of security.  The absence of
   standardized operating procedures for state management poses
   challenges to the adoption of stateful HBS.  This is especially
   critical when signing data over extended periods using the same key
   pair; i.e., the resulting signatures will be validated with the same
   public key over a long period of time.  Another aspect worth
   considering is that, without solutions for hardware security module
   replacements and disaster recovery scenarios, using stateful HBS
   might lead to a solution with limited resilience.

3.4.  Employing Stateless Hash-based Signature Schemes

   [NIST.FIPS.205] specifies the SLH-DSA (SPHINCS+) algorithm.  It is a
   stateless hash-based signature algorithm and is considered safe
   against attacks by quantum computers.  The advantage of this
   algorithm is that the state problem is resolved as part of the
   algorithm.  However, the tradeoff is that signature sizes are often
   an order of magnitude larger than XMSS or LMS.  This may make
   deploying these algorithms on constrained devices infeasible.

Vaira, et al.            Expires 9 January 2025                [Page 10]
Internet-Draft                PQC use cases                    July 2024

3.5.  Employing Module-Lattice-Based Digital Signature Schemes

   [NIST.FIPS.204] specifies the ML-DSA (Dilithium) algorithm, a digital
   signature algorithm based on the hardness of lattice problems over
   module lattices.  It serves as a general purpose post-quantum
   signature algorithm, offering smaller key sizes in comparison to SLH-
   DSA and fast signature generation.  For more details, refer to
   [I-D.ietf-pquip-pqc-engineers].

3.6.  Cryptographic Agility

   Migration to post-quantum cryptographic algorithms can be regarded as
   an instance of the general pattern of _cryptographic agility_, rather
   than be viewed as a special, one-off event.  A system that approaches
   migration this way can undergo multiple transitions without requiring
   major architectural changes.  Thus, when planning the transition to
   post-quantum cryptography, consider that when future cryptanalysis
   will trigger a transition to _post-post-quantum_ cryptography, it is
   better to be agile than to start from scratch.

   Hohm et al. identified circa 30 interpretations of the term
   "cryptographic agility" in their literature survey [CAMM], therefore
   referring to agility without defining it brings the potential of
   being misunderstood.  In this document, we encourage readers to
   reason about agility by relying on these guiding questions:

   1.  Can one *select* algorithms based on a specific context?

   2.  Can one *add* new cryptographic primitives or parameters?

   3.  Can obsolete crypto be *retired*?

   System and protocol designers can adjust the definition for their
   particular context, while ensuring that the adjusted definition is
   clearly stated, to avoid ambiguities.

   Agility in security protocols and message formats, such as IP
   Security (IPsec) and Internet Key Exchange (IKE) [RFC6071], Transport
   Layer Security (TLS)[RFC8446], Secure/Multipurpose Internet Mail
   Extensions (S/MIME)[RFC8551], is understood as the dynamic
   referencing of the algorithms to be used - the "select" component
   above.  A migration strategy that allows the existing and future
   cryptographic algorithms to be used simultaneously during a
   transition period (the "add" part) is not described in the respective
   standards.

Vaira, et al.            Expires 9 January 2025                [Page 11]
Internet-Draft                PQC use cases                    July 2024

   Revised versions of standards would be needed to integrate agility
   into protocols and formats.  This requires effort for standardization
   and implementation if a basic functionality, such as multiple
   signatures, e.g., in Cryptographic Message Syntax (CMS) [RFC5652], is
   not already available.  But even in the case of S/MIME and CMS,
   profiling is still necessary to describe how the multiple signatures
   are to be used specifically for the migration.

4.  Map of Migration Strategies to Reference Use Cases

   In this section, we establish a mapping between the reference use
   cases and their primary features, as summarized in the table below,
   and the digital signature migration strategies identified in the
   preceding section.

       +===============+=============+=============+===============+
       | Use Case      | Lifetime    | Protocol    | Backward      |
       |               |             |             | Compatibility |
       +===============+=============+=============+===============+
       | Industrial    | Long-lived  | Active      | Limited       |
       | communication |             | Negotiation |               |
       | protocols     |             |             |               |
       +---------------+-------------+-------------+---------------+
       | Software and  | Long-lived  | Passive     | Limited       |
       | Firmware      |             | Negotiation |               |
       | update        |             |             |               |
       +---------------+-------------+-------------+---------------+
       | Trust Anchor  | Long-lived  | Passive     | Limited       |
       | deployment    |             | Negotiation |               |
       +---------------+-------------+-------------+---------------+
       | CMS (S/MIME)  | Short-lived | Passive     | Mandatory     |
       |               | and Long-   | Negotiation |               |
       |               | lived       |             |               |
       +---------------+-------------+-------------+---------------+
       | Timestamping  | Long-lived  | Passive     | Optional      |
       |               |             | Negotiation |               |
       +---------------+-------------+-------------+---------------+

              Table 1: Summary of use cases and main features

   The map is constructed as a decision tree, which is available at:
   https://github.com/avaira77/pq-ietf-usecase/tree/main/decision-tree
   (https://github.com/avaira77/pq-ietf-usecase/tree/main/decision-
   tree).

Vaira, et al.            Expires 9 January 2025                [Page 12]
Internet-Draft                PQC use cases                    July 2024

5.  IANA Considerations

   This memo includes no request to IANA.

6.  Security Considerations

   This document should not affect the security of the Internet.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

7.2.  Informative References

   [IEEE.802.1AR-2018]
              "IEEE Standard for Local and Metropolitan Area Networks -
              Secure Device Identity", IEEE,
              DOI 10.1109/ieeestd.2018.8423794, ISBN ["9781504450195"],
              July 2018, <https://doi.org/10.1109/ieeestd.2018.8423794>.

   [RFC3161]  Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
              "Internet X.509 Public Key Infrastructure Time-Stamp
              Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August
              2001, <https://www.rfc-editor.org/rfc/rfc3161>.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
              <https://www.rfc-editor.org/rfc/rfc4949>.

   [RFC4998]  Gondrom, T., Brandner, R., and U. Pordesch, "Evidence
              Record Syntax (ERS)", RFC 4998, DOI 10.17487/RFC4998,
              August 2007, <https://www.rfc-editor.org/rfc/rfc4998>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/rfc/rfc5280>.

Vaira, et al.            Expires 9 January 2025                [Page 13]
Internet-Draft                PQC use cases                    July 2024

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, DOI 10.17487/RFC5652, September 2009,
              <https://www.rfc-editor.org/rfc/rfc5652>.

   [RFC6421]  Nelson, D., Ed., "Crypto-Agility Requirements for Remote
              Authentication Dial-In User Service (RADIUS)", RFC 6421,
              DOI 10.17487/RFC6421, November 2011,
              <https://www.rfc-editor.org/rfc/rfc6421>.

   [RFC7468]  Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
              PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
              April 2015, <https://www.rfc-editor.org/rfc/rfc7468>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/rfc/rfc8446>.

   [RFC9019]  Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A
              Firmware Update Architecture for Internet of Things",
              RFC 9019, DOI 10.17487/RFC9019, April 2021,
              <https://www.rfc-editor.org/rfc/rfc9019>.

   [I-D.ietf-pquip-pqc-engineers]
              Banerjee, A., Reddy.K, T., Schoinianakis, D., and T.
              Hollebeek, "Post-Quantum Cryptography for Engineers", Work
              in Progress, Internet-Draft, draft-ietf-pquip-pqc-
              engineers-04, 21 May 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
              pqc-engineers-04>.

   [I-D.ietf-pquip-pqt-hybrid-terminology]
              D, F. and M. P, "Terminology for Post-Quantum Traditional
              Hybrid Schemes", Work in Progress, Internet-Draft, draft-
              ietf-pquip-pqt-hybrid-terminology-03, 9 May 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
              pqt-hybrid-terminology-03>.

   [NIST.SP.800-208]
              Cooper, D. A., Apon, D. C., Dang, Q. H., Davidson, M. S.,
              Dworkin, M. J., Miller, C. A., and NIST, "Recommendation
              for Stateful Hash-Based Signature Schemes", NIST Special
              Publications (General) 800-208,
              DOI 10.6028/NIST.SP.800-208, 29 October 2020,
              <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-208.pdf>.

Vaira, et al.            Expires 9 January 2025                [Page 14]
Internet-Draft                PQC use cases                    July 2024

   [NIST.FIPS.186-5]
              Moody, D. and National Institute of Standards and
              Technology, "Digital Signature Standard (DSS)", NIST
              Federal Information Processing Standards
              Publications 186-5, DOI 10.6028/NIST.FIPS.186-5, 2023,
              <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.186-5.pdf>.

   [RFC8391]  Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A.
              Mohaisen, "XMSS: eXtended Merkle Signature Scheme",
              RFC 8391, DOI 10.17487/RFC8391, May 2018,
              <https://www.rfc-editor.org/rfc/rfc8391>.

   [RFC8554]  McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali
              Hash-Based Signatures", RFC 8554, DOI 10.17487/RFC8554,
              April 2019, <https://www.rfc-editor.org/rfc/rfc8554>.

   [RFC6071]  Frankel, S. and S. Krishnan, "IP Security (IPsec) and
              Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
              DOI 10.17487/RFC6071, February 2011,
              <https://www.rfc-editor.org/rfc/rfc6071>.

   [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
              Message Specification", RFC 8551, DOI 10.17487/RFC8551,
              April 2019, <https://www.rfc-editor.org/rfc/rfc8551>.

   [I-D.draft-ietf-lamps-pq-composite-sigs]
              Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S.
              Fluhrer, "Composite ML-DSA for use in Internet PKI", Work
              in Progress, Internet-Draft, draft-ietf-lamps-pq-
              composite-sigs-01, 6 June 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
              pq-composite-sigs-01>.

   [I-D.bonnell-lamps-chameleon-certs]
              Bonnell, C., Gray, J., Hook, D., Okubo, T., and M.
              Ounsworth, "A Mechanism for Encoding Differences in Paired
              Certificates", Work in Progress, Internet-Draft, draft-
              bonnell-lamps-chameleon-certs-04, 2 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-bonnell-
              lamps-chameleon-certs-04>.

Vaira, et al.            Expires 9 January 2025                [Page 15]
Internet-Draft                PQC use cases                    July 2024

   [I-D.ietf-lamps-cert-binding-for-multi-auth]
              Becker, A., Guthrie, R., and M. J. Jenkins, "Related
              Certificates for Use in Multiple Authentications within a
              Protocol", Work in Progress, Internet-Draft, draft-ietf-
              lamps-cert-binding-for-multi-auth-05, 29 April 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
              cert-binding-for-multi-auth-05>.

   [ANSI_ASHRAE.Standard.135-2016]
              American National Standards Institute (ANSI), "BACnetTM A
              Data Communication Protocol For Building Automation And
              Control Network", ANSI Standard 135-2016, 2016,
              <https://webstore.ansi.org/standards/ashrae/
              ansiashraestandard1352016>.

   [Addendum.bj.to.ANSI_ASHRAE.Standard.135-2016]
              American National Standards Institute (ANSI), "Addendum bj
              to BACnetTM A Data Communication Protocol For Building
              Automation And Control Network", ANSI Addendum bj to
              Standard 135-2016, 2016,
              <https://www.ashrae.org/File%20Library/
              Technical%20Resources/Standards%20and%20Guidelines/
              Standards%20Addenda/135_2016_bj_20191118.pdf>.

   [bsi.quantum-safe.crypto]
              Bundesamt fuer Sicherheit in der Informationstechnik,
              "Quantum-safe cryptography – fundamentals, current
              developments and recommendations", BSI Recommendations for
              action by the BSI, 2021,
              <https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/
              Publications/Brochure/quantum-safe-
              cryptography.pdf?__blob=publicationFile&v=4>.

   [entrust.composite-pki]
              Entrust, "Entrust introduces first commerically available
              post quantum ready pki platform", 2024,
              <https://www.entrust.com/newsroom/press-releases/2024/
              entrust-introduces-first-commercially-available-post-
              quantum-ready-pki-platform>.

   [CNSA2-0]  National Security Agency (NSA), "Announcing the Commercial
              National Security Algorithm Suite 2.0", 2022,
              <https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/
              CSA_CNSA_2.0_ALGORITHMS_.PDF>.

Vaira, et al.            Expires 9 January 2025                [Page 16]
Internet-Draft                PQC use cases                    July 2024

   [Dilithium.des.team]
              CRYSTALS-Dilithium design team, "CRYSTALS-Dilithium design
              team web page", 2023,
              <https://pq-crystals.org/dilithium/>.

   [Google.Sec.Blog]
              Google, "Toward Quantum Resilient Security Keys", 2023,
              <https://security.googleblog.com/2023/08/toward-quantum-
              resilient-security-keys.html?m=1>.

   [Hybrid.pqc.sig.hsk]
              Ghinea, D., Kaczmarczyck, F., Pullman, J., Cretin, J.,
              Koebl, S., Misoczki, R., Picod, J.-M., Invernizzi, L., and
              E. Bursztein, "Hybrid Post-quantum Signatures in Hardware
              Security Keys", 2023,
              <https://doi.org/10.1007/978-3-031-41181-6_26>.

   [NIST.FIPS.204]
              National Institute of Standards and Technology (NIST),
              "Module-Lattice-Based Digital Signature Standard",
              NIST FIPS 204 (Initial Public Draft), 2023,
              <https://csrc.nist.gov/pubs/fips/204/ipd>.

   [NIST.FIPS.205]
              National Institute of Standards and Technology (NIST),
              "Stateless Hash-Based Digital Signature Standard",
              NIST FIPS 205 (Initial Public Draft), 2023,
              <https://csrc.nist.gov/pubs/fips/205/ipd>.

   [NIST.SP.800-57.P1R5]
              National Institute of Standards and Technology (NIST),
              "Recommendation for Key Management: Part 1 – General",
              NIST Special Publication 800-57, 2020,
              <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-57pt1r5.pdf>.

   [X.509]    International Telecommunications Union, "Information
              technology – Open Systems Interconnection – The Directory:
              Public-key and attribute certificate frameworks",
              ITU-T Recommendation X.509, 2019.

   [CAMM]     Hohm, J., Heinemann, A., and A. Wiesmaier, "Towards a
              maturity model for crypto-agility assessment", 2022,
              <http://arxiv.org/abs/2202.07645>.

Vaira, et al.            Expires 9 January 2025                [Page 17]
Internet-Draft                PQC use cases                    July 2024

Appendix A.  Post-Quantum Migration Properties

   This section aims to establish a collection of characteristics for
   categorizing the use cases outlined in Section 2.  The objective is
   to enhance the document's utility by providing a framework for
   classifying use cases not explicitly addressed here.  For instance,
   implementors can categorize their own use case and subsequently
   identify a similar one in this document based on shared properties/
   classification.

A.1.  Lifetime

   This classification distinguishes between short-lived and long-lived
   use cases.  However, in practical terms, this distinction is
   challenging due to the nature of each use case's lifespan, which can
   be on a spectrum.

   1.  Short-lived: In this context, a short-lived use case is
       characterized by a duration of less than 5 years.  This timeframe
       aligns with common organizational practices, where hardware, for
       example servers in a data center, is typically replaced within a
       5-year cycle.

   2.  Long-lived: In the context of this document, a long-lived use
       case spans more than 10 years.  While there isn't a specific
       rationale for this timeframe, it is noteworthy that cryptographic
       recommendations, for example [NIST.SP.800-57.P1R5], often provide
       guidance for a duration of up to ten years from the time of their
       publication.

A.2.  Protocol

   Cryptographic protocols can be divided in Active Negotiation (real-
   time cryptography), Passive Negotiation (asynchronous cryptography),
   and Non Agile (no graceful migration).

   1.  Active Negotiation: Protocols with existing mechanisms for real-
       time cryptographic negotiation such as TLS and IKE already
       contain mechanisms for upgraded clients to downgrade the
       cryptography in a given session in order to communicate with a
       legacy peer.  These protocols provide the easiest migration path
       as these mechanisms should be used to bridge across traditional
       and post-quantum cryptography.

Vaira, et al.            Expires 9 January 2025                [Page 18]
Internet-Draft                PQC use cases                    July 2024

   2.  Passive Negotiation: Protocols with existing mechanisms for non-
       real-time or asynchronous cryptographic negotiation.  For example
       a PKI end entity who publishes multiple encryption certificates
       for themselves, each containing a public key for a different
       algorithm, or code signing object carrying multiple signatures on
       different algorithms.

   3.  Non-agile: no graceful migration is possible; the community
       decides that as of a certain date legacy clients will no longer
       be able to interoperate with upgraded clients.

A.3.  Backward compatibility

   The following scenarios may arise:

   1.  Optional: Backward compatibility isn't needed, either because
       post-quantum migration is unnecessary or already addressed within
       a specific protocol.

   2.  Limited: Backward compatibility is necessary for a defined
       period, such as during a migration time window.

   3.  Mandatory: Backward compatibility is essential throughout the use
       case's entire lifespan due to the absence of identifiable
       migration strategies.

Appendix B.  Composite Signature individual and organization position
             statements

   1.  BSI - The document [bsi.quantum-safe.crypto] recommends requiring
       that PQC lattice schemes only be used within a PQ/T hybrid.  More
       specifically this document includes the following recommendation:

       "Therefore, quantum computer-resistant methods should not be used
       alone - at least in a transitional period - but only in hybrid
       mode, i.e. in combination with a classical method.  For this
       purpose, protocols must be modified or supplemented accordingly.
       In addition, public key infrastructures, for example, must also
       be adapted"

       Also Stavros Kousidis from BSI says: "from a strategic point of
       view we don’t want to replace our current RSA algorithm with
       standalone Dilithium since: If Dilithium does not withstand
       cryptanalysis in the future then all our efforts are for nothing.
       With a composite signature Dilithium+ECDSA in AND-mode we can buy
       ourselves some time in case the Dilithium security guarantees do
       not withstand future cryptanalysis."

Vaira, et al.            Expires 9 January 2025                [Page 19]
Internet-Draft                PQC use cases                    July 2024

   2.  Google: according to [Google.Sec.Blog]: "Relying on a hybrid
       signature is critical as the security of Dilithium and other
       recently standardized quantum resistant algorithms haven’t yet
       stood the test of time and recent attacks on Rainbow (another
       quantum resilient algorithm) demonstrate the need for caution.
       This cautiousness is particularly warranted for security keys as
       most can’t be upgraded – although we are working toward it for
       OpenSK.  The hybrid approach is also used in other post-quantum
       efforts like Chrome’s support for TLS".

   3.  Entrust: During the transition to post-quantum cryptography,
       there will be uncertainty as to the strength of cryptographic
       algorithms; we will no longer fully trust traditional
       cryptography such as RSA, Diffie-Hellman, DSA and their elliptic
       curve variants, but we will also not fully trust their post-
       quantum replacements until they have had sufficient scrutiny and
       time to discover and fix implementation bugs.  Unlike previous
       cryptographic algorithm migrations, the choice of when to migrate
       and which algorithms to migrate to, is not so clear.  Even after
       the migration period, it may be advantageous for an entity's
       cryptographic identity to be composed of multiple public-key
       algorithms.  In 2024 Entrust added support for composite
       signatures in PKI infrastructure ([entrust.composite-pki]):

       "With this launch, the company’s cloud-based PKI as a Service
       offering now can provide both composite and pure quantum-safe
       certificate authority hierarchies, enabling customers to test or
       implement quantum-safe scenarios and infrastructure."

   4.  Robert Hulshof: "The rationale behind combined keys is that I can
       see an important use-case for very sensitive data (government,
       financial or other high value data) to combine multiple (PQ) key
       algorithms, and that this migration to PQ is a good time to start
       supporting that by default in the crypto libraries.  Trying to
       estimate the probability that a NIST standardized Crypto
       algorithm gets broken in the next 5-10 years is very difficult.
       However I assume that everybody agrees that this probability is
       definitely not zero.  Personally I would put that probability
       somewhere in the range of 0.1% – 1%. If I were the government/
       bank etc.  I would not like to have a 1% risk that all my secrets
       get exposed.  Adding one or two more PQ algorithms would reduce
       that probability to 1 in 5 million or 1 in a Billion would be
       much more acceptable."

   5.  MTG - Falko Strenzke: "Without hybrid signatures, a decision to
       move away from traditional signatures to Dilithium (or other non-
       hash-based signatures) has a certain risk to make things worse
       and I think many decision makers will not be ready to take the

Vaira, et al.            Expires 9 January 2025                [Page 20]
Internet-Draft                PQC use cases                    July 2024

       responsibility for it until the quantum computer threat becomes
       imminent.  If composite signature is not standardised, non-
       composite hybrids would be left.  This implies protocol changes
       which will:

       1.  need more discussion,

       2.  need more changes to existing applications,

       3.  and thus be more bug prone.

       4.  Not having hybrid signatures at all will likely cause many
           decision makers to

       5.  use hash-based schemes where possible / affordable

       6.  and elsewhere stick to traditional schemes as long as
           possible, thus effectively delaying the migration to PQC."

   6.  Transmute - Orie Steele: "There are use cases for long lived
       verifiable credentials, and attribute cert like stuff we work on
       in supply chain, with DHS / CBP."

   7.  CRYSTALS-Dilithium design team states in [Dilithium.des.team]
       that: “For users who are interested in using Dilithium, we
       recommend the following: Use Dilithium in a so-called hybrid mode
       in combination with an established "pre-quantum" signature
       scheme.”

   8.  Hybrid Post-Quantum Signatures in Hardware Security Keys: the
       paper [Hybrid.pqc.sig.hsk] describes a hybrid signature scheme.
       Below an excerpt from it: “A hybrid signature scheme combines a
       classical signature algorithm with a post-quantum secure
       signature algorithm.  Before discussing the design of our hybrid
       scheme, we explain why such an approach is relevant instead of
       simply replacing classically secure schemes with post-quantum
       secure schemes.  We present the assumptions below:

       1.  Cryptographically-Relevant Quantum Computers (i.e. with
           enough qubits to break ECDSA) are not available yet.

       2.  Classical signature algorithms withstands attacks from
           classical computers.

       3.  The post-quantum secure signature algorithm might be
           breakable by classical computers due to design or
           implementation bugs.  If any of these assumptions fails,
           using a hybrid approach instead of replacing classical

Vaira, et al.            Expires 9 January 2025                [Page 21]
Internet-Draft                PQC use cases                    July 2024

           schemes with post-quantum schemes indeed does not add any
           security.  We believe that all of these assumptions are
           currently correct.  The third assumption is motivated by a
           newly discovered attack against Rainbow, one of the NIST
           standardization finalists.  We can now discuss the informal
           requirements a hybrid scheme H should satisfy:

       4.  If a quantum computer becomes available, and hence H’s
           underlying classical scheme is broken, H should maintain the
           security of its underlying post-quantum scheme.

       5.  If a classical attack for H’s underlying post-quantum secure
           scheme is discovered, H should maintain the security of its
           underlying classical scheme."

Acknowledgements

   This draft would not be possible without the support of a great
   number of contributors.  We thank Stavros Kousidis, Robert Hulshof,
   Falko Strenzke and Orie Steele for allowing us to use their
   statements regarding composite signatures.

Authors' Addresses

   Antonio Vaira
   Siemens
   Werner-von-Siemens-Strasse 1
   80333 Munich
   Germany
   Email: antonio.vaira@siemens.com
   URI:   https://www.siemens.com

   Hendrik Brockhaus
   Siemens
   Werner-von-Siemens-Strasse 1
   80333 Munich
   Germany
   Email: hendrik.brockhaus@siemens.com
   URI:   https://www.siemens.com

   Alexander Railean
   Siemens
   Werner-von-Siemens-Strasse 1
   80333 Munich
   Germany
   Email: alexander.railean@siemens.com

Vaira, et al.            Expires 9 January 2025                [Page 22]
Internet-Draft                PQC use cases                    July 2024

   URI:   https://www.siemens.com

   John Gray
   Entrust
   1187 Park Place
   Minneapolis, MN 55379
   United States of America
   Email: john.gray@entrust.com
   URI:   https://www.entrust.com

   Mike Ounsworth
   Entrust
   1187 Park Place
   Minneapolis, MN 55379
   United States of America
   Email: mike.ounsworth@entrust.com
   URI:   https://www.entrust.com

Vaira, et al.            Expires 9 January 2025                [Page 23]