Composite ML-KEM for Use in the Internet X.509 Public Key Infrastructure and CMS
draft-ietf-lamps-pq-composite-kem-03
| Document | Type | Active Internet-Draft (lamps WG) | |
|---|---|---|---|
| Authors | Mike Ounsworth , John Gray , Massimiliano Pala , Jan Klaußner , Scott Fluhrer | ||
| Last updated | 2024-03-02 | ||
| Replaces | draft-ounsworth-pq-composite-kem | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
Mailing list discussion |
||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-lamps-pq-composite-kem-03
LAMPS M. Ounsworth
Internet-Draft J. Gray
Intended status: Standards Track Entrust
Expires: 3 September 2024 M. Pala
OpenCA Labs
J. Klaussner
D-Trust GmbH
S. Fluhrer
Cisco Systems
2 March 2024
Composite ML-KEM for Use in the Internet X.509 Public Key Infrastructure
and CMS
draft-ietf-lamps-pq-composite-kem-03
Abstract
This document defines Post-Quantum / Traditional composite Key
Encapsulation Mechanism (KEM) algorithms suitable for use within
X.509, PKIX and CMS protocols. Composite algorithms are provided
which combine ML-KEM with RSA-KEM and ECDH-KEM. The provided set of
composite algorithms should meet most Internet needs.
This document assumes that all component algorithms are KEMs, and
therefore it depends on [I-D.ietf-lamps-rfc5990bis] and
[I-D.ounsworth-lamps-cms-dhkem] in order to promote RSA and ECDH
respectively into KEMs. For the purpose of combining KEMs, the
combiner function from [I-D.ounsworth-cfrg-kem-combiners] is used.
For use within CMS, this document is intended to be coupled with the
CMS KEMRecipientInfo mechanism in [I-D.housley-lamps-cms-kemri].
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://lamps-
wg.github.io/draft-composite-kem/draft-ietf-lamps-pq-composite-
kem.html#name-asn1-module. Status information for this document may
be found at https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-
composite-kem/.
Discussion of this document takes place on the LAMPS Working Group
mailing list (mailto:spams@ietf.org), which is archived at
https://datatracker.ietf.org/wg/lamps/about/. Subscribe at
https://www.ietf.org/mailman/listinfo/spams/.
Ounsworth, et al. Expires 3 September 2024 [Page 1]
Internet-Draft Composite KEMs March 2024
Source for this draft and an issue tracker can be found at
https://github.com/lamps-wg/draft-composite-kem.
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 3 September 2024.
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. Changes in version -03 . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Composite Design Philosophy . . . . . . . . . . . . . . . 6
2.3. Composite Key Encapsulation Mechanisms (KEMs) . . . . . . 7
2.3.1. Composite KeyGen . . . . . . . . . . . . . . . . . . 8
2.3.2. Composite Encaps . . . . . . . . . . . . . . . . . . 8
2.3.3. Composite Decaps . . . . . . . . . . . . . . . . . . 8
2.4. Component Algorithm Selection Criteria . . . . . . . . . 9
3. Composite Key Structures . . . . . . . . . . . . . . . . . . 10
3.1. pk-CompositeKEM . . . . . . . . . . . . . . . . . . . . . 10
3.2. CompositeKEMPublicKey . . . . . . . . . . . . . . . . . . 10
Ounsworth, et al. Expires 3 September 2024 [Page 2]
Internet-Draft Composite KEMs March 2024
3.3. CompositeKEMPrivateKey . . . . . . . . . . . . . . . . . 11
3.4. Encoding Rules . . . . . . . . . . . . . . . . . . . . . 12
3.5. Key Usage Bits . . . . . . . . . . . . . . . . . . . . . 12
4. Composite KEM Structures . . . . . . . . . . . . . . . . . . 12
4.1. kema-CompositeKEM . . . . . . . . . . . . . . . . . . . . 12
4.2. CompositeCiphertextValue . . . . . . . . . . . . . . . . 13
4.3. KEM Combiner . . . . . . . . . . . . . . . . . . . . . . 13
4.3.1. KMAC-KDF . . . . . . . . . . . . . . . . . . . . . . 14
5. Example KEM Combiner instantiation . . . . . . . . . . . . . 15
6. Algorithm Identifiers . . . . . . . . . . . . . . . . . . . . 15
6.1. RSA-KEM Parameters . . . . . . . . . . . . . . . . . . . 17
7. Use in CMS . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Underlying Components . . . . . . . . . . . . . . . . . . 18
7.2. RecipientInfo Conventions . . . . . . . . . . . . . . . . 20
7.3. Certificate Conventions . . . . . . . . . . . . . . . . . 20
7.4. SMIMECapabilities Attribute Conventions . . . . . . . . . 21
8. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9.1. Object Identifier Allocations . . . . . . . . . . . . . . 28
9.1.1. Module Registration - SMI Security for PKIX Module
Identifier . . . . . . . . . . . . . . . . . . . . . 28
9.1.2. Object Identifier Registrations - SMI Security for PKIX
Algorithms . . . . . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10.1. Policy for Deprecated and Acceptable Algorithms . . . . 30
10.2. KEM Combiner . . . . . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Samples . . . . . . . . . . . . . . . . . . . . . . 36
Appendix B. Implementation Considerations . . . . . . . . . . . 36
B.1. FIPS certification . . . . . . . . . . . . . . . . . . . 36
B.2. Backwards Compatibility . . . . . . . . . . . . . . . . . 36
B.2.1. Parallel PKIs . . . . . . . . . . . . . . . . . . . . 37
Appendix C. Intellectual Property Considerations . . . . . . . . 38
Appendix D. Contributors and Acknowledgments . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Changes in version -03
* Changed the title to reflect that it is specific to ML-KEM.
* Added Max Pala, Jan Klaussner, and Scott Fluhrer as authors.
* Added text to Introduction to justify where and why this mechanism
would be used.
* Added section "Use in CMS".
Ounsworth, et al. Expires 3 September 2024 [Page 3]
Internet-Draft Composite KEMs March 2024
* Switched all KDFs for both the combiner and the CMS KEMRI to use
id-kmac128 or id-kmac256 from I-D.ietf-lamps-cms-sha3-hash.
Still to do in a future version:
[ ] We need PEM samples ... 118 hackathon? OQS friends? David @ BC?
The right format for samples is probably to follow the hackathon ...
a Dilithium or ECDSA trust anchor certificate, a composite KEM end
entity certificate, and a CMS EnvolepedData sample encrypted for that
composite KEM certificate.
2. Introduction
The migration to post-quantum cryptography is unique in the history
of modern digital cryptography in that neither the old outgoing nor
the new incoming algorithms are fully trusted to protect data for
long data lifetimes. The outgoing algorithms, such as RSA and
elliptic curve, may fall to quantum cryptalanysis, while the incoming
post-quantum algorithms face uncertainty about both the underlying
mathematics falling to classical algorithmic attacks as well as
hardware and software implementations that have not had sufficient
maturing time to rule out catastrophic implementation bugs. Unlike
previous cryptographic algorithm migrations, the choice of when to
migrate and which algorithms to migrate to, is not so clear.
Cautious implementers may wish to combine cryptographic algorithms
such that an attacker would need to break all of them in order to
compromise the data being protected. Such mechanisms are referred to
as Post-Quantum / Traditional Hybrids
[I-D.driscoll-pqt-hybrid-terminology].
In particular, certain jurisdictions are recommending or requiring
that PQC lattice schemes only be used within a PQ/T hybrid. As an
example, we point to [BSI2021] which 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"
In addition, [BSI2021] specifically references this specification as
a concrete example of hybrid X.509 certificates.
Ounsworth, et al. Expires 3 September 2024 [Page 4]
Internet-Draft Composite KEMs March 2024
A more recent example is [ANSSI2024], a document co-authored by
French Cybersecurity Agency (ANSSI), Federal Office for Information
Security (BSI), Netherlands National Communications Security Agency
(NLNCSA), and Swedish National Communications Security Authority,
Swedish Armed Forces which makes the following statement:
"In light of the urgent need to stop relying only on quantum-
vulnerable public-key cryptography for key establishment, the clear
priority should therefore be the migration to post-quantum
cryptography in hybrid solutions"
This specification represents the straightforward implementation of
the hybrid solutions called for by European cyber security agencies.
PQ/T Hybrid cryptography can, in general, provide solutions to two
migration problems:
* Algorithm strength uncertainty: During the transition period, some
post-quantum signature and encryption algorithms will not be fully
trusted, while also the trust in legacy public key algorithms will
start to erode. A relying party may learn some time after
deployment that a public key algorithm has become untrustworthy,
but in the interim, they may not know which algorithm an adversary
has compromised.
* Ease-of-migration: During the transition period, systems will
require mechanisms that allow for staged migrations from fully
classical to fully post-quantum-aware cryptography.
This document defines a specific instantiation of the PQ/T Hybrid
paradigm called "composite" where multiple cryptographic algorithms
are combined to form a single key encapsulation mechanism (KEM) key
and ciphertext such that they can be treated as a single atomic
algorithm at the protocol level. Composite algorithms address
algorithm strength uncertainty because the composite algorithm
remains strong so long as one of its components remains strong.
Concrete instantiations of composite KEM algorithms are provided
based on ML-KEM, RSA-KEM and ECDH-KEM. Backwards compatibility is
not directly covered in this document, but is the subject of
Appendix B.2.
This document is intended for general applicability anywhere that key
establishment or enveloped content encryption is used within PKIX or
CMS structures.
Ounsworth, et al. Expires 3 September 2024 [Page 5]
Internet-Draft Composite KEMs March 2024
2.1. Terminology
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.
This document is consistent with all terminology from
[I-D.driscoll-pqt-hybrid-terminology]. In addition, the following
terms are used in this document:
*COMBINER:* A combiner specifies how multiple shared secrets are
combined into a single shared secret.
*DER:* Distinguished Encoding Rules as defined in [X.690].
*KEM:* A key encapsulation mechanism as defined in Section 2.3.
*PKI:* Public Key Infrastructure, as defined in [RFC5280].
*SHARED SECRET:* A value established between two communicating
parties for use as cryptographic key material, but which cannot be
learned by an active or passive adversary. This document is
concerned with shared secrets established via public key
cryptographic operations.
2.2. Composite Design Philosophy
[I-D.driscoll-pqt-hybrid-terminology] defines composites as:
_Composite Cryptographic Element_: A cryptographic element that
incorporates multiple component cryptographic elements of the same
type in a multi-algorithm scheme.
Ounsworth, et al. Expires 3 September 2024 [Page 6]
Internet-Draft Composite KEMs March 2024
Composite keys as defined here follow this definition and should be
regarded as a single key that performs a single cryptographic
operation such key generation, signing, verifying, encapsulating, or
decapsulating -- using its internal sequence of component keys as if
they form a single key. This generally means that the complexity of
combining algorithms can and should be handled by the cryptographic
library or cryptographic module, and the single composite public key,
private key, and ciphertext can be carried in existing fields in
protocols such as PKCS#10 [RFC2986], CMP [RFC4210], X.509 [RFC5280],
CMS [RFC5652], and the Trust Anchor Format [RFC5914]. In this way,
composites achieve "protocol backwards-compatibility" in that they
will drop cleanly into any protocol that accepts KEM algorithms
without requiring any modification of the protocol to handle multiple
keys.
2.3. Composite Key Encapsulation Mechanisms (KEMs)
We borrow here the definition of a key encapsulation mechanism (KEM)
from [I-D.ietf-tls-hybrid-design], in which a KEM is a cryptographic
primitive that consists of three algorithms:
* KeyGen() -> (pk, sk): A probabilistic key generation algorithm,
which generates a public key pk and a secret key sk.
* Encaps(pk) -> (ct, ss): A probabilistic encapsulation algorithm,
which takes as input a public key pk and outputs a ciphertext ct
and shared secret ss.
* Decaps(sk, ct) -> ss: A decapsulation algorithm, which takes as
input a secret key sk and ciphertext ct and outputs a shared
secret ss, or in some cases a distinguished error value.
The KEM interface defined above differs from both traditional key
transport mechanism (for example for use with KeyTransRecipientInfo
defined in [RFC5652]), and key agreement (for example for use with
KeyAgreeRecipientInfo defined in [RFC5652]).
The KEM interface was chosen as the interface for a composite key
establishment because it allows for arbitrary combinations of
component algorithm types since both key transport and key agreement
mechanisms can be promoted into KEMs. This specification uses the
Post-Quantum KEM ML-KEM as specified in
[I-D.ietf-lamps-kyber-certificates] and [FIPS.203-ipd]. For
Traditional KEMs, this document relies on the RSA-KEM construction
defined in [I-D.ietf-lamps-rfc5990bis] and the Elliptic Curve DHKEM
defined in [I-D.ounsworth-lamps-cms-dhkem].
Ounsworth, et al. Expires 3 September 2024 [Page 7]
Internet-Draft Composite KEMs March 2024
A composite KEM allows two or more underlying key transport, key
agreement, or KEM algorithms to be combined into a single
cryptographic operation by performing each operation, transformed to
a KEM as outline above, and using a specified combiner function to
combine the two or more component shared secrets into a single shared
secret.
2.3.1. Composite KeyGen
The KeyGen() -> (pk, sk) of a composite KEM algorithm will perform
the KeyGen() of the respective component KEM algorithms and it
produces a composite public key pk as per Section 3.2 and a composite
secret key sk is per Section 3.3.
2.3.2. Composite Encaps
The Encaps(pk) -> (ct, ss) of a composite KEM algorithm is defined
as:
Encaps(pk):
# Split the component public keys
pk1 = pk[0]
pk2 = pk[1]
# Perform the respective component Encaps operations
(ct1, ss1) = ComponentKEM1.Encaps(pk1)
(ct2, ss2) = ComponentKEM2.Encaps(pk2)
# combine
ct = CompositeCiphertextValue(ct1, ct2)
ss = Combiner(ct1, ss1, ct2, ss2, algName)
return (ct, ss)
Figure 1: Composite Encaps(pk)
where Combiner(ct1, ss1, ct2, ss2, fixedInfo) is defined in
Section 4.3 and CompositeCiphertextValue is defined in Section 4.2.
2.3.3. Composite Decaps
The Decaps(sk, ct) -> ss of a composite KEM algorithm is defined as:
Ounsworth, et al. Expires 3 September 2024 [Page 8]
Internet-Draft Composite KEMs March 2024
Decaps(sk, ct):
# Sptil the component ciphertexts
ct1 = ct[0]
ct2 = ct[1]
# Perform the respective component Decaps operations
ss1 = ComponentKEM1.Encaps(sk1, ct1)
ss2 = ComponentKEM2.Encaps(sk2, ct2)
# combine
ss = Combiner(ct1, ss1, ct2, ss2, algName)
return ss
Figure 2: Composite Decaps(sk, ct)
where Combiner(ct1, ss1, ct2, ss2, fixedInfo) is defined in {sec-kem-
combiner}.
2.4. Component Algorithm Selection Criteria
The composite algorithm combinations defined in this document were
chosen according to the following guidelines:
1. RSA combinations are provided at key sizes of 2048 and 3072 bits.
Since RSA 2048 and 3072 are considered to have 112 and 128 bits
of classical security respectively, they are both matched with
NIST PQC Level 1 algorithms and 128-bit symmetric algorithms.
2. Elliptic curve algorithms are provided with combinations on each
of the NIST [RFC6090], Brainpool [RFC5639], and Edwards [RFC7748]
curves. NIST PQC Levels 1 - 3 algorithms are matched with
256-bit curves, while NIST levels 4 - 5 are matched with 384-bit
elliptic curves. This provides a balance between matching
classical security levels of post-quantum and traditional
algorithms, and also selecting elliptic curves which already have
wide adoption.
3. NIST level 1 candidates are provided, matched with 256-bit
elliptic curves, intended for constrained use cases.
If other combinations are needed, a separate specification should be
submitted to the IETF LAMPS working group. To ease implementation,
these specifications are encouraged to follow the construction
pattern of the algorithms specified in this document.
Ounsworth, et al. Expires 3 September 2024 [Page 9]
Internet-Draft Composite KEMs March 2024
The composite structures defined in this specification allow only for
pairs of algorithms. This also does not preclude future
specification from extending these structures to define combinations
with three or more components.
3. Composite Key Structures
3.1. pk-CompositeKEM
The following ASN.1 Information Object Class is a template to be used
in defining all composite KEM public key types.
pk-CompositeKEM {
OBJECT IDENTIFIER:id, FirstPublicKeyType,
SecondPublicKeyType} PUBLIC-KEY ::=
{
IDENTIFIER id
KEY SEQUENCE {
BIT STRING (CONTAINING FirstPublicKeyType)
BIT STRING (CONTAINING SecondPublicKeyType)
}
PARAMS ARE absent
CERT-KEY-USAGE { keyEncipherment }
}
As an example, the public key type pk-MLKEM512-ECDH-P256-KMAC128 is
defined as:
pk-MLKEM512-ECDH-P256-KMAC128 PUBLIC-KEY ::=
pk-CompositeKEM {
id-MLKEM512-ECDH-P256-KMAC128,
OCTET STRING, ECPoint }
The full set of key types defined by this specification can be found
in the ASN.1 Module in Section 8.
3.2. CompositeKEMPublicKey
Composite public key data is represented by the following structure:
CompositeKEMPublicKey ::= SEQUENCE SIZE (2) OF BIT STRING
A composite key MUST contain two component public keys. The order of
the component keys is determined by the definition of the
corresponding algorithm identifier as defined in section Section 6.
Ounsworth, et al. Expires 3 September 2024 [Page 10]
Internet-Draft Composite KEMs March 2024
Some applications may need to reconstruct the SubjectPublicKeyInfo
objects corresponding to each component public key. Table 2 in
Section 6 provides the necessary mapping between composite and their
component algorithms for doing this reconstruction. This also
motivates the design choice of SEQUENCE OF BIT STRING instead of
SEQUENCE OF OCTET STRING; using BIT STRING allows for easier
transcription between CompositeKEMPublicKey and SubjectPublicKeyInfo.
When the CompositeKEMPublicKey must be provided in octet string or
bit string format, the data structure is encoded as specified in
Section 3.4.
3.3. CompositeKEMPrivateKey
Usecases that require an interoperable encoding for composite private
keys, such as when private keys are carried in PKCS #12 [RFC7292],
CMP [RFC4210] or CRMF [RFC4211] MUST use the following structure.
CompositeKEMPrivateKey ::= SEQUENCE SIZE (2) OF OneAsymmetricKey
Each element is a OneAsymmetricKey` [RFC5958] object for a component
private key.
The parameters field MUST be absent.
The order of the component keys is the same as the order defined in
Section 3.2 for the components of CompositeKEMPublicKey.
When a CompositePrivateKey is conveyed inside a OneAsymmetricKey
structure (version 1 of which is also known as PrivateKeyInfo)
[RFC5958], the privateKeyAlgorithm field SHALL be set to the
corresponding composite algorithm identifier defined according to
Section 6, the privateKey field SHALL contain the
CompositeKEMPrivateKey, and the publicKey field MUST NOT be present.
Associated public key material MAY be present in the
CompositeKEMPrivateKey.
In some usecases the private keys that comprise a composite key may
not be represented in a single structure or even be contained in a
single cryptographic module; for example if one component is within
the FIPS boundary of a cryptographic module and the other is not; see
{sec-fips} for more discussion. The establishment of correspondence
between public keys in a CompositeKEMPublicKey and private keys not
represented in a single composite structure is beyond the scope of
this document.
Ounsworth, et al. Expires 3 September 2024 [Page 11]
Internet-Draft Composite KEMs March 2024
3.4. Encoding Rules
Many protocol specifications will require that the composite public
key and composite private key data structures be represented by an
octet string or bit string.
When an octet string is required, the DER encoding of the composite
data structure SHALL be used directly.
CompositeKEMPublicKeyOs ::= OCTET STRING (CONTAINING CompositeKEMPublicKey ENCODED BY der)
When a bit string is required, the octets of the DER encoded
composite data structure SHALL be used as the bits of the bit string,
with the most significant bit of the first octet becoming the first
bit, and so on, ending with the least significant bit of the last
octet becoming the last bit of the bit string.
CompositeKEMPublicKeyBs ::= BIT STRING (CONTAINING CompositeKEMPublicKey ENCODED BY der)
3.5. Key Usage Bits
For protocols such as X.509 [RFC5280] that specify key usage along
with the public key, then the composite public key associated with a
composite KEM algorithm MUST contain only a keyEncipherment key
usage, all other key usages MUST NOT be used. This is because the
composite public key can only be used in situations that are
appropriate for both component algorithms, so even if the classical
component key supports both signing and encryption, the post-quantum
algorithms do not.
4. Composite KEM Structures
4.1. kema-CompositeKEM
The ASN.1 algorithm object for a composite KEM is:
kema-CompositeKEM {
OBJECT IDENTIFIER:id,
PUBLIC-KEY:publicKeyType }
KEM-ALGORITHM ::= {
IDENTIFIER id
VALUE CompositeCiphertextValue
PARAMS ARE absent
PUBLIC-KEYS { publicKeyType }
}
Ounsworth, et al. Expires 3 September 2024 [Page 12]
Internet-Draft Composite KEMs March 2024
4.2. CompositeCiphertextValue
The compositeCipherTextValue is a concatenation of the ciphertexts of
the underlying component algorithms. It is represented in ASN.1 as
follows:
CompositeCiphertextValue ::= SEQUENCE SIZE (2) OF OCTET STRING
A composite KEM and CompositeCipherTextValue MAY be associated with a
composite KEM public key, but MAY also be associated with multiple
public keys from different sources, for example multiple X.509
certificates, or multiple cryptographic modules. In the latter case,
composite KEMs MAY be used as the mechanism for carrying multiple
ciphertexts, for example, in a non-composite hybrid encryption
equivalent of those described for digital signatures in
[I-D.becker-guthrie-noncomposite-hybrid-auth].
4.3. KEM Combiner
TODO: as per https://www.enisa.europa.eu/publications/post-quantum-
cryptography-integration-study section 4.2, might need to specify
behaviour in light of KEMs with a non-zero failure probability.
This document follows the construction of
[I-D.ounsworth-cfrg-kem-combiners], which is repeated here for
clarity and simplified to take two input shared secrets:
Combiner(ct1, ss1, ct2, ss2, fixedInfo) =
KDF(counter || ct1 || ss1 || ct2 || ss2 || fixedInfo, outputBits)
Figure 3: Generic KEM combiner construction
where:
* KDF(message, outputBits) represents a hash function suitable to
the chosen KEMs according to {tab-kem-combiners}.
* fixedInfo SHALL be the ASCII-encoded string name of the composite
KEM algorithm as listed in Table 2.
* counter SHALL be the fixed 32-bit value 0x00000001 which is placed
here solely for the purposes of easy compliance with
[SP.800-56Cr2].
* || represents concatenation.
Each registered composite KEM algorithm must specify the choice of
KDF, fixedInfo, and outputBits to be used.
Ounsworth, et al. Expires 3 September 2024 [Page 13]
Internet-Draft Composite KEMs March 2024
See Section 10.2 for further discussion of the security
considerations of this KEM combiner.
4.3.1. KMAC-KDF
KMAC128-KDF and KMAC256-KDF are KMAC-based KDFs specified for use in
CMS in [I-D.ietf-lamps-cms-sha3-hash]. Here, KMAC# indicates the use
of either KMAC128-KDF or KMAC256-KDF.
KMAC#(K, X, L, S) takes the following parameters:
K: the input key-derivation key. In this document this is the
shared secret outputted from the Encapsulate() or Decapsulate()
functions. This corresponds to the IKM KDF input from Section 5
of [I-D.ietf-lamps-cms-kemri].
X: the context, which is the info KDF input.
L: the output length, in bits.
S: the optional customization label. In this document this
parameter is unused, that is it is the zero-length string "".
The object identifier for KMAC128-KDF is id-kmac128 as defined in
[I-D.ietf-lamps-cms-sha3-hash].
The object identifier for KMAC256-KDF is id-kmac256 as defined in
[I-D.ietf-lamps-cms-sha3-hash].
Since the customization label to KMAC# is not used, the parameter
field MUST be absent when id-kmac128 or id-kmac256 is used as part of
an algorithm identifier specifying the KDF to use for ML-KEM in
KemRecipientInfo.
This specification references KEM combiner instantiations according
to the following names:
+===================+============+============+
| KEM Combiner Name | KDF | outputBits |
+===================+============+============+
| KMAC128/256 | id-kmac128 | 256 |
+-------------------+------------+------------+
| KMAC256/384 | id-kmac256 | 384 |
+-------------------+------------+------------+
| KMAC256/512 | id-kmac256 | 512 |
+-------------------+------------+------------+
Table 1: KEM Combiners
Ounsworth, et al. Expires 3 September 2024 [Page 14]
Internet-Draft Composite KEMs March 2024
BEGIN EDNOTE
these choices are somewhat arbitrary but aiming to match security
level of the input KEMs. Feedback welcome.
* ML-KEM-512: KMAC128/256
* ML-KEM-768: KMAC256/384
* ML-KEM-1024 KMAC256/512
END EDNOTE
5. Example KEM Combiner instantiation
For example, the KEM combiner used with the first entry of Table 2,
id-MLKEM512-ECDH-P256-KMAC128 would be:
Combiner(ct1, ss1, ct2, ss2, "id-MLKEM512-ECDH-P256-KMAC128") =
KMAC128( 0x00000001 || ss_1 || ss_2 ||
"id-MLKEM512-ECDH-P256-KMAC128", 256, "")
6. Algorithm Identifiers
This table summarizes the list of composite KEM algorithms and lists
the OID, two component algorithms, and the combiner function.
EDNOTE: The OID referenced are TBD and MUST be used only for
prototyping and replaced with the final IANA-assigned OIDS. The
following prefix is used for each: replace <CompKEM> with the String
"2.16.840.1.114027.80.5.2".
TODO: OIDs to be replaced by IANA.
Therefore <CompKEM>.1 is equal to 2.16.840.1.114027.80.5.2.1
Ounsworth, et al. Expires 3 September 2024 [Page 15]
Internet-Draft Composite KEMs March 2024
+========================+============+=========+===============+===========+
|Composite KEM OID |OID |First |Second |KEM |
| | |Algorithm|Algorithm |Combiner |
+========================+============+=========+===============+===========+
|id-MLKEM512-ECDH- |<CompKEM>.1 |MLKEM512 |ECDH-P256 |KMAC128/256|
|P256-KMAC128 | | | | |
+------------------------+------------+---------+---------------+-----------+
|id-MLKEM512-ECDH- |<CompKEM>.2 |MLKEM512 |ECDH- |KMAC128/256|
|brainpoolP256r1-KMAC128 | | |brainpoolp256r1| |
+------------------------+------------+---------+---------------+-----------+
|id- |<CompKEM>.3 |MLKEM512 |X25519 |KMAC128/256|
|MLKEM512-X25519-KMAC128 | | | | |
+------------------------+------------+---------+---------------+-----------+
|id- |<CompKEM>.13|MLKEM512 |RSA-KEM 2048 |KMAC128/256|
|MLKEM512-RSA2048-KMAC128| | | | |
+------------------------+------------+---------+---------------+-----------+
|id- |<CompKEM>.4 |MLKEM512 |RSA-KEM 3072 |KMAC128/256|
|MLKEM512-RSA3072-KMAC128| | | | |
+------------------------+------------+---------+---------------+-----------+
|id-MLKEM768-ECDH- |<CompKEM>.5 |MLKEM768 |ECDH-P256 |KMAC256/384|
|P256-KMAC256 | | | | |
+------------------------+------------+---------+---------------+-----------+
|id-MLKEM768-ECDH- |<CompKEM>.6 |MLKEM768 |ECDH- |KMAC256/384|
|brainpoolP256r1-KMAC256 | | |brainpoolp256r1| |
+------------------------+------------+---------+---------------+-----------+
|id- |<CompKEM>.7 |MLKEM768 |X25519 |KMAC256/384|
|MLKEM768-X25519-KMAC256 | | | | |
+------------------------+------------+---------+---------------+-----------+
|id-MLKEM1024-ECDH- |<CompKEM>.8 |MLKEM1024|ECDH-P384 |KMAC256/512|
|P384-KMAC256 | | | | |
+------------------------+------------+---------+---------------+-----------+
|id-MLKEM1024-ECDH- |<CompKEM>.9 |MLKEM1024|ECDH- |KMAC256/512|
|brainpoolP384r1-KMAC256 | | |brainpoolP384r1| |
+------------------------+------------+---------+---------------+-----------+
|id- |<CompKEM>.10|MLKEM1024|X448 |KMAC256/512|
|MLKEM1024-X448-KMAC256 | | | | |
+------------------------+------------+---------+---------------+-----------+
Table 2: Composite KEM key types
The table above contains everything needed to implement the listed
explicit composite algorithms, with the exception of some special
notes found below in this section. See the ASN.1 module in section
Section 8 for the explicit definitions of the above Composite
signature algorithms.
Full specifications for the referenced algorithms can be found as
follows:
Ounsworth, et al. Expires 3 September 2024 [Page 16]
Internet-Draft Composite KEMs March 2024
* _ECDH_: There does not appear to be a single IETF definition of
ECDH, so we refer to the following:
- _ECDH NIST_: SHALL be Elliptic Curve Cryptography Cofactor
Diffie-Hellman (ECC CDH) as defined in section 5.7.1.2 of
[SP.800-56Ar3].
- _ECDH BSI / brainpool_: SHALL be Elliptic Curve Key Agreement
algorithm (ECKA) as defined in section 4.3.1 of [BSI-ECC]
* _ML-KEM_: [I-D.ietf-lamps-kyber-certificates] and [FIPS.203-ipd]
* _RSA-KEM_: [I-D.ietf-lamps-rfc5990bis]
* _X25519 / X448_: [RFC8410]
Note that all ECDH as well as X25519 and X448 algorithms MUST be
promoted into KEMs according to [I-D.ounsworth-lamps-cms-dhkem].
EDNOTE: I believe that [SP.800-56Ar3] and [BSI-ECC] give equivalent
and interoperable algorithms, so maybe this is extraneous detail to
include?
The "KEM Combiner" column refers to the definitions in Section 4.3.
6.1. RSA-KEM Parameters
Use of RSA-KEM [I-D.ietf-lamps-rfc5990bis] within id-
MLKEM512-RSA2048-KMAC128 and id-MLKEM512-RSA3072-KMAC128 requires
additional specification.
The RSA component keys MUST be generated at the 2048-bit and 3072-bit
security level respectively.
As with the other composite KEM algorithms, when id-
MLKEM512-RSA2048-KMAC128 or id-MLKEM512-RSA3072-KMAC128 is used in an
AlgorithmIdentifier, the parameters MUST be absent. The RSA-KEM
SHALL be instantiated with the following parameters:
+=======================+===========================+
| RSA-KEM Parameter | Value |
+=======================+===========================+
| keyDerivationFunction | kda-kdf3 with id-sha3-256 |
+-----------------------+---------------------------+
| keyLength | 128 |
+-----------------------+---------------------------+
Table 3: RSA-KEM 2048 Parameters
Ounsworth, et al. Expires 3 September 2024 [Page 17]
Internet-Draft Composite KEMs March 2024
where:
* kda-kdf3 is defined in [I-D.ietf-lamps-rfc5990bis] which
references it from [ANS-X9.44].
* id-sha3-256 is defined in [I-D.ietf-lamps-cms-sha3-hash] which
references it from [SHA3].
7. Use in CMS
[EDNOTE: The convention in LAMPS is to specify algorithms and their
CMS conventions in separate documents. Here we have presented them
in the same document, but this section has been written so that it
can easily be moved to a standalone document.]
Composite KEM algorithms MAY be employed for one or more recipients
in the CMS enveloped-data content type [RFC5652], the CMS
authenticated-data content type [RFC5652], or the CMS authenticated-
enveloped-data content type [RFC5083]. In each case, the
KEMRecipientInfo [I-D.ietf-lamps-cms-kemri] is used with the chosen
composite KEM Algorithm to securely transfer the content-encryption
key from the originator to the recipient.
7.1. Underlying Components
A CMS implementation that supports a composite KEM algorithm MUST
support at least the following underlying components:
When a particular Composite KEM OID is supported, an implementation
MUST support the corresponding KDF algorithm identifier in Table 4.
When a particular Composite KEM OID is supported, an implementation
MUST support the corresponding key-encryption algorithm identifier in
Table 4.
An implementation MAY also support other key-derivation functions and
other key-encryption algorithms as well.
The following table lists the REQUIRED KDF and key-encryption
algorithms to preserve security and performance characteristics of
each composite algorithm.
Ounsworth, et al. Expires 3 September 2024 [Page 18]
Internet-Draft Composite KEMs March 2024
+===============================+=============+====================+
| Composite KEM OID | KDF | Key Encryption Alg |
+===============================+=============+====================+
| id-MLKEM512-ECDH-P256-KMAC128 | KMAC128/256 | id-aes128-Wrap |
+-------------------------------+-------------+--------------------+
| id-MLKEM512-ECDH- | KMAC128/256 | id-aes128-Wrap |
| brainpoolP256r1-KMAC128 | | |
+-------------------------------+-------------+--------------------+
| id-MLKEM512-X25519-KMAC128 | KMAC128/256 | id-aes128-Wrap |
+-------------------------------+-------------+--------------------+
| id-MLKEM512-RSA2048-KMAC128 | KMAC128/256 | id-aes128-Wrap |
+-------------------------------+-------------+--------------------+
| id-MLKEM512-RSA3072-KMAC128 | KMAC128/256 | id-aes128-Wrap |
+-------------------------------+-------------+--------------------+
| id-MLKEM768-ECDH-P256-KMAC256 | KMAC256/384 | id-aes192-Wrap |
+-------------------------------+-------------+--------------------+
| id-MLKEM768-ECDH- | KMAC256/384 | id-aes192-Wrap |
| brainpoolP256r1-KMAC256 | | |
+-------------------------------+-------------+--------------------+
| id-MLKEM768-X25519-KMAC256 | KMAC256/384 | id-aes192-Wrap |
+-------------------------------+-------------+--------------------+
| id-MLKEM1024-ECDH- | KMAC256/512 | id-aes256-Wrap |
| P384-KMAC256 | | |
+-------------------------------+-------------+--------------------+
| id-MLKEM1024-ECDH- | KMAC256/512 | id-aes256-Wrap |
| brainpoolP384r1-KMAC256 | | |
+-------------------------------+-------------+--------------------+
| id-MLKEM1024-X448-KMAC256 | KMAC256/512 | id-aes256-Wrap |
+-------------------------------+-------------+--------------------+
Table 4: REQUIRED pairings for CMS KDF and WRAP
where:
* KMAC KDF instantiations are defined in Section 4.3.1.
* id-aes*-Wrap are defined in [RFC3394].
Implementers MAY safely substitute stronger KDF and key-encryption
algorithms than those indicated; for example id-alg-hkdf-with-
sha3-512 and id-aes256-Wrap MAY be safely used in place of id-alg-
hkdf-with-sha3-384and id-aes192-Wrap, for example, where SHA3-384 or
AES-192 are not supported.
Ounsworth, et al. Expires 3 September 2024 [Page 19]
Internet-Draft Composite KEMs March 2024
7.2. RecipientInfo Conventions
When a composite KEM Algorithm is employed for a recipient, the
RecipientInfo alternative for that recipient MUST be
OtherRecipientInfo using the KEMRecipientInfo structure
[I-D.ietf-lamps-cms-kemri]. The fields of the KEMRecipientInfo MUST
have the following values:
version is the syntax version number; it MUST be 0.
rid identifies the recipient's certificate or public key.
kem identifies the KEM algorithm; it MUST contain one of the OIDs
listed in Table 2.
kemct is the ciphertext produced for this recipient; it contains the
ct output from Encaps(pk) of the KEM algorithm identified in the kem
parameter.
kdf identifies the key-derivation function (KDF). Note that the KDF
used for CMS RecipientInfo process MAY be different than the KDF used
within the composite KEM Algorithm, which MAY be different than the
KDFs (if any) used within the component KEMs of the composite KEM
Algorithm.
kekLength is the size of the key-encryption key in octets.
ukm is an optional random input to the key-derivation function.
wrap identifies a key-encryption algorithm used to encrypt the keying
material.
encryptedKey is the result of encrypting the keying material with the
key-encryption key. When used with the CMS enveloped-data content
type [RFC5652], the keying material is a content-encryption key.
When used with the CMS authenticated-data content type [RFC5652], the
keying material is a message-authentication key. When used with the
CMS authenticated-enveloped-data content type [RFC5083], the keying
material is a content-authenticated-encryption key.
7.3. Certificate Conventions
The conventions specified in this section augment RFC 5280 [RFC5280].
The willingness to accept a composite KEM Algorithm MAY be signaled
by the use of the SMIMECapabilities Attribute as specified in
Section 2.5.2. of [RFC8551] or the SMIMECapabilities certificate
extension as specified in [RFC4262].
Ounsworth, et al. Expires 3 September 2024 [Page 20]
Internet-Draft Composite KEMs March 2024
The intended application for the public key MAY be indicated in the
key usage certificate extension as specified in Section 4.2.1.3 of
[RFC5280]. If the keyUsage extension is present in a certificate
that conveys a composite KEM public key, then the key usage extension
MUST contain only the following value:
keyEncipherment
The digitalSignature and dataEncipherment values MUST NOT be present.
That is, a public key intended to be employed only with a composite
KEM algorithm MUST NOT also be employed for data encryption or for
digital signatures. This requirement does not carry any particular
security consideration; only the convention that KEM keys be
identified with the keyEncipherment key usage.
7.4. SMIMECapabilities Attribute Conventions
Section 2.5.2 of [RFC8551] defines the SMIMECapabilities attribute to
announce a partial list of algorithms that an S/MIME implementation
can support. When constructing a CMS signed-data content type
[RFC5652], a compliant implementation MAY include the
SMIMECapabilities attribute that announces support for the RSA-KEM
Algorithm.
The SMIMECapability SEQUENCE representing a composite KEM Algorithm
MUST include the appropriate object identifier as per Table 2 in the
capabilityID field.
8. ASN.1 Module
<CODE STARTS>
Composite-KEM-2023
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-composite-kems(TBDMOD) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL;
IMPORTS
PUBLIC-KEY, AlgorithmIdentifier{}
FROM AlgorithmInformation-2009 -- RFC 5912 [X509ASN1]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
Ounsworth, et al. Expires 3 September 2024 [Page 21]
Internet-Draft Composite KEMs March 2024
KEM-ALGORITHM, KEMAlgSet
FROM KEMAlgorithmInformation-2023
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-kemAlgorithmInformation-2023(99) }
SubjectPublicKeyInfo
FROM PKIX1Explicit-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51) }
OneAsymmetricKey
FROM AsymmetricKeyPackageModuleV1
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0)
id-mod-asymmetricKeyPkgV1(50) }
RSAPublicKey, ECPoint
FROM PKIXAlgs-2009
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-algorithms2008-02(56) }
;
--
-- Object Identifiers
--
-- Defined in ITU-T X.690
der OBJECT IDENTIFIER ::=
{joint-iso-itu-t asn1(1) ber-derived(2) distinguished-encoding(1)}
--
-- Composite KEM basic structures
--
CompositeKEMPublicKey ::= SEQUENCE SIZE (2) OF BIT STRING
CompositeKEMPublicKeyOs ::= OCTET STRING (CONTAINING
CompositeKEMPublicKey ENCODED BY der)
CompositeKEMPublicKeyBs ::= BIT STRING (CONTAINING
CompositeKEMPublicKey ENCODED BY der)
Ounsworth, et al. Expires 3 September 2024 [Page 22]
Internet-Draft Composite KEMs March 2024
CompositeKEMPrivateKey ::= SEQUENCE SIZE (2) OF OneAsymmetricKey
CompositeCiphertextValue ::= SEQUENCE SIZE (2) OF OCTET STRING
--
-- Information Object Classes
--
pk-CompositeKEM {
OBJECT IDENTIFIER:id, FirstPublicKeyType,
SecondPublicKeyType} PUBLIC-KEY ::=
{
IDENTIFIER id
KEY SEQUENCE {
BIT STRING (CONTAINING FirstPublicKeyType)
BIT STRING (CONTAINING SecondPublicKeyType)
}
PARAMS ARE absent
CERT-KEY-USAGE { keyEncipherment }
}
kema-CompositeKEM {
OBJECT IDENTIFIER:id,
PUBLIC-KEY:publicKeyType }
KEM-ALGORITHM ::= {
IDENTIFIER id
VALUE CompositeCiphertextValue
PARAMS ARE absent
PUBLIC-KEYS { publicKeyType }
SMIME-CAPS { IDENTIFIED BY id }
}
--
-- Composite KEM Algorithms
--
-- TODO: OID to be replaced by IANA
id-MLKEM512-ECDH-P256-KMAC128 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
entrust(114027) algorithm(80) explicitcomposite(5) kem(2) 1 }
pk-MLKEM512-ECDH-P256-KMAC128 PUBLIC-KEY ::=
pk-CompositeKEM {
id-MLKEM512-ECDH-P256-KMAC128,
Ounsworth, et al. Expires 3 September 2024 [Page 23]
Internet-Draft Composite KEMs March 2024
OCTET STRING, ECPoint }
kema-MLKEM512-ECDH-P256-KMAC128 KEM-ALGORITHM ::=
kema-CompositeKEM{
id-MLKEM512-ECDH-P256-KMAC128,
pk-MLKEM512-ECDH-P256-KMAC128 }
-- TODO: OID to be replaced by IANA
id-MLKEM512-ECDH-brainpoolP256r1-KMAC128 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
entrust(114027) algorithm(80) explicitcomposite(5) kem(2) 2 }
pk-MLKEM512-ECDH-brainpoolP256r1-KMAC128 PUBLIC-KEY ::=
pk-CompositeKEM {
id-MLKEM512-ECDH-brainpoolP256r1-KMAC128,
OCTET STRING, ECPoint }
kema-MLKEM512-ECDH-brainpoolP256r1-KMAC128 KEM-ALGORITHM ::=
kema-CompositeKEM{
id-MLKEM512-ECDH-brainpoolP256r1-KMAC128,
pk-MLKEM512-ECDH-brainpoolP256r1-KMAC128 }
-- TODO: OID to be replaced by IANA
id-MLKEM512-X25519-KMAC128 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
entrust(114027) algorithm(80) explicitcomposite(5) kem(2) 3 }
pk-MLKEM512-X25519-KMAC128 PUBLIC-KEY ::=
pk-CompositeKEM {
id-MLKEM512-X25519-KMAC128,
OCTET STRING, OCTET STRING }
kema-MLKEM512-X25519-KMAC128 KEM-ALGORITHM ::=
kema-CompositeKEM{
id-MLKEM512-X25519-KMAC128,
pk-MLKEM512-X25519-KMAC128 }
-- TODO: OID to be replaced by IANA
id-MLKEM512-RSA2048-KMAC128 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
entrust(114027) algorithm(80) explicitcomposite(5) kem(2) 13 }
pk-MLKEM512-RSA2048-KMAC128 PUBLIC-KEY ::=
Ounsworth, et al. Expires 3 September 2024 [Page 24]
Internet-Draft Composite KEMs March 2024
pk-CompositeKEM {
id-MLKEM512-RSA2048-KMAC128,
OCTET STRING, RSAPublicKey }
kema-MLKEM512-RSA2048-KMAC128 KEM-ALGORITHM ::=
kema-CompositeKEM{
id-MLKEM512-RSA2048-KMAC128,
pk-MLKEM512-RSA2048-KMAC128 }
-- TODO: OID to be replaced by IANA
id-MLKEM512-RSA3072-KMAC128 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
entrust(114027) algorithm(80) explicitcomposite(5) kem(2) 4 }
pk-MLKEM512-RSA3072-KMAC128 PUBLIC-KEY ::=
pk-CompositeKEM {
id-MLKEM512-RSA3072-KMAC128,
OCTET STRING, RSAPublicKey }
kema-MLKEM512-RSA3072-KMAC128 KEM-ALGORITHM ::=
kema-CompositeKEM{
id-MLKEM512-RSA3072-KMAC128,
pk-MLKEM512-RSA3072-KMAC128 }
-- TODO: OID to be replaced by IANA
id-MLKEM768-ECDH-P256-KMAC256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
entrust(114027) algorithm(80) explicitcomposite(5) kem(2) 5 }
pk-MLKEM768-ECDH-P256-KMAC256 PUBLIC-KEY ::=
pk-CompositeKEM {
id-MLKEM768-ECDH-P256-KMAC256,
OCTET STRING, ECPoint }
kema-MLKEM768-ECDH-P256-KMAC256 KEM-ALGORITHM ::=
kema-CompositeKEM{
id-MLKEM768-ECDH-P256-KMAC256,
pk-MLKEM768-ECDH-P256-KMAC256 }
-- TODO: OID to be replaced by IANA
id-MLKEM768-ECDH-brainpoolP256r1-KMAC256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
entrust(114027) algorithm(80) explicitcomposite(5) kem(2) 6 }
Ounsworth, et al. Expires 3 September 2024 [Page 25]
Internet-Draft Composite KEMs March 2024
pk-MLKEM768-ECDH-brainpoolP256r1-KMAC256 PUBLIC-KEY ::=
pk-CompositeKEM {
id-MLKEM768-ECDH-brainpoolP256r1-KMAC256,
OCTET STRING, ECPoint }
kema-MLKEM768-ECDH-brainpoolP256r1-KMAC256 KEM-ALGORITHM ::=
kema-CompositeKEM{
id-MLKEM768-ECDH-brainpoolP256r1-KMAC256,
pk-MLKEM768-ECDH-brainpoolP256r1-KMAC256 }
-- TODO: OID to be replaced by IANA
id-MLKEM768-X25519-KMAC256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
entrust(114027) algorithm(80) explicitcomposite(5) kem(2) 7 }
pk-MLKEM768-X25519-KMAC256 PUBLIC-KEY ::=
pk-CompositeKEM {
id-MLKEM768-X25519-KMAC256,
OCTET STRING, OCTET STRING }
kema-MLKEM768-X25519-KMAC256 KEM-ALGORITHM ::=
kema-CompositeKEM{
id-MLKEM768-X25519-KMAC256,
pk-MLKEM768-X25519-KMAC256 }
-- TODO: OID to be replaced by IANA
id-MLKEM1024-ECDH-P384-KMAC256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
entrust(114027) algorithm(80) explicitcomposite(5) kem(2) 8 }
pk-MLKEM1024-ECDH-P384-KMAC256 PUBLIC-KEY ::=
pk-CompositeKEM {
id-MLKEM1024-ECDH-P384-KMAC256,
OCTET STRING, ECPoint }
kema-MLKEM1024-ECDH-P384-KMAC256 KEM-ALGORITHM ::=
kema-CompositeKEM{
id-MLKEM1024-ECDH-P384-KMAC256,
pk-MLKEM1024-ECDH-P384-KMAC256 }
-- TODO: OID to be replaced by IANA
id-MLKEM1024-ECDH-brainpoolP384r1-KMAC256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
entrust(114027) algorithm(80) explicitcomposite(5) kem(2) 9 }
Ounsworth, et al. Expires 3 September 2024 [Page 26]
Internet-Draft Composite KEMs March 2024
pk-MLKEM1024-ECDH-brainpoolP384r1-KMAC256 PUBLIC-KEY ::=
pk-CompositeKEM{
id-MLKEM1024-ECDH-brainpoolP384r1-KMAC256,
OCTET STRING, ECPoint }
kema-MLKEM1024-ECDH-brainpoolP384r1-KMAC256 KEM-ALGORITHM ::=
kema-CompositeKEM{
id-MLKEM1024-ECDH-brainpoolP384r1-KMAC256,
pk-MLKEM1024-ECDH-brainpoolP384r1-KMAC256 }
-- TODO: OID to be replaced by IANA
id-MLKEM1024-X448-KMAC256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
entrust(114027) algorithm(80) explicitcomposite(5) kem(2) 10 }
pk-MLKEM1024-X448-KMAC256 PUBLIC-KEY ::=
pk-CompositeKEM {
id-MLKEM1024-X448-KMAC256,
OCTET STRING, OCTET STRING }
kema-MLKEM1024-X448-KMAC256 KEM-ALGORITHM ::=
kema-CompositeKEM{
id-MLKEM1024-X448-KMAC256,
pk-MLKEM1024-X448-KMAC256 }
--
-- Expand the S/MIME capabilities set used by CMS [RFC5911]
--
SMimeCaps SMIME-CAPS ::=
{ kema-MLKEM512-ECDH-P256-KMAC128.&smimeCaps |
kema-MLKEM512-ECDH-brainpoolP256r1-KMAC128.&smimeCaps |
kema-MLKEM512-X25519-KMAC128.&smimeCaps |
kema-MLKEM512-RSA2048-KMAC128.&smimeCaps |
kema-MLKEM512-RSA3072-KMAC128.&smimeCaps |
kema-MLKEM768-ECDH-P256-KMAC256.&smimeCaps |
kema-MLKEM768-ECDH-brainpoolP256r1-KMAC256.&smimeCaps |
kema-MLKEM768-X25519-KMAC256.&smimeCaps |
kema-MLKEM1024-ECDH-P384-KMAC256.&smimeCaps |
kema-MLKEM1024-ECDH-brainpoolP384r1-KMAC256.&smimeCaps |
kema-MLKEM1024-X448-KMAC256.&smimeCaps,
... }
END
<CODE ENDS>
Ounsworth, et al. Expires 3 September 2024 [Page 27]
Internet-Draft Composite KEMs March 2024
9. IANA Considerations
9.1. Object Identifier Allocations
EDNOTE to IANA: OIDs will need to be replaced in both the ASN.1
module and in Table 2.
9.1.1. Module Registration - SMI Security for PKIX Module Identifier
* Decimal: IANA Assigned - *Replace TBDMOD*
* Description: Composite-KEM-2023 - id-mod-composite-kems
* References: This Document
9.1.2. Object Identifier Registrations - SMI Security for PKIX
Algorithms
* id-MLKEM512-ECDH-P256-KMAC128
- Decimal: IANA Assigned
- Description: id-MLKEM512-ECDH-P256-KMAC128
- References: This Document
* id-MLKEM512-ECDH-brainpoolP256r1-KMAC128
- Decimal: IANA Assigned
- Description: id-MLKEM512-ECDH-brainpoolP256r1-KMAC128
- References: This Document
* id-MLKEM512-X25519-KMAC128
- Decimal: IANA Assigned
- Description: id-MLKEM512-X25519-KMAC128
- References: This Document
* id-MLKEM768-RSA3072-KMAC256
- Decimal: IANA Assigned
- Description: id-MLKEM768-3072-KMAC256
Ounsworth, et al. Expires 3 September 2024 [Page 28]
Internet-Draft Composite KEMs March 2024
- References: This Document
* id-MLKEM768-ECDH-P256-KMAC256
- Decimal: IANA Assigned
- Description: id-MLKEM768-ECDH-P256-KMAC256
- References: This Document
* id-MLKEM768-ECDH-brainpoolP256r1-KMAC256
- Decimal: IANA Assigned
- Description: id-MLKEM768-ECDH-brainpoolP256r1-KMAC256
- References: This Document
* id-MLKEM768-X25519-KMAC256
- Decimal: IANA Assigned
- Description: id-MLKEM768-X25519-KMAC256
- References: This Document
* id-MLKEM1024-ECDH-P384-KMAC256
- Decimal: IANA Assigned
- Description: id-MLKEM1024-ECDH-P384-KMAC256
- References: This Document
* id-MLKEM1024-ECDH-brainpoolP384r1-KMAC256
- Decimal: IANA Assigned
- Description: id-MLKEM1024-ECDH-brainpoolP384r1-KMAC256
- References: This Document
* id-MLKEM1024-X448-KMAC256
- Decimal: IANA Assigned
- Description: id-MLKEM1024-X448-KMAC256
Ounsworth, et al. Expires 3 September 2024 [Page 29]
Internet-Draft Composite KEMs March 2024
- References: This Document
10. Security Considerations
10.1. Policy for Deprecated and Acceptable Algorithms
Traditionally, a public key or certificate contains a single
cryptographic algorithm. If and when an algorithm becomes deprecated
(for example, RSA-512, or SHA1), it is obvious that the public keys
or certificates using that algorithm are to be considered revoked.
In the composite model this is less obvious since implementers may
decide that certain cryptographic algorithms have complementary
security properties and are acceptable in combination even though one
or both algorithms are deprecated for individual use. As such, a
single composite public key or certificate may contain a mixture of
deprecated and non-deprecated algorithms.
Since composite algorithms are registered independently of their
component algorithms, their deprecation can be handled independently
from that of their component algorithms. For example a cryptographic
policy might continue to allow id-MLKEM512-ECDH-P256-KMAC128 even
after ECDH-P256 is deprecated.
The composite KEM design specified in this document, and especially
that of the KEM combiner specified in Section 4.3 means that the
overall composite KEM algorithm should be considered to have the
security strength of the strongest of its component algorithms; ie as
long as one component algorithm remains strong, then the overall
composite algorithm remains strong.
10.2. KEM Combiner
This document uses directly the KEM Combiner defined in
[I-D.ounsworth-cfrg-kem-combiners] and therefore IND-CCA2 of any of
its ingredient KEMs, i.e. the newly formed combined KEM is IND-CCA2
secure as long as at least one of the ingredient KEMs is
[I-D.ounsworth-cfrg-kem-combiners] provides two different
constructions depending on the properties of the component KEMs:
If both the secret share ss_i and the ciphertext ct_i are constant
length, then k_i MAY be constructed concatenating the two values.
If ss_i or ct_i are not guaranteed to have constant length, it is
REQUIRED to append the rlen encoded length when concatenating,
prior to inclusion in the overall construction.
Ounsworth, et al. Expires 3 September 2024 [Page 30]
Internet-Draft Composite KEMs March 2024
The component KEMs used in this specification are RSA-KEM
[I-D.ietf-lamps-rfc5990bis], ECDH KEM [I-D.ounsworth-lamps-cms-dhkem]
and ML-KEM [FIPS.203-ipd] all of which meet the criteria of having
constant-length shared secrets and ciphertexts and therefore we
justify using the simpler construction that omits the length tag.
11. References
11.1. Normative References
[ANS-X9.44]
American National Standards Institute, "Public Key
Cryptography for the Financial Services Industry -- Key
Establishment Using Integer Factorization Cryptography",
American National Standard X9.44 , 2007.
[BSI-ECC] Federal Office for Information Security (BSI), "Technical
Guideline BSI TR-03111: Elliptic Curve Cryptography.
Version 2.10", 1 June 2018.
[FIPS.203-ipd]
National Institute of Standards and Technology (NIST),
"Module-Lattice-based Key-Encapsulation Mechanism
Standard", August 2023,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.203.ipd.pdf>.
[I-D.ietf-lamps-cms-kemri]
Housley, R., Gray, J., and T. Okubo, "Using Key
Encapsulation Mechanism (KEM) Algorithms in the
Cryptographic Message Syntax (CMS)", Work in Progress,
Internet-Draft, draft-ietf-lamps-cms-kemri-08, 6 February
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
lamps-cms-kemri-08>.
[I-D.ietf-lamps-cms-sha3-hash]
Housley, R., "Use of the SHA3 One-way Hash Functions in
the Cryptographic Message Syntax (CMS)", Work in Progress,
Internet-Draft, draft-ietf-lamps-cms-sha3-hash-01, 1 March
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
lamps-cms-sha3-hash-01>.
[I-D.ietf-lamps-rfc5990bis]
Housley, R. and S. Turner, "Use of the RSA-KEM Algorithm
in the Cryptographic Message Syntax (CMS)", Work in
Progress, Internet-Draft, draft-ietf-lamps-rfc5990bis-01,
12 September 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-rfc5990bis-01>.
Ounsworth, et al. Expires 3 September 2024 [Page 31]
Internet-Draft Composite KEMs March 2024
[I-D.ounsworth-lamps-cms-dhkem]
Ounsworth, M., Gray, J., and R. Housley, "Use of the DH-
Based KEM (DHKEM) in the Cryptographic Message Syntax
(CMS)", Work in Progress, Internet-Draft, draft-ounsworth-
lamps-cms-dhkem-00, 24 August 2023,
<https://datatracker.ietf.org/doc/html/draft-ounsworth-
lamps-cms-dhkem-00>.
[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/info/rfc2119>.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
September 2002, <https://www.rfc-editor.org/info/rfc3394>.
[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/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
DOI 10.17487/RFC5958, August 2010,
<https://www.rfc-editor.org/info/rfc5958>.
[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/info/rfc8174>.
[RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for
Ed25519, Ed448, X25519, and X448 for Use in the Internet
X.509 Public Key Infrastructure", RFC 8410,
DOI 10.17487/RFC8410, August 2018,
<https://www.rfc-editor.org/info/rfc8410>.
[RFC8411] Schaad, J. and R. Andrews, "IANA Registration for the
Cryptographic Algorithm Object Identifier Range",
RFC 8411, DOI 10.17487/RFC8411, August 2018,
<https://www.rfc-editor.org/info/rfc8411>.
Ounsworth, et al. Expires 3 September 2024 [Page 32]
Internet-Draft Composite KEMs March 2024
[SHA3] National Institute of Standards and Technology (NIST),
"SHA-3 Standard: Permutation-Based Hash and Extendable-
Output Functions, FIPS PUB 202, DOI 10.6028/
NIST.FIPS.202", August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.202.pdf>.
[SP.800-56Ar3]
National Institute of Standards and Technology (NIST),
"Recommendation for Pair-Wise Key-Establishment Schemes
Using Discrete Logarithm Cryptography", April 2018,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Ar3.pdf>.
[SP.800-56Cr2]
National Institute of Standards and Technology (NIST),
"Recommendation for Key-Derivation Methods in Key-
Establishment Schemes", August 2020,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Cr2.pdf>.
[SP800-185]
National Institute of Standards and Technology (NIST),
"SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and
ParallelHash", December 2016,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-185.pdf>.
[X.690] ITU-T, "Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ISO/IEC 8825-1:2015, November 2015.
11.2. Informative References
[ANSSI2024]
French Cybersecurity Agency (ANSSI), Federal Office for
Information Security (BSI), Netherlands National
Communications Security Agency (NLNCSA), and Swedish
National Communications Security Authority, Swedish Armed
Forces, "Position Paper on Quantum Key Distribution",
n.d., <https://cyber.gouv.fr/sites/default/files/document/
Quantum_Key_Distribution_Position_Paper.pdf>.
Ounsworth, et al. Expires 3 September 2024 [Page 33]
Internet-Draft Composite KEMs March 2024
[BSI2021] Federal Office for Information Security (BSI), "Quantum-
safe cryptography - fundamentals, current developments and
recommendations", October 2021,
<https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/
Publications/Brochure/quantum-safe-cryptography.pdf>.
[I-D.becker-guthrie-noncomposite-hybrid-auth]
Becker, A., Guthrie, R., and M. J. Jenkins, "Non-Composite
Hybrid Authentication in PKIX and Applications to Internet
Protocols", Work in Progress, Internet-Draft, draft-
becker-guthrie-noncomposite-hybrid-auth-00, 22 March 2022,
<https://datatracker.ietf.org/doc/html/draft-becker-
guthrie-noncomposite-hybrid-auth-00>.
[I-D.driscoll-pqt-hybrid-terminology]
D, F., "Terminology for Post-Quantum Traditional Hybrid
Schemes", Work in Progress, Internet-Draft, draft-
driscoll-pqt-hybrid-terminology-01, 20 October 2022,
<https://datatracker.ietf.org/doc/html/draft-driscoll-pqt-
hybrid-terminology-01>.
[I-D.housley-lamps-cms-kemri]
Housley, R., Gray, J., and T. Okubo, "Using Key
Encapsulation Mechanism (KEM) Algorithms in the
Cryptographic Message Syntax (CMS)", Work in Progress,
Internet-Draft, draft-housley-lamps-cms-kemri-02, 20
February 2023, <https://datatracker.ietf.org/doc/html/
draft-housley-lamps-cms-kemri-02>.
[I-D.ietf-lamps-kyber-certificates]
Turner, S., Kampanakis, P., Massimo, J., and B.
Westerbaan, "Internet X.509 Public Key Infrastructure -
Algorithm Identifiers for Kyber", Work in Progress,
Internet-Draft, draft-ietf-lamps-kyber-certificates-01, 28
March 2023, <https://datatracker.ietf.org/doc/html/draft-
ietf-lamps-kyber-certificates-01>.
[I-D.ietf-tls-hybrid-design]
Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key
exchange in TLS 1.3", Work in Progress, Internet-Draft,
draft-ietf-tls-hybrid-design-04, 11 January 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
hybrid-design-04>.
[I-D.ounsworth-cfrg-kem-combiners]
Ounsworth, M., Wussler, A., and S. Kousidis, "Combiner
function for hybrid key encapsulation mechanisms (Hybrid
KEMs)", Work in Progress, Internet-Draft, draft-ounsworth-
Ounsworth, et al. Expires 3 September 2024 [Page 34]
Internet-Draft Composite KEMs March 2024
cfrg-kem-combiners-04, 8 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ounsworth-
cfrg-kem-combiners-04>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210,
DOI 10.17487/RFC4210, September 2005,
<https://www.rfc-editor.org/info/rfc4210>.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211,
DOI 10.17487/RFC4211, September 2005,
<https://www.rfc-editor.org/info/rfc4211>.
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type", RFC 5083,
DOI 10.17487/RFC5083, November 2007,
<https://www.rfc-editor.org/info/rfc5083>.
[RFC5639] Lochter, M. and J. Merkle, "Elliptic Curve Cryptography
(ECC) Brainpool Standard Curves and Curve Generation",
RFC 5639, DOI 10.17487/RFC5639, March 2010,
<https://www.rfc-editor.org/info/rfc5639>.
[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
Format", RFC 5914, DOI 10.17487/RFC5914, June 2010,
<https://www.rfc-editor.org/info/rfc5914>.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090,
DOI 10.17487/RFC6090, February 2011,
<https://www.rfc-editor.org/info/rfc6090>.
[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,
and M. Scott, "PKCS #12: Personal Information Exchange
Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014,
<https://www.rfc-editor.org/info/rfc7292>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
Ounsworth, et al. Expires 3 September 2024 [Page 35]
Internet-Draft Composite KEMs March 2024
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
[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/info/rfc8446>.
[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/info/rfc8551>.
Appendix A. Samples
TBD
Appendix B. Implementation Considerations
B.1. FIPS certification
One of the primary design goals of this specification is for the
overall composite algorithm to be able to be considered FIPS-approved
even when one of the component algorithms is not. The combiner
presented in Section 4.3 was chosen to align with [SP.800-56Cr2] for
this reason.
Implementers seeking FIPS certification of a composite KEM algorithm
where only one of the component algorithms has been FIPS-validated or
FIPS-approved should credit the FIPS-validated component algorithm
with full security strength, the non-FIPS-validated component
algorithm with zero security, and the overall composite should be
considered full strength and thus FIPS-approved.
The authors wish to note that this gives composite algorithms great
future utility both for future cryptographic migrations as well as
bridging across jurisdictions; for example defining composite
algorithms which combine FIPS cryptography with cryptography from a
different national standards body.
B.2. Backwards Compatibility
As noted in the introduction, the post-quantum cryptographic
migration will face challenges in both ensuring cryptographic
strength against adversaries of unknown capabilities, as well as
providing ease of migration. The composite mechanisms defined in
this document primarily address cryptographic strength, however this
section contains notes on how backwards compatibility may be
Ounsworth, et al. Expires 3 September 2024 [Page 36]
Internet-Draft Composite KEMs March 2024
obtained.
The term "ease of migration" is used here to mean that existing
systems can be gracefully transitioned to the new technology without
requiring large service disruptions or expensive upgrades. The term
"backwards compatibility" is used here to mean something more
specific; that existing systems as they are deployed today can
interoperate with the upgraded systems of the future.
These migration and interoperability concerns need to be thought
about in the context of various types of protocols that make use of
X.509 and PKIX with relation to key establishment and content
encryption, from online negotiated protocols such as TLS 1.3
[RFC8446] and IKEv2 [RFC7296], to non-negotiated asynchronous
protocols such as S/MIME signed email [RFC8551], as well as myriad
other standardized and proprietary protocols and applications that
leverage CMS [RFC5652] encrypted structures.
B.2.1. Parallel PKIs
EDNOTE: remove this section?
We present the term "Parallel PKI" to refer to the setup where a PKI
end entity possesses two or more distinct public keys or certificates
for the same identity (name), but containing keys for different
cryptographic algorithms. One could imagine a set of parallel PKIs
where an existing PKI using legacy algorithms (RSA, ECC) is left
operational during the post-quantum migration but is shadowed by one
or more parallel PKIs using pure post quantum algorithms or composite
algorithms (legacy and post-quantum).
Equipped with a set of parallel public keys in this way, a client
would have the flexibility to choose which public key(s) or
certificate(s) to use in a given signature operation.
For negotiated protocols, the client could choose which public key(s)
or certificate(s) to use based on the negotiated algorithms.
For non-negotiated protocols, the details for obtaining backwards
compatibility will vary by protocol, but for example in CMS
[RFC5652].
EDNOTE: I copied and pruned this text from I-D.ounsworth-pq-
composite-sigs. It probably needs to be fleshed out more as we
better understand the implementation concerns around composite
encryption.
Ounsworth, et al. Expires 3 September 2024 [Page 37]
Internet-Draft Composite KEMs March 2024
Appendix C. Intellectual Property Considerations
The following IPR Disclosure relates to this draft:
https://datatracker.ietf.org/ipr/3588/
EDNOTE TODO: Check with Max Pala whether this IPR actually applies to
this draft.
Appendix D. Contributors and Acknowledgments
This document incorporates contributions and comments from a large
group of experts. The Editors would especially like to acknowledge
the expertise and tireless dedication of the following people, who
attended many long meetings and generated millions of bytes of
electronic mail and VOIP traffic over the past year in pursuit of
this document:
Serge Mister (Entrust), Ali Noman (Entrust), and Douglas Stebila
(University of Waterloo).
We are grateful to all, including any contributors who may have been
inadvertently omitted from this list.
This document borrows text from similar documents, including those
referenced below. Thanks go to the authors of those documents.
"Copying always makes things easier and less error prone" -
[RFC8411].
Authors' Addresses
Mike Ounsworth
Entrust Limited
2500 Solandt Road -- Suite 100
Ottawa, Ontario K2K 3G5
Canada
Email: mike.ounsworth@entrust.com
John Gray
Entrust Limited
2500 Solandt Road -- Suite 100
Ottawa, Ontario K2K 3G5
Canada
Email: john.gray@entrust.com
Ounsworth, et al. Expires 3 September 2024 [Page 38]
Internet-Draft Composite KEMs March 2024
Massimiliano Pala
OpenCA Labs
858 Coal Creek Cir
Louisville, Colorado, 80027
United States of America
Email: director@openca.org
Jan Klaussner
D-Trust GmbH
Kommandantenstr. 15
10969 Berlin
Germany
Email: jan.klaussner@d-trust.net
Scott Fluhrer
Cisco Systems
Email: sfluhrer@cisco.com
Ounsworth, et al. Expires 3 September 2024 [Page 39]