Post-quantum cryptography use cases
draft-vaira-pquip-pqc-use-cases-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Antonio Vaira , Hendrik Brockhaus , Alexander Railean , John Gray , Mike Ounsworth | ||
| Last updated | 2023-10-23 | ||
| RFC stream | (None) | ||
| Formats | |||
| 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-00
Post-Quantum Use In Protocols A. Vaira
Internet-Draft H. Brockhaus
Intended status: Informational A. Railean
Expires: 25 April 2024 Siemens
J. Gray
M. Ounsworth
Entrust
23 October 2023
Post-quantum cryptography use cases
draft-vaira-pquip-pqc-use-cases-00
Abstract
This document focuses on the critical challenge of migrating long-
term security assertions with security requirements spanning over a
decade, encompassing X.509 certificates, including those that serve
as manufacturer issued certificates (IDevID), signed firmware/
software, and other electronic artifacts. We investigate a range of
migration strategies, specifically hybrid cryptography and the
feasibility of stateful Hash-Based Signatures (HBS) schemes,
including its pros and cons. To offer a comprehensive context, we
present a list of use cases centered around long-lived security
assertions, categorize them, and evaluate them against the various
migration strategies identified. We also aim at listing pros and
cons associated with each method.
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.
Vaira, et al. Expires 25 April 2024 [Page 1]
Internet-Draft PQC use cases October 2023
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 25 April 2024.
Copyright Notice
Copyright (c) 2023 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
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Post-quantum Migration Strategies for Signing . . . . . . . . 5
2.1. Stateful Hash-based Signature Schemes . . . . . . . . . . 5
2.2. Stateless Hash-based Signature Schemes . . . . . . . . . 5
2.3. Protocol Revision (Cryptographic Agility) . . . . . . . . 5
2.4. Multiple Signatures . . . . . . . . . . . . . . . . . . . 6
2.5. Composite Signatures . . . . . . . . . . . . . . . . . . 6
3. Use cases collection . . . . . . . . . . . . . . . . . . . . 7
3.1. Industrial communication protocols (that rely on IETF
RFCs) . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Suitable migration mechanisms . . . . . . . . . . . . 8
Vaira, et al. Expires 25 April 2024 [Page 2]
Internet-Draft PQC use cases October 2023
3.2. Software update . . . . . . . . . . . . . . . . . . . . . 8
3.3. Firmware update . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Suitable migration mechanisms . . . . . . . . . . . . 10
3.4. Trust Anchor deployment . . . . . . . . . . . . . . . . . 10
3.4.1. Suitable migration mechanisms . . . . . . . . . . . . 11
3.5. Timestamping . . . . . . . . . . . . . . . . . . . . . . 12
3.5.1. Suitable migration mechanisms . . . . . . . . . . . . 12
3.6. CMS (S/MIME) . . . . . . . . . . . . . . . . . . . . . . 12
3.6.1. Suitable migration mechanisms . . . . . . . . . . . . 12
3.7. Additional use cases . . . . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Appendix 1 - post-quantum migration properties . . . 17
A.1. Active Negotiation . . . . . . . . . . . . . . . . . . . 17
A.2. Passive Negotiation . . . . . . . . . . . . . . . . . . . 17
A.3. Non Agile . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix B. Appendix 2 - Composite Signature individual and
organization position statements . . . . . . . . . . . . 18
B.1. BSI - Stavros Kousidis . . . . . . . . . . . . . . . . . 18
B.2. Google . . . . . . . . . . . . . . . . . . . . . . . . . 18
B.3. Entrust . . . . . . . . . . . . . . . . . . . . . . . . . 18
B.4. Charter - Robert Hulshof . . . . . . . . . . . . . . . . 19
B.5. MTG - Falko Strenzke . . . . . . . . . . . . . . . . . . 19
B.6. Transmute - Orie Steele . . . . . . . . . . . . . . . . . 19
B.7. CRYSTALS-Dilithium design team . . . . . . . . . . . . . 20
B.8. Hybrid Post-Quantum Signatures in Hardware Security
Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
The purpose of this document is to compile a list of real-world use
cases, focusing on long-term security assertions. This document
additionally aims at evaluating, for each use case, a set of
migration strategies, like hybrid cryptography, including multiple
and composite signatures, and the feasibility of using stateful Hash-
Based Signature (HBS) schemes, evaluating the pros and cons of each
approach.
The document is structured into the following sections: "Post-quantum
migration strategies", lists possible migration approaches; "Use case
collection", describes, at a high level, the use cases at hand,
including an analysis of the pros and cons for each of the migration
strategies applicable.
Vaira, et al. Expires 25 April 2024 [Page 3]
Internet-Draft PQC use cases October 2023
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.
1.2. Problem Statement
The transition to post-quantum cryptography poses a distinctive
challenge in the domain of modern digital cryptography. This
peculiarity stems from the absence of complete trust in both the
outgoing and incoming cryptographic algorithms, crucial for ensuring
data security throughout their required lifespans. This is of
particular significance in guaranteeing the security of long-lived
digital signatures, which are integral to secure software update
workflows and manufacturer issued certificates, among other
applications. Despite having NIST finalists for post-quantum
cryptographic signature algorithms, concerns persist regarding their
long-term security. At present, only stateful Hash-Based Signature
schemes are considered secure. At the same time, regulatory bodies
(TODO: add references) mandate the incorporation of post-quantum
cryptographic techniques, and in some cases, hybrid cryptography, as
a proactive response to the quantum threat. As of now, the most
effective strategies for transitioning to protect long-lasting
digital signatures across diverse usage scenarios remain uncertain.
1.3. Scope
The scope of this document is to compile a list of real-life use
cases characterized by long-term security requirements, which are
typically challenging to update, for example no over the air update
mechanisms are available. These scenarios necessitate an early
implementation of post-quantum cryptography migration strategies.
Consequently, mitigation mechanisms must be introduced, given the
limited experience with post-quantum cryptography to date.
Furthermore, it is essential to consider regional regulations that
may mandate the use of hybrid cryptography in specific instances.
1.4. Terminology
This document makes use of the terminology defined in [RFC4949],
[RFC5280], [RFC9019], [I-D.ietf-pquip-pqc-engineers],
[I-D.ietf-pquip-pqt-hybrid-terminology] and TODO: add ref to
composite signature drafts.
Vaira, et al. Expires 25 April 2024 [Page 4]
Internet-Draft PQC use cases October 2023
2. 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].
2.1. Stateful Hash-based Signature Schemes
The only algorithms that can be considered safe against attacks with
quantum computers with sufficient certainty today are the stateful
hash-based signature (HBS) schemes [NIST.SP.800-208]
[NIST.FIPS.186-5] XMSS [RFC8391] and LMS [RFC8554]. According to
NIST, these stateful HBS algorithms offer better performance than
stateless HBS algorithms, and the underlying technology is considered
well understood. Moreover stateful HBS algorithms are considered
safe against attacks by quantum computers but the lack of standard
operating procedures for how to manage state makes adoption harder.
Especially for the secure signing of data that can be signed
repeatedly over a very long period of time and whose signatures must
be able to be securely validated with the same public key, stateful
HBS do not appear to be suitable. This is because there are
currently insufficient solutions for the replacement of the hardware
security modules used and for disaster recovery cases.
2.2. Stateless Hash-based Signature Schemes
[NIST.FIPS.205] specifies the ML-SLH (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.
2.3. Protocol Revision (Cryptographic Agility)
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 usually understood as the dynamic
referencing of the algorithms to be used. A concrete migration
strategy that allows the existing and future cryptographic algorithms
to be used simultaneously during a transition period is usually not
described in the respective standards.
Vaira, et al. Expires 25 April 2024 [Page 5]
Internet-Draft PQC use cases October 2023
An extension of the existing standards would be needed to integrate
the required agility into the existing protocols and formats. This
is a lot of effort for standardization and implementations 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, a corresponding profiling is still
necessary to describe how the multiple signatures are to be used
specifically for the migration.
2.4. 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 2.3.
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].
2.5. 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
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
Vaira, et al. Expires 25 April 2024 [Page 6]
Internet-Draft PQC use cases October 2023
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.ounsworth-pq-composite-sigs] in more detail.
3. Use cases collection
EDNOTE9: The collection of use cases requires further edit.
This section is the core of this document. For each use case, we
present a concise overview of the use case and a list of potential
migration strategies. For each migration strategy, we highlight the
advantages and disadvantages that stem from considering real-world
deployment scenarios.
3.1. Industrial communication protocols (that rely on IETF RFCs)
Several industrial communication protocols, traditionally orthogonal
to 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 building automation industry makes use of the data communication
protocol 'Building Automation and Control Networks / Secure Connect'
(BACnet/SC) [ANSI_ASHRAE.Standard.135-2016]. 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 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.
The main features of BACnet/SC are:
* it makes use of WebSockets secured via TLS 1.3,
* it relies on X.509 certificates to authenticate the nodes in the
network,
* DNS host name resolution and DHCP are supported,
* it is agnostic to IP versions (IPv4 or IPv6),
* it can be NATted.
Vaira, et al. Expires 25 April 2024 [Page 7]
Internet-Draft PQC use cases October 2023
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
[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.
Furthermore, the regulations applicable to the environment the
BACnet/SC-enabled devices is operated in may necessitate the usage of
a specific migration strategy, e.g., the use of hybrid cryptography.
3.1.1. Suitable migration mechanisms
* Multiple Signatures - These can be used to give the environment
resilience to cryptanalysis attacks and technological advancements
because should a critical break happen, the secondary signature
should allow for addition time for upgrade which will be welcome
given the location constraints. This would require cryptographic
library updates as well as protocol level changes to support
multiple signatures. Additionally, it would require the
introduction of security policy to allow to switch the validation
from one signature to the other, if needed. These modifications
to the protocols, and introduction of additional policies will not
be easily attainable due to the interdependencies of protocols and
might come at a detriment of interoperability especially cross-
vendor interoperability.
* Composite Signatures - Similar to multiple signatures but may only
require updates to the cryptographic libraries as well as a
signature algorithm update in protocols. It is likely composite
signatures would be easier to deploy as single key and signature
objects are used which is similar to what has historically been
used. In the use case at hand, this would be the best fit,
because it would require no modifications of industrial protocol,
which are usually harder to update.
3.2. Software update
TBD
Vaira, et al. Expires 25 April 2024 [Page 8]
Internet-Draft PQC use cases October 2023
3.3. Firmware update
EDNOTE3: The firmware update use case, and the software update one,
have to be further defined and its differences have to be made more
clear.
Firmware, defined in [RFC4949], refers to computer programs and data
stored in hardware, typically in read-only memory (ROM) or
programmable read-only memory (PROM). These programs and data are
non-modifiable during execution, offering low-level hardware control.
Secure firmware updates are crucial for ensuring device security and
long-term operation, 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 "simple" 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.
At a high level, a usual process involves, a firmware build server,
which requests a signature from a signing service. The signing
service, often safeguarding the signing private key in secure
environments like Hardware Security Modules (HSMs), returns the
signature after authenticating the request.
Subsequently, the firmware is distributed to target devices, which in
turn must validate the firmware 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.
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 lifespan 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
Vaira, et al. Expires 25 April 2024 [Page 9]
Internet-Draft PQC use cases October 2023
* 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.
3.3.1. Suitable migration mechanisms
Given the long term requirements of the signatures and physically
contrained locations, a signature used in these environments must be
able to withstand future crytanalysis attacks as well as
technological advancements. Therefore the following migration
mechanisms should be considerd for these enviornments:
* Multiple Signatures - These can be used to give the environment
resilience to crytanalysis attacks and technological advancements
because should a critical break happen, the secondary signature
should allow for addition time for upgrade which will be welcome
given the location constraints. This would require cryptographic
library updates as well as protocol level changes to support
multiple signatures.
* Composite Signatures - Similar to multiple signatures but may only
require updates to the cryptographic libraries as well as a
signature algorithm update in protocols. It is likely composite
signatures would be easier to deploy as single key and signature
objects are used which is similar to what has historically be
used.
* Stateless hash based signatures - In constrained locations where
larger signature sizes are acceptable, direct upgrade to a
stateless hash based signature may be sufficient.
3.4. 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-
Vaira, et al. Expires 25 April 2024 [Page 10]
Internet-Draft PQC use cases October 2023
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 device or software.
Two common variations of this use case are:
* injection within a factory: in industrial contexts, Trust Anchors
are typically injected into target devices during the
manufacturing phase. Devices leaving the assembly line do not
possess any credentials or Trusted Anchors initially. To
bootstrap a Trust Anchor, the device is placed in a physically
secure environment accessible only to trustworthy personnel. This
injection can occur during manufacturing or when a device is being
resold, but it's critical to note that not all scenarios support
this method, potentially requiring the return of the device to the
OEM for post-quantum Trust Anchor injection or it may be even not
supported at all.
* 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.
3.4.1. Suitable migration mechanisms
Trust anchors that have limited to no ability to be upgraded but
which must be able to be trusted for a long time will require the use
of signatures which must be able to withstand future crytanalysis
attacks as well as technological advancements. The following
migration mechanisms should be considered for these environments:
* Multiple Signatures - These can be used to give the environment
resilience to crytanalysis attacks and technological advancements
because should a critical break happen, the secondary signature
should allow for addition time for upgrade which will be welcome
given the location constraints. This would require cryptographic
library updates as well as protocol level changes to support
multiple signatures.
Vaira, et al. Expires 25 April 2024 [Page 11]
Internet-Draft PQC use cases October 2023
* Composite Signatures - Similar to multiple signatures but may only
require updates to the cryptographic libraries as well as a
signature algorithm update in protocols. It is likely composite
signatures would be easier to deploy as single key and signature
objects are used which is similar to what has historically be
used.
* Stateless hash based signatures - In constrained locations where
larger signature sizes are acceptable, direct upgrade to a
stateless hash based signature may be sufficient.
3.5. Timestamping
EDNOTE5: RFC 4998 - we could study this to understand how to re-sign
old timestamp messages. Question: does re-signing give protection
against a full break of the original algorithm. AV: an example is
provided by "ETSI EN 319 142-1" (and "ETSI EN 319 142-2"), the
standards define PDF advanced electronic signatures which have legal
value EU. I assume that this concept may be extended to similar use
cases, i.e., wherever long term validation is required new time-
stamps may be added using post-quantum cryptography
3.5.1. Suitable migration mechanisms
TBD
3.6. CMS (S/MIME)
EDNOTE6: You can do infinite nesting in CMS.
EDNOTE7: The difficulty here will be non-uniform adoption: there are
many many many email clients in the world at varying levels of
maturity and maintenance. It is expected that some email clients
will support PQ algorithms quickly while others may take more time or
never adopt them fully. Suggestion to IETF: Study be put into
RFC5652 the Cryptographic Message Syntax into signing messages with
multiple signatures in a way that unsupported signatures will be
ignored (likely this already "just works"). Email encryption
probably requires either a flag day (you simply cannot encrypt a
message for a recipient if you do not understand their PQ
certificate)
3.6.1. Suitable migration mechanisms
TBD
Vaira, et al. Expires 25 April 2024 [Page 12]
Internet-Draft PQC use cases October 2023
3.7. Additional use cases
EDNOTE8: TO-DOs:
* add additional post-quantum relevant use cases which cover aspects
not covered so far, this could also include use cases that are not
common in our line of work (e.g., FAA airworthiness
certifications, medical records, etc.), maybe contributed by other
participants,
* any party that would be interested in contributing in this work
may add additional post-quantum relevant use cases that are closer
to her experience/field,
* the goal is to cover as much ground as possible in terms of use
cases and to be able to define categories of use cases,
4. IANA Considerations
This memo includes no request to IANA.
5. Security Considerations
This document should not affect the security of the Internet.
6. References
6.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>.
6.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>.
Vaira, et al. Expires 25 April 2024 [Page 13]
Internet-Draft PQC use cases October 2023
[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>.
[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-02, 20 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
pqc-engineers-02>.
Vaira, et al. Expires 25 April 2024 [Page 14]
Internet-Draft PQC use cases October 2023
[I-D.ietf-pquip-pqt-hybrid-terminology]
D, F., "Terminology for Post-Quantum Traditional Hybrid
Schemes", Work in Progress, Internet-Draft, draft-ietf-
pquip-pqt-hybrid-terminology-01, 20 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
pqt-hybrid-terminology-01>.
[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>.
[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>.
Vaira, et al. Expires 25 April 2024 [Page 15]
Internet-Draft PQC use cases October 2023
[I-D.ounsworth-pq-composite-sigs]
Ounsworth, M., Gray, J., and M. Pala, "Composite
Signatures For Use In Internet PKI", Work in Progress,
Internet-Draft, draft-ounsworth-pq-composite-sigs-09, 29
May 2023, <https://datatracker.ietf.org/doc/html/draft-
ounsworth-pq-composite-sigs-09>.
[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-02, 21 September 2023,
<https://datatracker.ietf.org/doc/html/draft-bonnell-
lamps-chameleon-certs-02>.
[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-01, 26 June 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
cert-binding-for-multi-auth-01>.
[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>.
[X.509] International Telecommunications Union, "Information
technology – Open Systems Interconnection – The Directory:
Public-key and attribute certificate frameworks",
ITU-T Recommendation X.509, 2019.
[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>.
Vaira, et al. Expires 25 April 2024 [Page 16]
Internet-Draft PQC use cases October 2023
[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>.
Appendix A. Appendix 1 - post-quantum migration properties
The purpose of this section is to define a set of properties that can
be used to classify each of the use-cases listed in a consistent way
Section 3. The goal is to make the document a resource to help
classify use cases which are not covered herein because, for example,
implementors could classify their own use-case and then find one in
this document with the same properties / classification.
A.1. Active Negotiation
TBD
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.
A.2. Passive Negotiation
TBD
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.
A.3. Non Agile
TBD
Non-agile or flag day implies 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.
Vaira, et al. Expires 25 April 2024 [Page 17]
Internet-Draft PQC use cases October 2023
Appendix B. Appendix 2 - Composite Signature individual and
organization position statements
B.1. BSI - Stavros Kousidis
"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."
B.2. Google
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. TODO: How to
reference this page: https://security.googleblog.com/2023/08/toward-
quantum-resilient-security-keys.html?m=1
B.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.
Entrust will support composite signatures in PKI infrastructure.
Vaira, et al. Expires 25 April 2024 [Page 18]
Internet-Draft PQC use cases October 2023
B.4. Charter - 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 a million or 1 in a Billion would be
much more acceptable."
B.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 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:
* need more discussion,
* need more changes to existing applications,
* and thus be more bug prone.
* Not having hybrid signatures at all will likely cause many
decision makers to
- use hash-based schemes where possible / affordable
- and elsewhere stick to traditional schemes as long as possible,
thus effectively delaying the migration to PQC."
B.6. Transmute - Orie Steele
TODO but something about this: There are use cases for long lived
verifiable credentials, and attribute cert like stuff we work on in
supply chain, with DHS / CBP.
Vaira, et al. Expires 25 April 2024 [Page 19]
Internet-Draft PQC use cases October 2023
B.7. CRYSTALS-Dilithium design team
* https://pq-crystals.org/dilithium/ (accessed: 2023-08-21): “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.”
B.8. Hybrid Post-Quantum Signatures in Hardware Security Keys
https://storage.googleapis.com/pub-tools-public-publication-data/
pdf/8becef5ac3da51c3b2e36d2dbcd18a4bd3d220d9.pdf
“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 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: 1. 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. 2. 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. TBD.
Vaira, et al. Expires 25 April 2024 [Page 20]
Internet-Draft PQC use cases October 2023
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
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 25 April 2024 [Page 21]