| Internet-Draft | PQ Composite Keys | March 2023 |
| Ounsworth, et al. | Expires 14 September 2023 | [Page] |
The migration to post-quantum cryptography is unique in the history of modern digital cryptography in that neither the old outgoing nor the new incoming algorithms are fully trusted to protect data for the required data lifetimes. The outgoing algorithms, such as RSA and elliptic curve, may fall to quantum cryptalanysis, while the incoming post-quantum algorithms face uncertainty about both the underlying mathematics as well as hardware and software implementations that have not had sufficient maturing time to rule out classical cryptanalytic attacks and implementation bugs.¶
Cautious implementers may wish to layer cryptographic algorithms such that an attacker would need to break all of them in order to compromise the data being protected using either a Post-Quantum / Traditional Hybrid, Post-Quantum / Post-Quantum Hybrid, or combinations thereof. This document, and its companions, defines a specific instantiation of hybrid paradigm called "composite" where multiple cryptographic algorithms are combined to form a single key, signature, or key encapsulation mechanism (KEM) such that they can be treated as a single atomic object at the protocol level.¶
This document defines the structures CompositePublicKey and CompositePrivateKey, which are sequences of the respective structure for each component algorithm. Explicit pairings of algorithms are defined which should meet most Internet needs. The generic composite key type is also defined which allows arbitrary combinations of key types to be placed in the CompositePublicKey and CompositePrivateKey structures without needing the combination to be pre-registered or pre-agreed.¶
This document is intended to be coupled with corresponding documents that define the structure and semantics of composite signatures and encryption, such as [I-D.ounsworth-pq-composite-sigs] and [I-D.ounsworth-pq-composite-kem].¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-keys/.¶
Discussion of this document takes place on the Limited Additional Mechanisms for PKIX and SMIME (lamps) Working Group mailing list (mailto:spasm@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at https://www.ietf.org/mailman/listinfo/spasm/.¶
Source for this draft and an issue tracker can be found at https://github.com/EntrustCorporation/draft-ounsworth-pq-composite-keys.¶
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 14 September 2023.¶
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.¶
The following algorithms were removed:¶
The following algorithms were added:¶
During the transition to post-quantum cryptography (PQ or PQC), 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 may also not fully trust their post-quantum replacements until further time has passed to allow additional scrutiny and the discovery of 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 by using a Post-Quantum/Traditional (PQ/T) or Post-Quantum/Post-Quantum (PQ/PQ) Hybrid scheme.¶
The transition to PQC will face two challenges:¶
This document provides the composite mechanism, which is a specific instantiation of the PQ/T hybrid paradigm to address algorithm strength uncertainty concerns by providing formats for encoding multiple public key and private key values into existing public key and private key fields. Backwards compatibility is not directly addressed via the composite mechanisms defined in the document, but some notes on how it can be obtained can be found in Appendix C.2.¶
This document only specifies key formats; usage of these keys are covered in the corresponding composite signatures [I-D.ounsworth-pq-composite-sigs] and composite KEM [I-D.ounsworth-pq-composite-kem] specifications.¶
This document is intended for general applicability anywhere that keys are used within PKIX or CMS structures.¶
The composite algorithm combinations defined in this document were chosen according to the following guidelines:¶
The authors wish to note that although all the composite structures defined in this and the companion composite signatures [I-D.ounsworth-pq-composite-sigs] and composite KEM [I-D.ounsworth-pq-composite-kem] specifications are defined in such a way as to easily allow 3 or more component algorithms, it was decided to only specify explicit pairs. The generic composite specified in this document allows for an arbitrary number of components. This also does not preclude future specification of explicit combinations with three or more components.¶
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 BCP14 [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:¶
BER: Basic Encoding Rules (BER) as defined in [X.690].¶
CLIENT: Any software that is making use of a cryptographic key. This includes a signer, verifier, encrypter, decrypter.¶
In order to represent public keys and private keys that are composed of multiple algorithms, we define encodings consisting of a sequence of public key or private key primitives (aka "components") such that these structures can be used directly in existing public key fields such as those found in PKCS#10 [RFC2986], CMP [RFC4210], X.509 [RFC5280], CMS [RFC5652], and the Trust Anchor Format [RFC5914].¶
[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.¶
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 encapsulated sequence of component keys as if it was a single key. This generally means that the complexity of combining algorithms can and should be ignored by application and protocol layers and deferred to the cryptographic library layer.¶
The following ASN.1 Information Object Class applies to all composite key types, with suitable replacements for the ASN.1 identifier pk-Composite and the OID id-composite-key as appropriate. See the ASN.1 Module in Section 5 for parmeterized as well as signature and KEM versions.¶
pk-Composite PUBLIC-KEY ::= {
id id-composite-key
KeyValue CompositePublicKey
Params ARE ABSENT
PrivateKey CompositePrivateKey
}
¶
keyUsage is omitted here because composites may be formed for keys of any type, provided that any key usage specified MUST apply to all component keys. Composites MAY NOT be used to combine key types, for example to make a "dual-usage" key by combining a signing key with a KEM key.¶
Composite public key data is represented by the following structure:¶
CompositePublicKey ::= SEQUENCE SIZE (2..MAX) OF SubjectPublicKeyInfo¶
A composite key MUST contain at least two component public keys. When the composite key is used in conjunction with an explicit composite algorithm identifier defined under section Section 4, the order of the component keys is determined by that algorithm identifier's definition.¶
A CompositePublicKey MUST NOT contain a component public key which itself describes a composite key; i.e. recursive CompositePublicKeys are not allowed. The purpose is a general reduction in complexity by not needing to consider nested key types.¶
Each element of a CompositePublicKey is a SubjectPublicKeyInfo object encoding a component public key. Each component SubjectPublicKeyInfo SHALL contain an AlgorithmIdentifier OID which identifies the public key type and parameters for the public key contained within it. See Section 4 for specific algorithms defined in this document.¶
When the CompositePublicKey must be provided in octet string or bit string format, the data structure is encoded as specified in Section 3.5.¶
Protocols such as X.509 [RFC5280] that specify a key usage along with the public key. For composite keys, a single key usage is specified for the entire public key and it MUST apply to all component keys. For example if a composite key is marked with a key usage of digitalSignature, then all component keys MUST be capable of producing digital signatures and handled with policies appropriate for digital signature keys. The composite mechanism MUST NOT be used to implement mixed-usage keys, for example, where a digitalSignature and a keyEncipherment key are combined together into a single composite key.¶
Specifications of explicit composite key types must specify allowable key usages for that type based on the types of the components.¶
Many cryptographic libraries will require treating each component key independently and thus expect a full SubjectPublicKeyInfo for each component at some layer of the software stack. This left two design choices: either we carry full SPKI for each component within the CompositePublicKey, or we compress it by only carrying the raw key bytes and force implementations to carry OID and parameter mapping tables to be able to reconstruct component SPKIs.¶
The authors decided to carry the full SPKIs in order to lessen the implementation complexity at the expense of a small amount of redundant data to transmit. This also leads to the same wire format between explicitly specified combinations and generic composites where the component OIDs cannot be infered and thus must be carried.¶
This design choice has a non-obvious security risk in that the algorithm carried within each component SPKI is redundant information which MUST match -- and can be inferred from -- the specification of the explicit algorithm.¶
Security consideration: Implementations SHOULD check that the component AlgorithmIdentifier OIDs and parameters match those expected by the definition of the explicit algorithm. Implementations SHOULD first parse a component's SubjectPublicKeyInfo.algorithm, and ensure that it matches what is expected for that position in the explicit key, and then proceed to parse the SubjectPublicKeyInfo.subjectPublicKey. This is to reduce the attack surface associated with parsing the public key data of an unexpected key type, or worse; to parse and use a key which does not match the explicit algorithm definition. Similar checks SHOULD be done when handling the corresponding private key.¶
This section provides an encoding for composite private keys intended for PKIX protocols and other applications that require an interoperable format for transmitting private keys, such as PKCS #12 [RFC7292] or CMP / CRMF [RFC4210], [RFC4211]. It is not intended to dictate a storage format in implementations not requiring interoperability of private key formats.¶
In some cases 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. The establishment of correspondence between public keys in a CompositePublicKey and private keys not represented in a single composite structure is beyond the scope of this document.¶
The composite private key data is represented by the following structure:¶
CompositePrivateKey ::= SEQUENCE SIZE (2..MAX) OF OneAsymmetricKey¶
Each element is a OneAsymmetricKey [RFC5958] object for a component private key.¶
The parameters field MUST be absent.¶
A CompositePrivateKey MUST contain at least two component private keys, and the order of the component keys is the same as the order defined in Section 3.2 for the components of CompositePublicKey.¶
A CompositePrivateKey can be stored in a OneAsymmetricKey structure (version 1 of which is also known as PrivateKeyInfo) [RFC5958]. When this is done, the privateKeyAlgorithm field SHALL be set to the corresponding composite algorithm identifier defined according to Section 4, the privateKey field SHALL contain the CompositePrivateKey, and the publicKey field MUST NOT be present. Associated public key material MAY be present in the CompositePrivateKey.¶
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.¶
CompositePublicKeyOs ::= OCTET STRING (CONTAINING CompositePublicKey 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.¶
CompositePublicKeyBs ::= BIT STRING (CONTAINING CompositePublicKey ENCODED BY der)¶
This section defines algorithm identifiers, component algorithms and their ordering for composite combinations. The combinations registered in this section are intended to strike a balance between the overall number of combinations ("the combinatorial explosion problem"), while also covering the needs of a wide range of protocols, applications, and regulatory environments in which X.509-based technologies are used.¶
This section is not intended to be exhaustive and other authors may define OIDs for new combinations so long as they are compatible with the structures and processes defined in this and the companion signature and encryption documents.¶
This table summarizes the list of explicit composite Signature algorithms by the key and signature OID and the two component algorithms which make up the explicit composite algorithm. These are denoted by First Signature Alg, and Second Signature Alg.¶
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 <CompSig> with the String "2.16.840.1.114027.80.5.1"¶
Therefore <CompSig>.1 is equal to 2.16.840.1.114027.80.5.1.1¶
Note that a single OID is used for both the key type and the signature algorithm; ie there is a one-to-one correspondance between key types and signature algorithms, hence why these key type names contain more information than they strictly need to define a key type.¶
| Composite Signature Key Type | OID | First Key Type | Second Key Type |
|---|---|---|---|
| id-Dilithium3-RSA-PSS | <CompSig>.14 | Dilithium3 | RSASSA-PSS |
| id-Dilithium3-RSA-PKCS15-SHA256 | <CompSig>.1 | Dilithium3 | RSAES-PKCS-v1_5 |
| id-Dilithium3-ECDSA-P256-SHA256 | <CompSig>.2 | Dilithium3 | EC-P256 |
| id-Dilithium3-ECDSA-brainpoolP256r1-SHA256 | <CompSig>.3 | Dilithium3 | EC-brainpoolP256r1 |
| id-Dilithium3-Ed25519 | <CompSig>.4 | Dilithium3 | Ed25519 |
| id-Dilithium5-ECDSA-P384-SHA384 | <CompSig>.5 | Dilithium5 | EC-P384 |
| id-Dilithium5-ECDSA-brainpoolP384r1-SHA384 | <CompSig>.6 | Dilithium5 | EC-brainpoolP384r1 |
| id-Dilithium5-Ed448 | <CompSig>.7 | Dilithium5 | Ed448 |
| id-Falcon512-ECDSA-P256-SHA256 | <CompSig>.8 | Falcon512 | EC-P256 |
| id-Falcon512-ECDSA-brainpoolP256r1-SHA256 | <CompSig>.9 | Falcon512 | EC-brainpoolP256r1 |
| id-Falcon512-Ed25519 | <CompSig>.10 | Falcon512 | Ed25519 |
| id-SPHINCSplusSHA256128sSimple-ECDSA-P256-SHA256 | <CompSig>.11 | SPHINCSplusSHA256128sSimple | EC-P256 |
| id-SPHINCSplusSHA256128sSimple-ECDSA-brainpoolP256r1-SHA256 | <CompSig>.12 | SPHINCSplusSHA256128sSimple | EC-brainpoolP256r1 |
| id-SPHINCSplusSHA256128sSimple-Ed25519 | <CompSig>.13 | SPHINCSplusSHA256128sSimple | Ed25519 |
| id-composite-sig | (1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) OpenCA(18227) Algorithms(2) id-alg-composite(1) | Any | Any |
The table above contains everything needed to implement the listed explicit composite algorithms. See the ASN.1 module in section Section 5 for the explicit definitions of the above Composite signature algorithms.¶
Full specifications for the referenced algorithms can be found as follows:¶
secp256r1 as defined in [RFC5480].¶
brainpoolP256r1 as defined in [RFC5639].¶
secp384r1 as defined in [RFC5480].¶
brainpoolP384r1 as defined in [RFC5639].¶
The intended application for the key is indicated in the keyUsage certificate extension; see Section 4.2.1.3 of [RFC5280]. If the keyUsage extension is present in a certificate that indicates signature public key types above in the SubjectPublicKeyInfo, then the at least one of following MUST be present:¶
digitalSignature; or nonRepudiation; or keyCertSign; or cRLSign.¶
Requirements about the keyUsage extension bits defined in [RFC5280] still apply.¶
This table summarizes the list of explicit composite Signature algorithms by the key and signature OID and the two component algorithms which make up the explicit composite algorithm. These are denoted by First Signature Alg, and Second Signature Alg.¶
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"¶
Therefore <CompKEM>.1 is equal to 2.16.840.1.114027.80.5.2.1.¶
Note that a single OID is used for both the key type and the KEM algorithm; ie there is a one-to-one correspondance between key types and KEM algorithms, hence why these key type names contain more information than they strictly need to define a key type.¶
| Composite KEM Key Type | OID | First Key Type | Second Key Type | |
|---|---|---|---|---|
| id-Kyber512-ECDH-P256-KMAC128 | <CompKEM>.1 | Kyber512 | EC-P256 | |
| id-Kyber512-ECDH-brainpoolP256r1-KMAC128 | <CompKEM>.2 | Kyber512 | EC-brainpoolP256r1 | |
| id-Kyber512-X25519-KMAC128 | <CompKEM>.3 | Kyber512 | X25519 | |
| id-Kyber768-RSA-KMAC256 | <CompKEM>.4 | Kyber768 | RSA-KEM | |
| id-Kyber768-ECDH-P256-KMAC256 | <CompKEM>.5 | Kyber768 | EC-P256 | |
| id-Kyber768-ECDH-brainpoolP256r1-KMAC256 | <CompKEM>.6 | Kyber768 | EC-brainpoolP256r1 | |
| id-Kyber768-X25519-KMAC256 | <CompKEM>.7 | Kyber768 | X25519 | |
| id-Kyber1024-ECDH-P384-KMAC256 | <CompKEM>.8 | Kyber1024 | EC-P384 | |
| id-Kyber1024-ECDH-brainpoolP384r1-KMAC256 | <CompKEM>.9 | Kyber1024 | EC-brainpoolP384r1 | |
| id-Kyber1024-X448-KMAC256 | <CompKEM>.10 | Kyber1024 | X448 | |
| id-composite-kem-KMAC128 | 2.16.840.1.114027.80.4.1 | Any | Any | |
| id-composite-kem-KMAC256 | 2.16.840.1.114027.80.4.1 NEEDS NEW OID | Any | Any |
The table above contains everything needed to implement the listed explicit composite algorithms. See the ASN.1 module in section Section 5 for the explicit definitions of the above Composite signature algorithms.¶
Full specifications for the referenced algorithms can be found as follows:¶
secp256r1 as defined in [RFC5480].¶
brainpoolP256r1 as defined in [RFC5639].¶
secp384r1 as defined in [RFC5480].¶
brainpoolP384r1 as defined in [RFC5639].¶
Note: the inclusion of a hash function is so that these algorithm identifiers can double as both key types and KEM algorithms.¶
The intended application for the key is indicated in the keyUsage certificate extension; see Section 4.2.1.3 of [RFC5280]. If the keyUsage extension is present in a certificate that indicates any of the KEM public key types above in the SubjectPublicKeyInfo, then the following MUST be present:¶
keyEncipherment¶
Requirements about the keyUsage extension bits defined in [RFC5280] still apply.¶
<CODE STARTS>
-- command for easily copying it into a compiler (ubuntu with xclip)
-- cat ASN1ModuleIncludes.asn Composite-Keys-2023.asn | xclip -sel clip
Composite-Keys-2023
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-composite-keys(98)}
DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL;
IMPORTS
PUBLIC-KEY, SIGNATURE-ALGORITHM, ParamOptions, 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) }
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) }
NamedCurve
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) }
pk-Ed25519, pk-X25519, pk-X448
FROM Safecurves-pkix-18
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-safecurves-pkix(93) } ;
--
-- Object Identifiers
--
der OBJECT IDENTIFIER ::=
{joint-iso-itu-t asn1(1) ber-derived(2) distinguished-encoding(1)}
-- TODO: To be replaced by IANA
id-composite-key OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) composite(4) compositekey(1) }
-- COMPOSITE-KEY-ALGORITHM
--
-- Describes the basic properties of a composite key algorithm
--
-- &id - contains the OID identifying the composite algorithm
-- &Params - if present, contains the type for the algorithm
-- parameters; if absent, implies no parameters
-- ¶mPresence - parameter presence requirement
--
-- }
COMPOSITE-KEY-ALGORITHM ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Params OPTIONAL,
¶mPresence ParamOptions DEFAULT absent
} WITH SYNTAX {
IDENTIFIER &id
[PARAMS [TYPE &Params] ARE ¶mPresence ]
}
--
-- Public Key
--
-- Generic Composite
-- TODO: To be replaced by IANA
id-composite-key OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) composite(4) compositekey(1) }
pk-Composite PUBLIC-KEY ::= {
IDENTIFIER id-composite-key
KEY CompositePublicKey
PARAMS TYPE CompositeAlgorithmIdentifier ARE optional
PRIVATE-KEY CompositePrivateKey
}
CompositePublicKey ::= SEQUENCE SIZE (2..MAX) OF SubjectPublicKeyInfo
CompositePublicKeyOs ::= OCTET STRING (CONTAINING CompositePublicKey ENCODED BY der)
CompositePublicKeyBs ::= BIT STRING (CONTAINING CompositePublicKey ENCODED BY der)
CompositePrivateKey ::= SEQUENCE SIZE (2..MAX) OF OneAsymmetricKey
--
-- Composite public key information objects
--
-- The following ASN.1 object class then automatically generates the
-- public key structure from the types defined in pk-explicitComposite.
-- ExplicitCompositePublicKey - The data structure for a composite
-- public key sec-composite-pub-keys and SecondPublicKeyType are needed
-- because PUBLIC-KEY contains a set of public key types, not a single
-- type.
-- TODO The parameters should be optional only if they are marked
-- optional in the PUBLIC-KEY
ExplicitCompositePublicKey{PUBLIC-KEY:firstPublicKey, FirstPublicKeyType,
PUBLIC-KEY:secondPublicKey, SecondPublicKeyType} ::= SEQUENCE {
firstPublicKey SEQUENCE {
params firstPublicKey.&Params OPTIONAL,
publicKey FirstPublicKeyType
},
secondPublicKey SEQUENCE {
params secondPublicKey.&Params OPTIONAL,
publicKey SecondPublicKeyType
}
}
pk-explicitCompositeSignature{OBJECT IDENTIFIER:id, PUBLIC-KEY:firstPublicKey,
FirstPublicKeyType, PUBLIC-KEY:secondPublicKey, SecondPublicKeyType}
PUBLIC-KEY ::= {
IDENTIFIER id
KEY ExplicitCompositePublicKey{firstPublicKey, FirstPublicKeyType,
secondPublicKey, SecondPublicKeyType}
PARAMS ARE absent
CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
}
pk-explicitCompositeKEM{OBJECT IDENTIFIER:id, PUBLIC-KEY:firstPublicKey,
FirstPublicKeyType, PUBLIC-KEY:secondPublicKey, SecondPublicKeyType}
PUBLIC-KEY ::= {
IDENTIFIER id
KEY ExplicitCompositePublicKey{firstPublicKey, FirstPublicKeyType,
secondPublicKey, SecondPublicKeyType}
PARAMS ARE absent
CERT-KEY-USAGE { keyEncipherment }
}
-- TODO this is one possible way to reference specific named curves.
-- But I don't think this compiles.
--pk-ECDSA-P256 PUBLIC-KEY ::= {
-- IDENTIFIER id-ecPublicKey
-- KEY ECPoint
-- PARAMS TYPE NamedCurve.secp256r1 ARE required }
--
--pk-ECDSA-brainpoolP256r1 PUBLIC-KEY ::= {
-- IDENTIFIER id-ecPublicKey
-- KEY ECPoint
-- PARAMS NamedCurve{brainpoolP256r1} }
--
--pk-ECDSA-P384 PUBLIC-KEY ::= {
-- IDENTIFIER id-ecPublicKey
-- KEY ECPoint
-- PARAMS TYPE NamedCurve{secp384r1} }
--
--pk-ECDSA-brainpoolP384r1 PUBLIC-KEY ::= {
-- IDENTIFIER id-ecPublicKey
-- KEY ECPoint
-- PARAMS NamedCurve{brainpoolP384r1} }
-- Explicit Composite Signature Keys
-- TODO: To be replaced by IANA
id-Dilithium3-RSA-PSS OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) signature(1) dilithium3-rsa-pss(14) }
pk-Dilithium3-RSA-PSS PUBLIC-KEY ::=
pk-explicitCompositeSignature{id-Dilithium3-RSA-PSS, pk-Dilithium3TBD,
OCTET STRING, pk-rsaSSA-PSS, OCTET STRING}
-- TODO: To be replaced by IANA
id-Dilithium3-RSA-PKCS15-SHA256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) signature(1) dilithium3-rsa(1) }
pk-Dilithium3-RSA-PKCS15-SHA256 PUBLIC-KEY ::=
pk-explicitCompositeSignature{id-Dilithium3-RSA-PKCS15-SHA256,
pk-Dilithium3TBD, OCTET STRING, pk-rsa, RSAPublicKey}
-- TODO: To be replaced by IANA
id-Dilithium3-ECDSA-P256-SHA256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) signature(1) dilithium3-rsa(2) }
pk-Dilithium3-ECDSA-P256-SHA256 PUBLIC-KEY ::=
pk-explicitCompositeSignature{id-Dilithium3-ECDSA-P256-SHA256,
pk-Dilithium3TBD, OCTET STRING, pk-ECDSA-P256, ECPoint}
--TODO: this is missing `PARAMS secp256r1`
-- TODO: To be replaced by IANA
id-Dilithium3-ECDSA-brainpoolP256r1 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) signature(1)
dilithium3-ecdsa-brainpoolp256r1(3) }
pk-Dilithium3-ECDSA-brainpoolP256r1 PUBLIC-KEY ::=
pk-explicitCompositeSignature{id-Dilithium3-ECDSA-brainpoolP256r1,
pk-Dilithium3TBD, OCTET STRING, pk-ec, ECPoint}
--TODO: this is missing `PARAMS brainpoolP256r1`
-- TODO: To be replaced by IANA
id-Dilithium3-Ed25519 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) signature(1) dilithium3-ed25519(4) }
pk-Dilithium3-Ed25519 PUBLIC-KEY ::=
pk-explicitCompositeSignature{id-Dilithium3-Ed25519,
pk-Dilithium3TBD, OCTET STRING, pk-Ed25519, OCTET STRING}
-- TODO: To be replaced by IANA
id-Dilithium5-ECDSA-P384 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) signature(1) dilithium5-ecdsa-p384(5) }
pk-Dilithium5-ECDSA-P384 PUBLIC-KEY ::=
pk-explicitCompositeSignature{id-Dilithium5-ECDSA-P384,
pk-Dilithium5TBD, OCTET STRING, pk-ec, ECPoint}
--TODO: this is missing `PARAMS secp384r1`
-- TODO: To be replaced by IANA
id-Dilithium5-ECDSA-brainpoolP384r1 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) signature(1) dilithium5-ecdsa-brainpoolp384r1(6) }
pk-Dilithium5-ECDSA-brainpoolP384r1 PUBLIC-KEY ::=
pk-explicitCompositeSignature{id-Dilithium5-ECDSA-brainpoolP384r1,
pk-Dilithium5TBD, OCTET STRING, pk-ec, ECPoint}
--TODO: this is missing `PARAMS brainpoolP384r1`
-- TODO: To be replaced by IANA
id-Dilithium5-Ed448 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) signature dilithium5-ed448(7) }
pk-Dilithium5-Ed448 PUBLIC-KEY ::=
pk-explicitCompositeSignature{id-Dilithium5-Ed448,
pk-Dilithium5TBD, OCTET STRING, pk-Ed25519, OCTET STRING}
--TODO: I have a question out to LAMPS about why there is no pk-Ed448. See: https://mailarchive.ietf.org/arch/msg/spasm/bJHcxCA3bXoqKHqXnZ85Vrixu68/
-- TODO: To be replaced by IANA
id-Falcon512-ECDSA-P256-SHA256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) signature falcon512-ecdsa-p256-sha256(8) }
pk-Falcon512-ECDSA-P256-SHA256 PUBLIC-KEY ::=
pk-explicitCompositeSignature{id-Falcon512-ECDSA-P256-SHA256,
pk-falcon512TBD, OCTET STRING, pk-ec, ECPoint}
--TODO: this is missing `PARAMS secp256r1`
-- TODO: To be replaced by IANA
id-Falcon512-ECDSA-brainpoolP256r1-SHA256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) signature(1) falcon512-ecdsa-brainpoolp256r1-sha256(9) }
pk-Falcon512-ECDSA-brainpoolP256r1-SHA256 PUBLIC-KEY ::=
pk-explicitCompositeSignature{id-Falcon512-ECDSA-brainpoolP256r1-SHA256,
pk-falcon512TBD, OCTET STRING, pk-ec, ECPoint}
--TODO: this is missing `PARAMS brainpoolp256r1`
-- TODO: To be replaced by IANA
id-Falcon512-Ed25519 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) signatur(1) falcon512-ed25519(10) }
pk-Falcon512-Ed25519 PUBLIC-KEY ::=
pk-explicitCompositeSignature{id-Falcon512-Ed25519,
pk-falcon512TBD, OCTET STRING, pk-Ed25519, OCTET STRING}
-- TODO: To be replaced by IANA
id-SPHINCSplusSHA256128sSimple-ECDSA-P256-SHA256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) signature(1) sphincsplussha256128ssimple-ecdsa-p256-sha256(11) }
pk-SPHINCSplusSHA256-ECDSA-P256 PUBLIC-KEY ::=
pk-explicitCompositeSignature{id-SPHINCSplusSHA256-ECDSA-P256,
pk-sphincs-plus-256, SPHINCS-Plus-PublicKey, pk-ec, ECPoint}
--TODO: this is missing `PARAMS secp256r1`
-- TODO: To be replaced by IANA
id-SPHINCSplusSHA256128sSimple-ECDSA-brainpoolP256r1-SHA256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) signature(1)
id-sphincsplussha256128ssimple-ecdsa-brainpoolp256r1-sha256(12) }
pk-SPHINCSplusSHA256128sSimple-ECDSA-brainpoolP256r1-SHA256 PUBLIC-KEY ::=
pk-explicitCompositeSignature{id-SPHINCSplusSHA256128sSimple-ECDSA-brainpoolP256r1-SHA256,
pk-sphincs-plus-256, SPHINCS-Plus-PublicKey, pk-ec, ECPoint}
--TODO: this is missing `PARAMS brainpoolp256r1`
-- TODO: To be replaced by IANA
id-SPHINCSplusSHA256128sSimple-Ed25519 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) signature(1)
sphincsplussha256128ssimple-ed25519(13) }
pk-SPHINCSplusSHA256128sSimple-Ed25519 PUBLIC-KEY ::=
pk-explicitCompositeSignature{id-SPHINCSplusSHA256128sSimple-Ed25519,
pk-sphincs-plus-256, SPHINCS-Plus-PublicKey, pk-Ed25519, OCTET STRING}
-- Explicit Composite KEM Keys
-- TODO: To be replaced by IANA
id-Kyber512-ECDH-P256-KMAC128 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) explicitcomposite-kem(2) id-kyber512-ecdh-p256(1) }
pk-Kyber512-ECDH-P256-KMAC128 PUBLIC-KEY ::=
pk-explicitCompositeKEM{id-Kyber512-ECDH-P256-KMAC128,
pk-Kyber512TBD, OCTET STRING, pk-ec, ECPoint}
--TODO: this is missing `PARAMS secp256r1`
-- TODO: To be replaced by IANA
id-Kyber512-ECDH-brainpoolP256r1-KMAC128 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) explicitcomposite-kem(2) id-kyber512-ecdh-brainpoolp256r1(2) }
pk-Kyber512-ECDH-brainpoolP256r1-KMAC128 PUBLIC-KEY ::=
pk-explicitCompositeKEM{id-Kyber512-ECDH-brainpoolP256r1-KMAC128,
pk-Kyber512TBD, OCTET STRING, pk-ec, ECPoint}
--TODO: this is missing `PARAMS brainpoolp256r1`
-- TODO: To be replaced by IANA
id-Kyber512-X25519-KMAC128 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) kem(2)
id-kyber512-x25519(3) }
pk-Kyber512-X25519-KMAC128 PUBLIC-KEY ::=
pk-explicitCompositeKEM{id-Kyber512-X25519-KMAC128,
pk-Kyber512TBD, OCTET STRING, pk-X25519, OCTET STRING}
-- TODO: To be replaced by IANA
id-Kyber768-RSA-KMAC256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) kem(2)
id-kyber768-rsa(4) }
pk-Kyber768-RSA-KMAC256 PUBLIC-KEY ::=
pk-explicitCompositeKEM{id-Kyber768-RSA-KMAC256,
pk-Kyber768TBD, OCTET STRING, pk-rsa, RSAPublicKey}
-- TODO: To be replaced by IANA
id-Kyber768-ECDH-P256-KMAC256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) kem(2)
id-kyber768-ecdh-p256(5) }
pk-Kyber768-ECDH-P256-KMAC256 PUBLIC-KEY ::=
pk-explicitCompositeKEM{id-Kyber768-ECDH-P256-KMAC256,
pk-Kyber768TBD, OCTET STRING, pk-ec, ECPoint}
--TODO: this is missing `PARAMS secp256r1`
id-Kyber768-ECDH-brainpoolP256r1-KMAC256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) kem(2)
id-kyber768-ecdh-p256(6) }
pk-Kyber768-ECDH-brainpoolP256r1-KMAC256 PUBLIC-KEY ::=
pk-explicitCompositeKEM{id-Kyber768-ECDH-brainpoolP256r1-KMAC256,
pk-Kyber768TBD, OCTET STRING, pk-ec, ECPoint}
--TODO: this is missing `PARAMS brainpoolp256r1`
-- TODO: To be replaced by IANA
id-Kyber768-X25519-KMAC256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) kem(2)
id-kyber768-x25519(7) }
pk-Kyber768-X25519-KMAC256 PUBLIC-KEY ::=
pk-explicitCompositeKEM{id-Kyber768-X25519-KMAC256,
pk-Kyber768TBD, OCTET STRING, pk-X25519, OCTET STRING}
-- TODO: To be replaced by IANA
id-Kyber1024-ECDH-P384-KMAC256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) kem(2)
id-kyber1024-ecdh-p384(8) }
pk-Kyber1024-ECDH-P384-KMAC256 PUBLIC-KEY ::=
pk-explicitCompositeKEM{id-Kyber1024-ECDH-P384-KMAC256,
pk-Kyber1024TBD, OCTET STRING, pk-ec, ECPoint}
--TODO: this is missing `PARAMS secp384r1`
-- TODO: To be replaced by IANA
id-Kyber1024-ECDH-brainpoolP384r1-KMAC256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) kem(2)
id-kyber1024-ecdh-brainpoolp384r1(9) }
pk-Kyber1024-ECDH-brainpoolP384r1-KMAC256 PUBLIC-KEY ::=
pk-explicitCompositeKEM{id-Kyber1024-ECDH-brainpoolP384r1-KMAC256,
pk-Kyber1024TBD, OCTET STRING, pk-ec, ECPoint}
--TODO: this is missing `PARAMS brainpoolp384r1`
-- TODO: To be replaced by IANA
id-Kyber1024-X448-KMAC256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
algorithm(80) explicitcomposite(5) kem(2)
id-kyber1024-x448(10) }
pk-Kyber1024-X448-KMAC256 PUBLIC-KEY ::=
pk-explicitCompositeKEM{id-Kyber1024-X448-KMAC256,
pk-Kyber1024TBD, OCTET STRING, pk-X448, OCTET STRING}
END
<CODE ENDS>
¶
All sorts of OIDs in the ASN.1 module. Too many to list here (sorry).¶
This document registers the following in the SMI "Security for PKIX Algorithms (1.3.6.1.5.5.7.6)" registry:¶
id-composite-key OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) algorithms(6) id-composite-key(??) }
¶
There is an additional security consideration that some use cases such as signatures remain secure against downgrade attacks if and only if component keys are never used outside of their composite context and therefore it is RECOMMENDED that component keys in a composite key are not to be re-used in other contexts. In particular, the components of a composite key SHOULD NOT also appear in single-key certificates. This is particularly relevant for protocols that use composite keys in a logical AND mode since the appearance of the same component keys in single-key contexts undermines the binding of the component keys into a single composite key by allowing messages signed in a multi-key AND mode to be presented as if they were signed in a single key mode in what is known as a "stripping attack".¶
This security consideration copied from Section 3.2.2.¶
Implementations SHOULD check that the component AlgorithmIdentifier OIDs and parameters match those expected by the definition of the explicit algorithm. Implementations SHOULD first parse a component's SubjectPublicKeyInfo.algorithm, and ensure that it matches what is expected for that position in the explicit key, and then proceed to parse the SubjectPublicKeyInfo.subjectPublicKey. This is to reduce the attack surface associated with parsing the public key data of an unexpected key type, or worse; to parse and use a key which does not match the explicit algorithm definition. Similar checks SHOULD be done when handling the corresponding private key.¶
Traditionally, a public key, certificate, or signature contains a single cryptographic algorithm. If and when an algorithm becomes deprecated (for example, RSA-512, or SHA1), it is obvious that clients performing signature verification or encryption operations should be updated to fail to validate or refuse to encrypt for these algorithms.¶
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, certificate, signature, or ciphertext MAY contain a mixture of deprecated and non-deprecated algorithms.¶
Specifying behaviour in these cases is beyond the scope of this document, but should be considered by implementers and potentially in additional standards.¶
EDNOTE: Max had proposed a CRL mechanism to accomplish this, which could be revived if necessary.¶
Structures described in this document do not protect private keys in any way unless combined with a security protocol or encryption properties of the objects (if any) where the CompositePrivateKey is used.¶
Protection of the private keys is vital to public key cryptography. The consequences of disclosure depend on the purpose of the private key. If a private key is used for signature, then the disclosure allows unauthorized signing. If a private key is used for key management, then disclosure allows unauthorized parties to access the managed keying material. The encryption algorithm used in the encryption process must be at least as 'strong' as the key it is protecting.¶
Certification Authority (CA) implementations need to be careful when checking for compromised key reuse, for example as required by WebTrust regulations; when checking for compromised keys, you MUST unpack the CompositePublicKey structure and compare individual component keys. In other words, for the purposes of key reuse checks, the composite public key structures need to be un-packed so that primitive keys are being compared. For example if the composite key {RSA1, PQ1} is revoked for key compromise, then the keys RSA1 and PQ1 need to be individually considered revoked. If the composite key {RSA1, PQ2} is submitted for certification, it SHOULD be rejected because the key RSA1 was previously declared compromised even though the key PQ2 is unique.¶
For content commitment use-cases, such as legally-binding non-repudiation, the signer (whether it be a CA or an end entity) needs to be able to specify how its signature is to be interpreted and verified.¶
For now we have removed combiner modes (AND, OR, KofN) from this draft, but we are still discussing how to incorporate this for the cases where it is needed (maybe a X.509 v3 extension, or a signature algorithm param).¶
These samples are reproduced here for completeness, but are also available in github:¶
https://github.com/EntrustCorporation/draft-ounsworth-pq-composite-keys/tree/master/sampledata¶
TODO: move these to https://github.com/lamps-wg before publication¶
This is an example generic composite public key¶
-----BEGIN PUBLIC KEY----- MIIBmDAMBgpghkgBhvprUAQBA4IBhgAwggGBMFkwEwYHKoZIzj0CAQYIKoZIzj0D AQcDQgAExGPhrnuSG/fGyw1FN+l5h4p4AGRQCS0LBXnBO+djhcI6qnF2TvrQEaIY GGpQT5wHS+7y5iJJ+dE5qjxcv8loRDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANsVQK1fcLQObL4ZYtczWbObECAFSsng0OLpRTPr9VGV3SsS/VoMRZqX F+sszz6I2UcFTaMF9CwNRbWLuIBczzuhbHSjn65OuoN+Om2wsPo+okw46RTekB4a d9QQvYRVzPlILUQ8NvZ4W0BKLviXTXWIggjtp/Y1pKRHKz8n35J6OmFWz4TKGNth n87D28kmdwQYH5NLsDePHbfdw3AyLrPvQLlQw/hRPz/9Txf7yi9Djg9HtJ88ES6+ ZbfE1ZHxLYLSDt25tSL8A2pMuGMD3P81nYWO+gJ0vYV2WcRpXHRkjmliGqiCg4eB mC4//tm0J4r9Ll8b/pp6xyOMI7jppVUCAwEAAQ== -----END PUBLIC KEY-----¶
which decodes as:¶
algorithm: AlgorithmIdentifier{id-composite-key}
subjectPublicKey: CompositePublicKey {
SubjectPublicKeyInfo {
algorithm: AlgorithmIdentifier {
algorithm: ecPublicKey
parameters: prime256v1
}
subjectPublicKey: <ec key octet string>
},
SubjectPublicKeyInfo {
algorithm: AlgorithmIdentifier {
algorithm: rsaEncryption
parameters: NULL
}
subjectPublicKey: <rsa key octet string>
}
}
¶
The corresponding explicit private key is as follows. Note that the PQ key comes from OpenQuantumSafe-openssl and is in the {privatekey || publickey} concatenated format. This may cause interoperability issues with some clients, and also makes the private keys appear larger than they would be if generated by a non-openssl client.¶
-----BEGIN PRIVATE KEY----- MIIFHgIBADAMBgpghkgBhvprUAQBBIIFCTCCBQUwQQIBADATBgcqhkjOPQIBBggq hkjOPQMBBwQnMCUCAQEEICN0ihCcgg5n8ALtk9tkQZqg/WLEm5NefMi/kdN06Z9u MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDbFUCtX3C0Dmy+ GWLXM1mzmxAgBUrJ4NDi6UUz6/VRld0rEv1aDEWalxfrLM8+iNlHBU2jBfQsDUW1 i7iAXM87oWx0o5+uTrqDfjptsLD6PqJMOOkU3pAeGnfUEL2EVcz5SC1EPDb2eFtA Si74l011iIII7af2NaSkRys/J9+SejphVs+EyhjbYZ/Ow9vJJncEGB+TS7A3jx23 3cNwMi6z70C5UMP4UT8//U8X+8ovQ44PR7SfPBEuvmW3xNWR8S2C0g7dubUi/ANq TLhjA9z/NZ2FjvoCdL2FdlnEaVx0ZI5pYhqogoOHgZguP/7ZtCeK/S5fG/6aescj jCO46aVVAgMBAAECggEAFtT6LpdZuYofTxh6Mo9Jc+xfG9cxWiSx4FQLQEQBBwWl TQ3nlXDd+CRy+7Fpz8yXSE2HL8w5DDY945OyIL6LYl2KXgWHaLUPvxByqmfVqd7J L0RnFiOzxU9g2Zr9BUOj3v7kqM3VtI4KhIK2rnWmPu+BDckmzgP9Kpm4KhbPuAYP iqUZSkxpSUsd5ALLsk9b0xjR7UEYkEpV2/vORwieEhOmPLzuXh+Px0yavkazT/vU +h/rDSoLQn7v4fVsQgNdOaaOG/gHemGuuiLPJJlX5ZZ6mmsIaEjz+MNk0aJDH2po KbAr4B709dTsnYgv7YtkEfSyOeMEdhMiswI1c9FpwQKBgQD6kdHmHCoeWNNvlqxU v57e7ZDAXDA6WcfrypcsF0l72rI3J8oOPmFaNaCmwIH/Icz+Zy7fr2IYxVjyDjCa zi8qTnj2ZNds71hUYOcq60u0TcSVrtocA4HW7NoWJqK5thNlNaa1M358cYBopGoN ocS9yf10q2MBZtpF0fc5PbFf+QKBgQDf1L4cezoebbNTaN4KoapycHXxKozP2GwI r15YRYjt0ZpHstdUPABQuwlL9CuL+5Q17VRiM81cUVNfFsBzKIXYb/PBC5UD+DmR qGlT6v6uUWY6jifUgEjfyPxO0oJ3M6cChHR/TvpkT5SyaEwHpIH7IeXbMFcS5m4G mSNBECO/PQKBgCD0CoHT1Go3Tl9PloxywwcYgT/7H9CcvCEzfJws19o1EdkVH4qu A4mkoeMsUCxompgeo9iBLUqKsb7rxNKnKSbMOTZWXsqR07ENKXnIhiVJUQBKhZ7H i0zjy268WAxKeNSHsMwF4K2nE7cvYE84pjI7nVy5qYSmrTAfg/8AMRKpAoGBAN/G wN6WsE9Vm5BLapo0cMUC/FdFFAyEMdYpBei4dCJXiKgf+7miVypfI/dEwPitZ8rW YKPhaHHgeLq7c2JuZAo0Ov2IR831MBEYz1zvtvmuNcda8iU4sCLTvLRNL9Re1pzk sdfJrPn2uhH3xfNqG+1oQXZ3CMbDi8Ka/a0Bpst9AoGBAPR4p6WN0aoZlosyT6NI 4mqzNvLE4KBasmfoMmTJih7qCP3X4pqdgiI0SjsQQG/+utHLoJARwzhWHOZf1JKk D8lSJH02cp/Znrjn5wPpfYKLphJBiKSPwyIjuFwcR1ck84ONeYq421NDqf7lXbvx oMqjTPagXUpzHvwluDjtSi8+ -----END PRIVATE KEY-----¶
which decodes as:¶
algorithm: AlgorithmIdentifier{id-composite-key}
SEQUENCE {
OneAsymmetricKey {
version: 0,
privateKeyAlgorithm: PrivateKeyAlgorithmIdentifier{
algorithm: ecPublicKey
parameters: prime256v1
}
privateKey: <ec key octet string>
},
OneAsymmetricKey {
version: 0,
privateKeyAlgorithm: PrivateKeyAlgorithmIdentifier{
algorithm: rsaEncryption
parameters: NULL
}
privateKey: <rsa key octet string>
}
}
¶
This example uses the following OID as defined in Open Quantum Safe, which correspond to NIST Round3 candidates:¶
https://github.com/open-quantum-safe/oqs-provider/blob/main/ALGORITHMS.md¶
id-dilithium3_aes 1.3.6.1.4.1.2.267.11.6.5¶
A Dilithium3-ECDSA-P256 public key:¶
-----BEGIN PUBLIC KEY----- MIIIKjAMBgpghkgBhvprUAUBA4IIGAAwgggTMIIHtDANBgsrBgEEAQKCCwsGBQOCB6EA2wEINOg X+0DRUsEixdVXp+ZVcigmaDEEDNCSblD9t5nERtIufPxKONt/IRXok6v5jKWbZWIFB6ZT3EvIpv crm2Qybxvrp5GwB4FaUe+0IwuMlrt7Nr/57WTqgxeeBMWbHnudqX2QzP2nnlAWip3YQ1hWj288b Z1qnRzc2C8S+eR56qcAPd+xN8ehs/n1WzNQoBigXXbJsh0zpVZuML+p15GEH7JvEtV+4flx6iPS CkEahgXLXZFJ2i7gDa+tWfXPO1oa1cb9uhLEkZjEsy9YivBOmmEhwq9pEterizqrqffP1EIco+L BB3Q5mqhJTh42+i1oRVDrcN0dL6ZIc26NI0ebbBKUuHZLlMPppsF8x3jg88uZjshvwaQy3clEhP pcwRf48/nbMiSaaWvl0/dXNgrZqYPrvUPGIFr+j+YMLVod2+74tum7AOc/k9/SsUcoQf1BkFYV2 5+ViK1n+CwdvbBS4VPeoTroO6YiPTB6sT+id3YIgI03yQmOQJTsRr63Sq7a+f+IBwVPuo1ZMI/4 MGngXtkquTEV/Ufs0sP6D5KmOs5lhGVe8V61h+N2r9MLuKIlV7CaoBGGTQ1AXj0vliWDltZnVQ9 FRJ4QYQFsyln7DVORfE+luuq1YmutyoC3G/JgnSjtoGOp6NQKrQGWgCV0gNIYa/Khg9cPcIIMRn 82LCVNRhRdI+hPkIHNcLNlJyBQ9A3IHHERtuJDQMoJN6aq5yx1rhbOUdGhWZEZHiX9FaLcURoCh bUPVdCZrmLuct/5rbnfMfc0bmmHR5cRmENMEIwI/kLljrCoDmcMEGfSBZEEqX2I5+xVAyUfm3j5 baYXlzkTjSX4WXXx70pkCY7QNymW6im+/neA78w3TMV7P+0dqehuA6ohC+2puIkyZ8zOm0vfbte 7vFXlqh2eV38TBVT0umIaw5mvv07+9S0OOzdDrR3iix1MWA4iT00h3wi1y45KHrbb6blZHECBvO f1crFR03SpjFqiSkjGezxWN84lPMTZKQ/dflmxWhN4yYVJpVadSwJoY9atRVI0QI1cdvO2AfDdP IwRtrauRrYdEVkAkr5H65nxBkU2clHsIdQDzTB+7npX0KUsokKFIe+Yb/Ofko7Zz1jHBaaPig0u 6Ul1w8oRWzqREQPWeKRd1SEziC21DZ4MXIuzZvpH7/W+LqXzC9DvaJOCHY7fve9cMWDW9AuHvAP Mtk5/NnekpUKit4acfIFn/YcUa3gN3uUqoC2x2dZ/GrehDM5Ff8I/b5fqxBB42tJbUWIHwxINT+ 2iXGn/dpKxV/IRtvo8VRlRgwaKILIn9MjJxaugWzsVvxDuxDPGB9WgnelYOgVL8lt6l8RrSf7cE vdIDfwm0rzd0xQMGLwlynCtIOY77XRyOl1SR3crHjNx4H+R7nqF6jMGBS59nvlGF/CC7OX84Zxg TaUXPk8hrR4RB7elhBR9azgadnqDfAbvoHmjv46xRniCVJywrgkeU73FzU1WRLT8jrECDLlnLVv pXMyMB6L4I5rrhQ6R3Hc095SnMcSWTmFSOwFs2hsrkzEfJhWZXRhCeKWpe0zFhHRz4MUY5Rf0ww TabYOpRWhMK6CgA2l5tFc7r+SKxK1v3i8mZ3sB2TptIlfSVU+iQT8RLEdJjWC9BBqW76a03u7Yq iUr6aKsw2z+AN/ZnuLyZ3YvWLHNdCRmtZlASMZfoa5K+FfkXUog4m0IzxHzy2dMOpDXsi489oiX +8D3L51Le/K9FR4xjLo8TMAjnoS2KMrKfmiseIqIMJfcECcKyM8UJrECkS+GC3Hu9g22bsyoJHE LwYu7gKbElItj4dlj7RRv7DXYPF/fJiUkcjK8WTQ9geHKrcooe8DMMMNb14Z5G27P6ecZaaHL6F M1ixnkIF7EMXF4EVlXo4dgSF0Ozc+LF57pYVc9x//5kprQ35Va8Cs1YJTooS2bIuZEzQx9GxXig LG4yQvbp2q3dQxQKqovdOp/c3yZfFffBQsOPCUKsnmpEJsKhUrNEfzuylZTk5/8gnH4//6wGD4m kq+2VLi2YNBj/YCBFRKTQLqUkiZKRjeyWakBo6aVS+rJS/gQD08DMISiihNK6Xi0bxoHV0le7Ag 05q3O+QuZEjPjZp1w33nwv+ck3uqPsH8HQbvEQnkxFidEK/9vXQyB2EZkWfTYuNvWPRsBab2f+i Om0nUh6Kg+xHZZrX7hfN7GMvAx7jfBSYoHSCuRhZuSMYwXYWadBiV4KsCNAOm5PqE4p6DQmYxut m8/3TzkR7m4fEuF/E5qHZ2vpkWI4MTGx3uYXf3dLHd+JiEorXL+HzR/dPhaHTDL/XwenhrGZSZc /YNAXka/6OpzN/+oP7zmEjLcs9RKqtRlipmjlusriUfxJ5wxi+xGS+xyrjXeXlqe3EV0JVdVSJx 0iqR94g9PX69zuBP/rPNxdQf3od86mreh0ts5ul83KmUK0xpTOQqLAZUuckeC6pmA27nZOdjoMU hySgzTu32gAwXyifRQc0wE/EmZWRneLgh45QecDE+glcGY8rn0+P5dMyNhlNwNwbgpc8NSQaL5+ dM9Vq8+WtyBRwSjG/TkjEMY6Ex+hIASoM2D4Hs5MJ0AHNswWTATBgcqhkjOPQIBBggqhkjOPQMB BwNCAATLQgUt46GGb96T815H65I05ELw9siX91ZlN+vVNW9RLQm519BPfX+1Vk+HAviXMVk0W7X Srzd4w0i+5dCNM9rX -----END PUBLIC KEY-----¶
The corresponding explicit private key is as follows. Note that the PQ key comes from OpenQuantumSafe-openssl and is in the {privatekey || publickey} concatenated format. This may cause interoperability issues with some clients, and also makes the private keys appear larger than they would be if generated by a non-openssl client.¶
-----BEGIN PRIVATE KEY----- MIIXugIBADAMBgpghkgBhvprUAUBBIIXpTCCF6EwghdaAgEAMA0GCysGAQQBAoILCwYFBIIXRAS CF0DbAQg06Bf7QNFSwSLF1Ven5lVyKCZoMQQM0JJuUP23mWccgkCYK6iOhDmkqybIASjgzCUhVZ FDOEPKot4rEOPa3J+Wnp1odULvCAUvzIbi9DKIk2xBJVvJI6oS+WBq2JwAE0NgVHZ0BBhUYkYga CMyNxIxF4QRE4YXN2UjKBhBcAYTBHFyBXYVJ0Eod0CGIzGGCERBFhdXdRERMmeIB1FgM3EQc3Yg cgU4MlACVldTh0NmRANSUkAEFIVBdzRgEVFHIgFocRZYUxJERUE4gCg4KANkaHESJwgCYFFDUlU 4gHhmAmYDERd2NWc0MIhogBSBUBFkZBhjBTIkVXdVNEWDSDVVUTVGcodzSIaDOEEIMVFQUgVCNy IQcCBAEWVXYmUFaGICcyInZjMgQIZIUiYmghEwdGeEgShTWEQ0KHAnc4ATAkNjBYVEFWUUSDBmK BCENTeCh1VXY2RCY2JEJYdDQXMUeCIRAhEFEDNiJxIWQhMjAAAIU0UCVCEBIxUBZRhDUnMkCHQB gYUjESZ3FydCMVBFZ0YxA3IwFRcxQ0d4UQWGQBAYOGQzdSQyV0EldWV1A3ZmNTYmaCBxIjUoeEi IQYEoNnMAZANHJBQFZQIxNxiEVQIYCDElGEAHYlUlFFWDVIMDRgZUJzgVAwdnQUgicAFwRUMWYw VDZkEGRYISMXJRYSaIF2UAADcSSHB2RHAEdzCFF4ghRwdyUlUBAzhGd3BHNnFGAwMHZxR4ZQUyV YAVUHcoQQMFcGEohGVQBzNVZTQBRiJVdSgmZXF2dTQxFnRkIWBDFFeANEMnEmJDFVVxCGUmVhch JCRHIDUlESE4iEFIBAZoUhFmcEgHIBA1JlAUiEAhRXIlFUVDIkYXeGI1IxcoJCd3dWB1FHA4VzK BRgN0JhByc0eFUVQlBRYIRhIoQBdTNnE0YxVYCDZjY1gAeDFlc3GDVgI2FoIYMSOBZQhIgBeCRR iBVgMDYoZ3dzdDFxFjOEUSREEldTV2MQNEhShTYkNYIFMgNwJyBGIyUVJnVoEzhEEWF1KHFVASe FUEF3VhdmIwMVABh3dzMDUIBTGIQDFRN3doNhhjdldGgjhUZXgUQRg2IGZVZkBBQABGgEUAhnVi hTZliFAxFwcnQVUVZ2IQJCGCISYxQncFAnJ1cxN4gDZ1ZlIRVjM4UIRIRTAnIRd3ZCgjdlaIFCY mBlVQNTQocIKACBhTI0NhY4NVElBgASB4WDVYQziGAhRyR4QDdChhZ2B1ZBFFciUxIQYFJlAgYT Q3AQhoQAcGByOHNIYGiEI0hlERJxghhkIyYRMHGIFmYoZieDeCBXMhd0IENTQlGFFygQdyBmNIV CITEQFXBBUCUxNVVigGgoEVgDByhwQVBHcicCJoWEKAM1NWcFJCYyJBRzcjNARHEUYGgoUkVBID F4MoaEZ0gUODMQeCQwAySCIiJmhgBmBxJVFgJVZyJ4OEB2QQdGdRgSJUB3Z2BBMHECQ0YXCEYgR RWBAFBWUiAyM4hwIwUkBgFwc0I3QlhGYxECR0QQVUhRIUcjEihgYxiAQyBySBciB2SHQoJRVSdW cyUAc1N2hRhQMGBVQwJFeAcVNTA1gEggMxSEUGd4Y3FWSFcnRRAFGEUldChUcwWEFnEigVZnZTB mVCE0CAMkeAFSEWWHUShEBXYmUAgVQkhSZCaCU3BCdFMlZnAWUncwJShThxYyBTgzcYdoVkJgCB EwV0BmdxAkZwAxMGCBgBZYKDdzElGBEghBUwIzBDgFA4OGBXICVXFWBSd1glEygSVDJVdYBkYjR mAlgkNUJQFoUXQoaHUmR3CEJ0KDQWRUiChHMXh1ZgATMBJGZGFhIiFEcyABJmZkSFY0UldIdygi VWMmhUEocRhigzJAZlOCEhAyB3EHZGUEFDU1GIeHYjNgNII2dwN2JYc3NFWIcycDJjdISCOEIhN BCGElgoUYMECBAIMEcGdGWFWFc2h0eGERM2Byc2Q2UwQXdWImZFKCJhRVaFOZ0+KDXUoj30jDGs YL4L7KEAuevyOLifPNDnBY/rrg6GB81xNpsdKdjg+osRG0OsBNsmnxkg3nALFodEYQ7Z9Qyx/np 5rreYJ0oy77dXuc4DoHaOxtPuAMOn6aKZqBtUktyInranRPjubOSe6isnInZk7IMom8egOvdCeF TguF+WaiaFU0WCZIghuUQxYqGJ34QmRLSwLT4f+uHoIV059jAzuG2E4c+2bGyebTCKkzkahMNGh itzln03fRygDMTJREy2uvzxb/pAZ4Tewp9tVlP90Lf33cyqvwJBlj+yv7HeRneg6g/6GOs/4Snl 4k2Tbk7iZdn7fGnjqf3Sdiz7pNECCHvAF/TPnxCYA41wUD+gNUnaiz8Npk9N02V0FXi7NZKJQs/ lVtIuToWlVHFOx9gswYiCmUS56mqTiLs/KR8c4zF14NnvQiakpl60tKntDkcBUZgoruDJLnLH9n yft7TQlnRb4NG0hjv7s1uY/EnT3mvgGHIJu3Tb2sqlHLkVLsK19rsMqbF689svN6WCZ38jNsZJc FPEzcCE+fb91n0mWx+f6Ab7OSm/CPS1WmoMHxi3ad2QT93f3EJqfNjOZiiTDKPre/ybYf8EBi8A Yv8YA+HJn7zduecMIu0tEVkEnUqTm1Jo7UJPXO//R3TSBgcnX9AwBgRagP6/gArBVh9j9Bjd9OI fmS1bUY/Bz4Yhoal1X1rpTfSzsw/ZXcEpM/cYRUEPaFNsNcFUjUi4t8e68fp/CciGXkLEl5LC8t 72or4gCSzrzOaPwnSB/HVSflRtQPqD6i9QbR71QhgvtF+KeZD2U4iLaJf1fDUNqXa+IXNy64YUR cMuQN28uB0ewxUn68UdRMUIjmq1kNoHr4QH6J6IEhC6ejjbNkDPvoRrIuoIsJ1rTPoVPEpzToK2 cNlqWjRHHPtT7qH08xIgP0Hsa+8qa79vBkmqIUcRFtNdhGfv06pFwvJa0B9dTSxfXIO8iO3LpCw Daj8W44gwx6m5MXaMLXnjcwH4i7vf8k47RpifCr8T2V8D9iCKNdFfd6FdHEZfkCjbe7/aVU8jST 2AUrGYCpgC5MBkSV9IoxT05KTC0ut82Ni0BRDi+LsdI3syNoARoE0BqQTuF5XEFJVe6MXzmZ2ig XfQK8aW6zZnHwW9TtlF23YR9ozDN0fFkwsoMd8qeFsgzUOo1TYi8w1P4FnmLp0NdoRDf/gX+jBg Fs0CWSYZAYubIR5cgDPN0mwlQJDW46sr2ATRabjJ0A/N9ZhxdWEV1Qfb91z3JixpUGjQ1cPhBWb ZnJKCMarCmx9rNjoGo/WJ1iOilahBihCH83k+hUWFwNNrTZSm+TnzlObpu9WgE5g0e/QzQrsIO9 o3s25BQqJAGiRKBLd0UXz5AUbSB9fFaO21aiX2WWISjdA1R4SuQNNQZcVgGuKpQBAcPV7xcFRlZ eyCOw3/AA+WInx8mHjtDcOIowbEG1HQzV4CTsAelNp7I8CtXsXL539wiUpO8A2Fbh2wqTbe1W/K DSM7VPezIBE9gFPIDGJul1YyyzGON0ukKAHWmAiUuoBtlrryFFEO1Cnh01aoP41vMWMiqM9Xi6T /oeAYdAyY21G3oyKV4JXrNufFNyhivCRGaptCKDJ15odOe4ZXJ6BIaU3UBz+cm85OOAwHq1FoFB XwEuLU95G65QHzukC42ajwAhVLjcRudqNZ0Nb4vi63NiP+ZVrS52vZJGSPa6B7Vss+PYsZKp+OC j54Y5Z1eU+Q35lnLLSKMOkLTkCP3oFxX8mW5hnZO3ysCkytBC3CRe+7dxTMP0XWDT5LraSphlAB 7ocMAKh8mSPYhqAAaAgekjmvPDMbIezv5slR4M1/br5cc4z/01UwKV2qkT8DQxM9vkHO5XLomMD DRJXW1hUnpjhOrOzMsiTJ6aQ/+z4dBjJxR9a9mYfkju/SEk3V8TX7VmKQk7WpKTt6b2xGiQcBhM 5BZBouYeNZ1D9Bgv6CyME0GIjf9nIXyq3mNs4ALGgheo+RIcPXrkhVZgdZexEtl0N6s0ynZgbBe o/baP1pV730vAqIgbwSerx6773sqSorU+L1HL1XQrm4EjgzirKn9/IMm+gz9zYRZy1RdnnKvMwo +mV85fOOlUJZZhdyOKEXp+OJnez70Y7iHnmuqvDlX8aQXzPm+ehXohw4yiLVhcENTQyGRjR0pFY 3SkW0OyuVMysYMo6LBAejaoKdCbcI6VmRZOPRWXbhch2Pv29SErLsbJrSSE0JAdRIZZKW6IqkKM oGQ9oB72br5mSFeg5tYMdDSgqyOVqJmFNB6PzEvKbke8AwAiaZSX7tteP8LVxkIJPHIaBAVVWij olG2Oe/eDXbyz0ZwbomnHe7wzyGc3W3LmpbnP5wF2QnIRRrLnBQgwvMpV/JuGkdcWc4awiSwEZl cvAhQKCUWvLYgGLNaa8fh61OVOGCKymMt00w7/RGufPKaunCzlei9JF0IKCZBS0LzOeVMhP9lnb jjopJSP6Mg1RPCTHD1caQ6NT6HVrv08SmHCRG+G0szAEpC72sXjeYkra+1bwj6RCw49uzd4gZ6g Ruv9/iN5tx0CW6em7bH1K30UFMDEB/zTsEBSj7QkdZ7TLItDIUY/ztMu+La7zHfCFIz7OpN7kYw xLDax+pAC4mBunet/zOyaIc1XJozwTz+HmwAorOlEqPklXNJ+78VKtDih92px9K0ALX70/akq+b kLoxqf2NfLEd3YOJhUZE3jt3KYTpqohzJWAG9e+2FNXMqSrTOY8YZq4HThTxyWjvNUX6iQYc6OA N17XenbHp1Cfdk4Bc8mTheUocqUOtrRFWsO+XhPJXSv6XXwPgbyD0Jr4xMQ7ni/vfEZuR6qbb0s +Hi54aEsF+2Y4WfafOFQvRNcemC8J2rMJenGbCzfysU1wiz86qizoGocbd3OS9GqPy29dupfFKX t0dWnFmm7SHoqjtpbyjr31Q9zSt271gxepriull6rVegURHtZtINi6LHL6yYCd3PQcFdm7tUpt/ D3bAjrvOIf23rdQpahyIAE+xrtamDF/0qjirz8XBMkNxKgXbA5hgyhBmvDU/YjGxIhyOZj7tQgg XnyDiUwdxO/i0onKxh56aI9sPUptY8AGOArV/1DZ5gJqjcF9BMs1CTZTGQiReyL/stfgkDcUvbb a3+K8beH93CNe2fYYOPIVc02fY9kD85HW1ljtsm6caRAHZl0IxXWpeGbmutqhuWyWe6uVpP21rt LPkJFRnpUFcVkJbJs6nUspUdLE4sltzEjykqjPoBKct7rGRSCK6A7jBTrqArh7yYPMcm34bMyX1 GjvT9pzm8sws2wEINOgX+0DRUsEixdVXp+ZVcigmaDEEDNCSblD9t5nERtIufPxKONt/IRXok6v 5jKWbZWIFB6ZT3EvIpvcrm2Qybxvrp5GwB4FaUe+0IwuMlrt7Nr/57WTqgxeeBMWbHnudqX2QzP 2nnlAWip3YQ1hWj288bZ1qnRzc2C8S+eR56qcAPd+xN8ehs/n1WzNQoBigXXbJsh0zpVZuML+p1 5GEH7JvEtV+4flx6iPSCkEahgXLXZFJ2i7gDa+tWfXPO1oa1cb9uhLEkZjEsy9YivBOmmEhwq9p EterizqrqffP1EIco+LBB3Q5mqhJTh42+i1oRVDrcN0dL6ZIc26NI0ebbBKUuHZLlMPppsF8x3j g88uZjshvwaQy3clEhPpcwRf48/nbMiSaaWvl0/dXNgrZqYPrvUPGIFr+j+YMLVod2+74tum7AO c/k9/SsUcoQf1BkFYV25+ViK1n+CwdvbBS4VPeoTroO6YiPTB6sT+id3YIgI03yQmOQJTsRr63S q7a+f+IBwVPuo1ZMI/4MGngXtkquTEV/Ufs0sP6D5KmOs5lhGVe8V61h+N2r9MLuKIlV7CaoBGG TQ1AXj0vliWDltZnVQ9FRJ4QYQFsyln7DVORfE+luuq1YmutyoC3G/JgnSjtoGOp6NQKrQGWgCV 0gNIYa/Khg9cPcIIMRn82LCVNRhRdI+hPkIHNcLNlJyBQ9A3IHHERtuJDQMoJN6aq5yx1rhbOUd GhWZEZHiX9FaLcURoChbUPVdCZrmLuct/5rbnfMfc0bmmHR5cRmENMEIwI/kLljrCoDmcMEGfSB ZEEqX2I5+xVAyUfm3j5baYXlzkTjSX4WXXx70pkCY7QNymW6im+/neA78w3TMV7P+0dqehuA6oh C+2puIkyZ8zOm0vfbte7vFXlqh2eV38TBVT0umIaw5mvv07+9S0OOzdDrR3iix1MWA4iT00h3wi 1y45KHrbb6blZHECBvOf1crFR03SpjFqiSkjGezxWN84lPMTZKQ/dflmxWhN4yYVJpVadSwJoY9 atRVI0QI1cdvO2AfDdPIwRtrauRrYdEVkAkr5H65nxBkU2clHsIdQDzTB+7npX0KUsokKFIe+Yb /Ofko7Zz1jHBaaPig0u6Ul1w8oRWzqREQPWeKRd1SEziC21DZ4MXIuzZvpH7/W+LqXzC9DvaJOC HY7fve9cMWDW9AuHvAPMtk5/NnekpUKit4acfIFn/YcUa3gN3uUqoC2x2dZ/GrehDM5Ff8I/b5f qxBB42tJbUWIHwxINT+2iXGn/dpKxV/IRtvo8VRlRgwaKILIn9MjJxaugWzsVvxDuxDPGB9Wgne lYOgVL8lt6l8RrSf7cEvdIDfwm0rzd0xQMGLwlynCtIOY77XRyOl1SR3crHjNx4H+R7nqF6jMGB S59nvlGF/CC7OX84ZxgTaUXPk8hrR4RB7elhBR9azgadnqDfAbvoHmjv46xRniCVJywrgkeU73F zU1WRLT8jrECDLlnLVvpXMyMB6L4I5rrhQ6R3Hc095SnMcSWTmFSOwFs2hsrkzEfJhWZXRhCeKW pe0zFhHRz4MUY5Rf0wwTabYOpRWhMK6CgA2l5tFc7r+SKxK1v3i8mZ3sB2TptIlfSVU+iQT8RLE dJjWC9BBqW76a03u7YqiUr6aKsw2z+AN/ZnuLyZ3YvWLHNdCRmtZlASMZfoa5K+FfkXUog4m0Iz xHzy2dMOpDXsi489oiX+8D3L51Le/K9FR4xjLo8TMAjnoS2KMrKfmiseIqIMJfcECcKyM8UJrEC kS+GC3Hu9g22bsyoJHELwYu7gKbElItj4dlj7RRv7DXYPF/fJiUkcjK8WTQ9geHKrcooe8DMMMN b14Z5G27P6ecZaaHL6FM1ixnkIF7EMXF4EVlXo4dgSF0Ozc+LF57pYVc9x//5kprQ35Va8Cs1YJ TooS2bIuZEzQx9GxXigLG4yQvbp2q3dQxQKqovdOp/c3yZfFffBQsOPCUKsnmpEJsKhUrNEfzuy lZTk5/8gnH4//6wGD4mkq+2VLi2YNBj/YCBFRKTQLqUkiZKRjeyWakBo6aVS+rJS/gQD08DMISi ihNK6Xi0bxoHV0le7Ag05q3O+QuZEjPjZp1w33nwv+ck3uqPsH8HQbvEQnkxFidEK/9vXQyB2EZ kWfTYuNvWPRsBab2f+iOm0nUh6Kg+xHZZrX7hfN7GMvAx7jfBSYoHSCuRhZuSMYwXYWadBiV4Ks CNAOm5PqE4p6DQmYxutm8/3TzkR7m4fEuF/E5qHZ2vpkWI4MTGx3uYXf3dLHd+JiEorXL+HzR/d PhaHTDL/XwenhrGZSZc/YNAXka/6OpzN/+oP7zmEjLcs9RKqtRlipmjlusriUfxJ5wxi+xGS+xy rjXeXlqe3EV0JVdVSJx0iqR94g9PX69zuBP/rPNxdQf3od86mreh0ts5ul83KmUK0xpTOQqLAZU uckeC6pmA27nZOdjoMUhySgzTu32gAwXyifRQc0wE/EmZWRneLgh45QecDE+glcGY8rn0+P5dMy NhlNwNwbgpc8NSQaL5+dM9Vq8+WtyBRwSjG/TkjEMY6Ex+hIASoM2D4Hs5MJ0AHNswQQIBADATB gcqhkjOPQIBBggqhkjOPQMBBwQnMCUCAQEEIBqglVGEbVW2JdupT30vKPECOx29/9JjP8kbw9GW 9wve -----END PRIVATE KEY-----¶
This example uses the following OID as defined in Open Quantum Safe, which correspond to NIST Round3 candidates:¶
https://github.com/open-quantum-safe/oqs-provider/blob/main/ALGORITHMS.md¶
id-dilithium3_aes 1.3.6.1.4.1.2.267.11.6.5¶
A Dilithium3-RSA public key:¶
-----BEGIN PUBLIC KEY----- MIII9TAMBgpghkgBhvprUAUCA4II4wAwggjeMIIHtDANBgsrBgEEAQKCCwsGBQOCB6EAD7KvTpq fJ66NzesNkOiHBXWcF5FYs9mBugtOHAUrl86Ns8l24jV6Ut+TjYd8TUbUClNoWhGe/v2W/gZ34N QGlUahMxLY68nqH2BXO5bjMHbE4pGGGuNejGJnJoe+1/kd9+Mym6LE2YpAZCKRtgka9wXR3i/MO C+qp9OHi2tt9cpur11mk6NPWjdVMqXxOBYgeWESR5k8fYS6ttRNPEC2JQ5ZtNMV1srdov+mjWRi TmGIXWUwXWEI/5LQAthtaSywFPHj96+kLlm79lbYeaVfSN/URojQZLAq2gx0DFK8m5ZA9GaRQZS L3eavfzw2Kd6pOdFNemTquM/i7uGFc4/Tt2JOGjatLz4u9UvvO3pLUxU2bohd1vR/FwmB/9bgwL mmtdtrP5s2N+/oZP/kBYETHNX60oaldO07yxog3V6XbRybCLmGi8wDrSwNeIMrQEurKA6vBl+6O epfMaLjGZKMGqAZAPy+Wz51uW7diJOHx8AfXoFcj0ClUHaGopxgiS93rQXnDcTGn7JSIqt/tW+T Or2v3BuepZThd+guP/bkDBqHbrBhHtVsjPp6YMD2Zis8gT4c+9DQYKwRewb829g9ZmY3cxhNj6h KwVypB+/RUSOho/DWm32a76xQOfDODh65noPoPqtMBOaoRyAm2qbFPztPhP946SAy6SWD37dZ+t 8k26vJ+l2vzMqFR+pOymYFFgwP3K0OFaKf+K2Xh5luhRVg+Ev7BI2ejBOFh6TtjX4ljTPw5mNQ4 1wnMD56tcGFBxMDdnEJl3ekCPPwcDBLZvacRIJjOUsEPvybcY04FVADSXM/jSkZpW9BLNR5brET 1FTXIT7PMN6ueIhAdKDDHgYNN8up7ZE7ffZBByIXnXVil+Xt6CAXOV3YYRtegHBT3bl6SZsHxfE 9atK6UX0PzT6LqVnUjZNAJfWnE7GSiwZL+E/32JXMkT68N1obDffi7Nyv1NqAmGqF31wWwH69+E YV5JE/mHUxfInpG9UeNvGnLVgus6/O7X1b3H4/BglqQ9BhAz5l3rStt1tolpOpI+HErKKc5CXfo /vT958tgObTjY2LHSY3BdAYo85zLnwAE+Hw/ZA37NlnOl6YXhEjNI7SuAw7hcPqO9LPgoofk7oA DU+iGR28qpmfYDT8lg0/FKRqsufHvqRon1H8zlFF09Xpi0u87JnVSG7e1oqNBjrfLR3/5iR4qP0 avcFaFAUpM+CGVX8lCL3UYEDa1wK29YxnkU/9JY5NIERb/FZagWO5yXv5gJ9+E9wWY44moU3vJY 3P3Ov5x2+1bkhiAdmSUCUo/wU5eK7kntlpU/6c/lCN+VPlhht4neI+NQkmVZvbbgEk4KD9qA+Fe tizPH4tdbAJCwRR9UMuNPdgwnObVmKCgwGZmZr4ZSDpDmdR7XdPOaJw6hiXxvr6xAVuvVNrHfcV LsiqdKop4jG7/DHOZOG30/LvyOutt9GktBDCnIPAE+7/JHK7Gn4FGbOt3VZxW5L5WWiRxzePYX4 urjt68U/sQYxJRMqopRPhpGnguFAw6Ye6wpyvSg6nkZjeADyNSYn+W66VR8IZafpnfGxFtnZRPg GiE3UAxL7YvP7AeG2APYepCtTnNybFPHQPkHSRtn4NK5BenrRfGBT/+M4WdyYQ++4Kn5b8KoDr2 HeU2SqNOru0VvEGa10emd6YOe2c7NgJGNcp0OeCzYsNZxLoZJru3CMZ3+w5uyf2TEaCEKwCM0+F NYMTS7o+KFO7N1AdEG9Fz4HeIs4VeqOKFRf4+brBo8xK8AV/dT3aXxORz6TRR/wTNwKDuctwJQv 03Tq4X+db+V6z/4nuyzSU/G3e7J0JtcuMgkP6txV2GVZPFMajwZckg0uFZcu5HTkXJsa8x/JWRC cLxtzYin5GqRaOHYgksJ93ab2vTW4lvEUlxt841mgICndnUa1NSyC9rw04mnaBSHBTFLjyKG1FO gYoeRkE9Lj/VCmmr1v5P9/AK2Ui5lGkV4ugsBOx6dqK9TuZ5uSaAa3fvgIVHofBKckafpHBMpcd AWFUNnv3RcSIrCx6IOduGDJr8b3JuQIxCLg1u4HaJuSCqsINhch8B/4NTz72YuTzDfh3cGHfvmF rcxYgp4FTq1lc76nC7q6fbxMaRZVfjqcbFCTUbBVtg6mUapmDh/Ao1VzXUMml1JdBRqJhBfNcKx kj8oJ0+U1wjcqPcTTCvHljuMmNtLET0AVdgxSqUA1q/qg3dazHJ5YBDKt34a5cmHQeXj8pXNalH hOpSSb2uHlau3cfxPTRPqhfKnkDPKFPNaqTNCF1Pmh/xDzbCVNaKkPK+rLQW7p5VpA2cGCNBj38 eaKwVEccH+NUmTVyxe+jH6QZdQa8GuawW1JYo6VSJGJycqmyVWcvH7m9ZYQI7VObfvCb4D861QW IvkeytKM31BkHsxEEraJuI50AYxIs+1ZX/bz37IRBLq9AivLPCFZ20crOPT+IS2v4Dn0YIfDztx UH0lDfZ5b3e9QBsFVORp3o6Hw2WewktGlPHCfDrYsm/t0Dv368Hbq8HJCDdnw9syZCjD3mBTnYh 2HQiHSbViOvOUnD3saFHZeONsuNM+9KXi/d1k1o3Y65Ud0wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQC+G9YX1BboIItyZdjEnPeoJXh5J3UQak+lkO+KirllYeNQML7ent3l9KOp0tM /IfxSDmVWtyYAUoxM3TGnDoJgCCn5jUQIdQkPXTxa7xeL11W4d0fqyaAOyMOXA2QZShE61dBEz9 ly+bnIN1MrcwLe0q/TPuKS1EBp8LS/lQzW/PrHTnDHwoGinBZq58B/ErgmPh27QlkhamdXG4KxD dN2ayilmvdG06dMwrGKs2Tag5HKbUSMPA3BlKvvqrJhMb3w86xPf2MnvWzVWmi0tpE2zcCgXkX+ 4VtiikBW1QoFuFjiBWNJKWMXe2UKXYbdYFBPzaJiGCdiYXXJu1N16pSxAgMBAAE= -----END PUBLIC KEY-----¶
The corresponding explicit private key is as follows. Note that the PQ key comes from OpenQuantumSafe-openssl and is in the {privatekey || publickey} concatenated format. This may cause interoperability issues with some clients, and also makes the private keys appear larger than they would be if generated by a non-openssl client.¶
-----BEGIN PRIVATE KEY----- MIIcOAIBADAMBgpghkgBhvprUAUCBIIcIzCCHB8wghdaAgEAMA0GCysGAQQBAoILCwYFBIIXRAS CF0APsq9Omp8nro3N6w2Q6IcFdZwXkViz2YG6C04cBSuXzreoI2nq7/EVjqV0dVYtWemAk+TYAV dZpvQmMPkjQTbD3f4xBwlnQQGwyIaqV3uLMaSixrNDRQfjmbMzkJveKu+GIDMDNRhhYYFBQARSd BYWIXeEh1cRJjI3MkQhQTUmgHNzFTYUVgdXMVc3MHCERRREdWBXhCcwUBBCQGR4cRBghAVXdIZw NhJFOEYHVVVzNDQ1NYBYcBhoeBdWNCB2FxMkIGEhBiFzUCURA0FAUDMUczFmhhc2MgBQMnhHA4Q hRyEjRAcEByZ1FDAwWFFhdVcoZXI0R4N0UiRmdDd1NAFkYSJIRHgwgjJ1hwJ0N2NXFTZ0EjIVED Y4ghSFcAFngxMAIiBQJ2chBmhXgnYDQkiGZTQwZAGDc2YxY1hUUEMBR3MViAVjJHhQdmFgdERzU icYRGaHOBVDAFNFh4JWFXEWUHhidHU3h1aEMkBoJCEnSGSDETR2QYBBQWUYdCOCMwCGKIZkYSYX gnGGMRaAQWInAnVYiBSHEHYQCIUGcEMGRFMzhyEQBgMTAoYVBlhYgDRVhSJkUSgohxGCMSZGczI FVBJEhwMocFIGNUY2IicDYnR4BiYUB1KDREMlRYNnczNyQQFWZCQVEwBHYASDAFYRdVYjNDNXAI ICcEgUY4Y3A4A0FEZGZiUjFTUzAkQEUTg4JFNVRBU4RjdYcAZ1BCgTNGZAYDIydwJnSBVlZxCFI HM2VUZwJGBDNlWFFYZ3gGZEUhBIcGEnOGNgdQEmFgM2AjhDWIUGdVYmMRBzYCZjhoMEiAI0cCAI NkYwVjRwcgRyR2E0BXEiEEVRcih1KAU1dScTYmg1hXdUBQFocFBUCFCHZyQhVQYIBghAQRSHEhB CiCVVhoFEAEV3UnUCIzaHc2Z3QYMBIkQEAzJnMxd0EkCCWFM0VHAYgWBYMGCHQCRjVoGGdTCCiA aAiGdDdgcCFVdYiBQSUSZwNxBoYRaDIwJEAHBYSAiGRUUxYEUiZoYABCQGMkAHMjFBJlBFQBMRh RAERCYHICOGYAFUUSB3hRgzKAFiNFJGGAdFGEhlVgImchV1cIcUZChTYHg4hXEkFoQDgRhgUAUX MSMwgEMyYYAAAgVHN3FxBDgHQkCCNHNwZzVFWBMyQQg1AjYVN2FhY0hGMjdlU1VFMnZEN3MCQUB FhzBIEwABN4gXJmRhRDdQgkVHUlFHKAJBQFBGIGVmICcWhAcRYYVRVECGRXQFYjUiMYOEgwdVEH MEdERGZIdSADhIJQdDNHcVVxiHNjUVQwUUAXKHFxWDOIVzQQBQN2iFQUECQEgGGGh2dRKARQaCY 3JCZihyAnRSElQoIXghZmdgV2U1EoUQdGKFZFZBcHJAVSh4UHBYJyNBR4AHJXMnAIhABmM2FHRH RhUjRHgSEygXQkAXUHaDA4JCNYYlUVF1GHNAiFQDQyQINCNzISI1cichgTYVJTdEAISCExFhEYU TJ4B4EDI0EVZhJTREEBQFhGGHcmhiSCMoVEEUYkgAcHQQRhBCF1N3AYaFQoJjQBCFRSQQRggnNk E2EnNQUnMgVghRSHgjAoAyMEQoElVWdXdXRiEEAhI1UyMlRBJHeDAxhyIyRWNBMTFWaGdwUUhmA zQzM1QIBmRoNVR1R0EjBFZzUxURKIIFAUgRWCFkBjVENxElIEZ2EWAASIERYjCBV3ZYR2RYJyJi h1BCFzYQiCRmNCJ1EHR1VnhYVBZgQ2ZyASSDZlY0BTiFdodmgXEjAFQFFjNnUAUVYhQTOBgCaCQ XUiJjJDUUZmYCFSAgVigVcIg4IGcoI3RWEnB3GCIDJYSGKAZiMyUXBXh2h0IHAiZwQSU1UlZzcS YmBYFgJIEnUkV4BzNXN3cGQxEVc1coVgUkVSBGiHIHdCQgcxBoJmhxM1ZAIgMlFQd2MCgxQmURF gYXIGOBNyQWRnZlKIE0NjGDIYVxFSGGAmSENSdYKCE1gTclUXU4MDAAhzNoSV/oB1DjWBLZ5P8l QVd2ppLs7YI7BBTrICpkXQcPWX0jFXuibD+6+YL56TvIdb5Cn4kBeWVtJTIIuRyJVK7NbzKPg+e Njo49ytpj+GP8QwnfLuDlYY0v012JLonxvrYc1izUZbau5t1XU4u/FgOvXpP/HuQKxwBefhuZAm xZedCArFTiDa7pPKjK5TJPCuCWvpz0hOjqu01KwvD0EUUIUq7SmvWyt593X5XwPx8VSYaFqLkm0 cHNmFvGYAGT2MyBlkmsrZPjbxzeqF+Riias6fR/DT0CGHK/aB5BsKFgup9kEOnVEhDRlRHqp6CR WndVHV3PBvUBmyAJCOCshWzu/Irx+HzEU5raRqzs/5wwTZcZzahPx9Uo/4FeKWkw/UcjI+uxyIT 0tj0mZ5lLttGwfC2JuH+G2DHUcorccCwFnaoHJ7x9jf/cnKcOMFji4UE5CHVKnAEgwWU9neDJ62 V4JAY6nTKH6nZ953w2u4GMI/pvA8RYaylEhoHmHTSvH7xbFlAH0FkI6f3DuGD2UVMkk6+EGuC/g xp0gws1X8ZsKSECm+0/yWwtRmbyVNW0js/8thly5eet8ZaV4AG6MysyeW5Fp3CvS0AKBfzfO3mN YZAxzEi1OjtNtuYiLmXrvFm6xEewIQLBix7M907KuOY8wuRNIArJKzrGMybqjnbk2woBNFJV7Uy gZel8xMX0dWvcAbBm0K1wxv/n17nFZ/rP2BqGJyA6nGu7m+vREiUdahK9YU4xAWGwjb0oeHCE5E kWi6RPEGhVgWmlcVkUGBvWHQYdiSTu5plMAPBeWVZneGwbVZ3B0ksLXfGIc5lTcReSGyeCVK/6W mE/GtH92lz0fC9GQWgdyTK4H23xP5PlRGlzVLJ5CVA/rucNg6F7AU5bycpC557ugsdO+UOLhc92 XTl5RKvO4uxrqZw4OOzKXR+aZFaY7AvpPSIXYQRxk4dHAW5ra8MpI0b8aAJGf4fE4ad2w6rgpRf K7NUIUOfpBhX9QxcprPyXsp7AfQsoCBs2ipf7QoJNu6GkFCFijTFxBAt2rK58QoeuxYVjQidrRg c1AtYhBFyY9OronGTsaEtpL8goTptIX10f5YYmjmTd4FgB0Iwiww1Re7/G1eiRARzp4M1u1VjgA xp+1pRZn8mpx0PIDMSfRieoicAcXhjMgCCwhxf79RWlxUMpKU3xFNVN8kcS1XXy1OUt6myApnjN 2SzUEJT0l/zT9ni/JhDhAb9vd09ab9DWGifhIyOkoq2Cg5AlTQXAwI3kDp31gg0cDP1O1j0D69w pzmFlo1UT8MauxEH4h1AHWvyM9Eiul90Mkp6ofd1gcFC3J4fSX4y8Ut4n4vyr00k1UVKthLIlg1 h+lDi6KZBl6v2U4GwLyU5bx8O5j/iUyims+sxjlsKap4YWLK1Z1EMnZUwLyKgeUBljTRokTEVSu 1oMahgoV5W5FjNV//mTsLWQvQWKelX5qpCvzTXIOS9T5Ucxex0/7lFn1/k/I1Qkr4FQgtDze1Gw rppntEHXj6qcpypsQwPZ1aGwBNvbAlwbX7nt2Vz/twx7kVInyvB8gROkG5I+SAPiTLCsritC/Js oyeyEXvXPm3SbU9bgCrqxZ0uDue0BrfdZVagEpL0Lbr+TSrVVNLv/DBfQsYD+DmMF1ZP5BkTqXI l9eHmEReQCIiA4kx4GSjtDpcQNil2m62jlM5yVqa5mpDKo7VvOMAM/FZehEWqtEDDwP4KC9AHFq kVhpt3/4ZoT5HX1nxaBlfm2Ts9i0VA7SJxY0HRRI72mcFbxlm2bvw+ntiX0La+UUblSZlafu4F0 xDYAC9f9oAssAkaMgbdgi+GNQh4msBMI2SEDdC9iOTrvbx1oFlySi3StSKND4iAxs6c4IxY/F53 THVCPd06SFyrqYW8A+Ex/tGfeKX8rfZVnkMaNScMpxytXd16nlvDxWGT9RvNuDLY5CzQwz+ng2N OirCkx655apuXisz6ELRFvxb6MI0FkdlO87MuYQ7Q9uGxZE1QcRAvIoqTzl+E4IoALr0sf690M2 V4m3RMvALIPsCJVrXou7SUUKEwhozYXyVe83OQZpqeQsB57AiCA+YXAv20Fgp5xJQerU90xuHXM 8p0zhIizEDiRWGt68IDeqPjcvU+0DWxEyHqUvBZe2vmNCpV4CFodMleMZ3LzP9pBUM4kB5Co1ny Wzz9EKgPAZD8gYUZn2bSxvX8zsBEkW0D1RAZMsEex8c2Hb4jJiiEqwhyLzysagU8nFdNZ+W5kgv Dlk7k3E9OSh7PuBKCRZXd7cVym0NHTEMHjOaiPHsgUWB3oC+D9e088DUEYe4cu1Q36Bg11Vg0EG YRwBgnt2OkWzNKRFSN2mPp4fUY/3bPWVqOGQZcclhzVSNamMcpGWTjtWfb6utfAktCR+fhY9say X0jsn0D29PfLndlw3syxoi9gAwy3gFCvlfTbY+n7AbmEO+R7CKOXywqcH1vIUfHtWUaPqBk0/6N rfviLXewdS9xu401eIGaTZlWIePIwE1pK0nedALw1ABGnUfFm7kz6UDRA59X1BXb5oAXzzDYRZX IWPV84n0XVFaFW94glkwO1UtUtTioUUTaSAXvh6YR0kxMhByHkDHpQ+B7dN25hAc3rYA5NulK3W bIyNimLOxyCx3v+ooRtUzmseT8rvS1dBdHEvt5AbENG8oFWhyquwN2ftEDGRqJs927RxvWBOp0i kkak7vyiawuFqU9iMUyQ6Pcp+tOvJ+m493C5H3s8L49gfiBiqr1hYZuFqO9u87wTuVt0eGF0grm EfOKKdiWj/+cvEID4XRE5ay66/F4rHneLn6Ucc82Z1Ga1BInqVUdD4O+4mGt8z9FE7p2JkFcdo6 uKFxvFtsVq4kyYg7S/t2km7HkIU4Byqa6EGJPHbxdOX/0gADEvovhNHy1WlZEpinPEKTP+jiAvl T5IeA95LI0GP2sv3a9ZX4JUKFq+pAB5t7EwcGj9/htQ1MOKItwAGgYJvTVKmiCgO48UxqinqH+j qyDKcXNC9cqw4SVVOa9ulu7O0EgARObu0mxA1PMvJZ8VPaARQl/vVejgnLUUqoqD0zaZprt8wQY uUbkSO1Yr3PUz5YI6ldIuutuplG842+FfW6oFU/cfsD2Rp0Yxq8O/gzOKMR7KFhhi7sLKs4xSwo RwI1Rw2cUtXQz/5SH936SDtdgoFTmeugaa/H+O2hIbUJGQ2IS7NT3NG72HhNXe0qCq6v7ZRMN8M SaDL62c5RwhpxVJrqGpr1u+cYupZ+YAZfgaNH/ePo8BZRDgurCtSS0QH82/2UUfahWsPVEiUZXX khmVheFRhKqGD7KvTpqfJ66NzesNkOiHBXWcF5FYs9mBugtOHAUrl86Ns8l24jV6Ut+TjYd8TUb UClNoWhGe/v2W/gZ34NQGlUahMxLY68nqH2BXO5bjMHbE4pGGGuNejGJnJoe+1/kd9+Mym6LE2Y pAZCKRtgka9wXR3i/MOC+qp9OHi2tt9cpur11mk6NPWjdVMqXxOBYgeWESR5k8fYS6ttRNPEC2J Q5ZtNMV1srdov+mjWRiTmGIXWUwXWEI/5LQAthtaSywFPHj96+kLlm79lbYeaVfSN/URojQZLAq 2gx0DFK8m5ZA9GaRQZSL3eavfzw2Kd6pOdFNemTquM/i7uGFc4/Tt2JOGjatLz4u9UvvO3pLUxU 2bohd1vR/FwmB/9bgwLmmtdtrP5s2N+/oZP/kBYETHNX60oaldO07yxog3V6XbRybCLmGi8wDrS wNeIMrQEurKA6vBl+6OepfMaLjGZKMGqAZAPy+Wz51uW7diJOHx8AfXoFcj0ClUHaGopxgiS93r QXnDcTGn7JSIqt/tW+TOr2v3BuepZThd+guP/bkDBqHbrBhHtVsjPp6YMD2Zis8gT4c+9DQYKwR ewb829g9ZmY3cxhNj6hKwVypB+/RUSOho/DWm32a76xQOfDODh65noPoPqtMBOaoRyAm2qbFPzt PhP946SAy6SWD37dZ+t8k26vJ+l2vzMqFR+pOymYFFgwP3K0OFaKf+K2Xh5luhRVg+Ev7BI2ejB OFh6TtjX4ljTPw5mNQ41wnMD56tcGFBxMDdnEJl3ekCPPwcDBLZvacRIJjOUsEPvybcY04FVADS XM/jSkZpW9BLNR5brET1FTXIT7PMN6ueIhAdKDDHgYNN8up7ZE7ffZBByIXnXVil+Xt6CAXOV3Y YRtegHBT3bl6SZsHxfE9atK6UX0PzT6LqVnUjZNAJfWnE7GSiwZL+E/32JXMkT68N1obDffi7Ny v1NqAmGqF31wWwH69+EYV5JE/mHUxfInpG9UeNvGnLVgus6/O7X1b3H4/BglqQ9BhAz5l3rStt1 tolpOpI+HErKKc5CXfo/vT958tgObTjY2LHSY3BdAYo85zLnwAE+Hw/ZA37NlnOl6YXhEjNI7Su Aw7hcPqO9LPgoofk7oADU+iGR28qpmfYDT8lg0/FKRqsufHvqRon1H8zlFF09Xpi0u87JnVSG7e 1oqNBjrfLR3/5iR4qP0avcFaFAUpM+CGVX8lCL3UYEDa1wK29YxnkU/9JY5NIERb/FZagWO5yXv 5gJ9+E9wWY44moU3vJY3P3Ov5x2+1bkhiAdmSUCUo/wU5eK7kntlpU/6c/lCN+VPlhht4neI+NQ kmVZvbbgEk4KD9qA+FetizPH4tdbAJCwRR9UMuNPdgwnObVmKCgwGZmZr4ZSDpDmdR7XdPOaJw6 hiXxvr6xAVuvVNrHfcVLsiqdKop4jG7/DHOZOG30/LvyOutt9GktBDCnIPAE+7/JHK7Gn4FGbOt 3VZxW5L5WWiRxzePYX4urjt68U/sQYxJRMqopRPhpGnguFAw6Ye6wpyvSg6nkZjeADyNSYn+W66 VR8IZafpnfGxFtnZRPgGiE3UAxL7YvP7AeG2APYepCtTnNybFPHQPkHSRtn4NK5BenrRfGBT/+M 4WdyYQ++4Kn5b8KoDr2HeU2SqNOru0VvEGa10emd6YOe2c7NgJGNcp0OeCzYsNZxLoZJru3CMZ3 +w5uyf2TEaCEKwCM0+FNYMTS7o+KFO7N1AdEG9Fz4HeIs4VeqOKFRf4+brBo8xK8AV/dT3aXxOR z6TRR/wTNwKDuctwJQv03Tq4X+db+V6z/4nuyzSU/G3e7J0JtcuMgkP6txV2GVZPFMajwZckg0u FZcu5HTkXJsa8x/JWRCcLxtzYin5GqRaOHYgksJ93ab2vTW4lvEUlxt841mgICndnUa1NSyC9rw 04mnaBSHBTFLjyKG1FOgYoeRkE9Lj/VCmmr1v5P9/AK2Ui5lGkV4ugsBOx6dqK9TuZ5uSaAa3fv gIVHofBKckafpHBMpcdAWFUNnv3RcSIrCx6IOduGDJr8b3JuQIxCLg1u4HaJuSCqsINhch8B/4N Tz72YuTzDfh3cGHfvmFrcxYgp4FTq1lc76nC7q6fbxMaRZVfjqcbFCTUbBVtg6mUapmDh/Ao1Vz XUMml1JdBRqJhBfNcKxkj8oJ0+U1wjcqPcTTCvHljuMmNtLET0AVdgxSqUA1q/qg3dazHJ5YBDK t34a5cmHQeXj8pXNalHhOpSSb2uHlau3cfxPTRPqhfKnkDPKFPNaqTNCF1Pmh/xDzbCVNaKkPK+ rLQW7p5VpA2cGCNBj38eaKwVEccH+NUmTVyxe+jH6QZdQa8GuawW1JYo6VSJGJycqmyVWcvH7m9 ZYQI7VObfvCb4D861QWIvkeytKM31BkHsxEEraJuI50AYxIs+1ZX/bz37IRBLq9AivLPCFZ20cr OPT+IS2v4Dn0YIfDztxUH0lDfZ5b3e9QBsFVORp3o6Hw2WewktGlPHCfDrYsm/t0Dv368Hbq8HJ CDdnw9syZCjD3mBTnYh2HQiHSbViOvOUnD3saFHZeONsuNM+9KXi/d1k1o3Y65Ud0wggS9AgEAM A0GCSqGSIb3DQEBAQUABIIEpzCCBKMCAQACggEBAL4b1hfUFuggi3Jl2MSc96gleHkndRBqT6WQ 74qKuWVh41Awvt6e3eX0o6nS0z8h/FIOZVa3JgBSjEzdMacOgmAIKfmNRAh1CQ9dPFrvF4vXVbh 3R+rJoA7Iw5cDZBlKETrV0ETP2XL5ucg3UytzAt7Sr9M+4pLUQGnwtL+VDNb8+sdOcMfCgaKcFm rnwH8SuCY+HbtCWSFqZ1cbgrEN03ZrKKWa90bTp0zCsYqzZNqDkcptRIw8DcGUq++qsmExvfDzr E9/Yye9bNVaaLS2kTbNwKBeRf7hW2KKQFbVCgW4WOIFY0kpYxd7ZQpdht1gUE/NomIYJ2Jhdcm7 U3XqlLECAwEAAQKCAQAyhSM34dzUgxGLrRUV6sDFpm+Fgr7RRe80iHef0Y3DK2hE/y856e3+Fi0 IDEanGFj9VWYIzVMD8uvl4UI4qtpqusCs2KWjubZWpuhLIg6X0vmss8Yg1sP6KdAQaY5ISi6Z/A gEwVd//m0oj8tCWKYCoOqosKV1b4JOpPDjmLB40PwT5T0B10IhZLfgrAwKofbT+bpyuNbfZv0K9 oxUvT9LYWtcF4aPdA7GqgwKAybHq0UYzc2Uggki4gKtlw9MHdzz0u1jnu42sJ7qjadVlWH/UwpV uK5jmzcHmWFbzrFP2O6p0Jpq0AP/EcNKjbD0pxUuGF5RbbIuTQeXfG3z5pkhAoGBAO7qVBwUZCg Q00QmZ46ZtvfSUYslFwrQhM21zVUJbV4tfPZYlK7cInQvlwxy3prCdpbROMcb78eL9aFCjaS2XY A3e4ufpm6Ncu5a/Y2W5ScSw1N7EZHeIGj3rZu51b0WZZakUHupas4S7yApQT0cyg4Fru8yr+6WA 24bwhxEWl6nAoGBAMu0CUB8+lZih2vDy9sDm++DTlDJZDKPfOCCj5IH6YqtdkUm/+TUmuINZqMI yowUulwpunPDFs3W6aGr6XnOYkcbbQ5dHbhuF9i+JY84rW/zhLLd/nGf9zx1rKanWD5B1zC88/1 yM0B7WY1A0Rg2D9K8OJ+FTwEAHq2nkHpVmPTnAoGAGuOks8RXwWqjXHg2D4adYSb6pn52KXFugP iFM5zsAj18Yv11PnjoJ8tzZKNJCoH4duD1UvOB+SN3cb7b0j30KAoWjZBaWvbwiIMVJmplQBCMi 0i+oXwuiaHWmEBCHhX3OQ0lQcW/j5Hx99ysywQCebGKDsHVqzSXDj1xi1zmDuECgYBiwE236J6H oE5cLNg3vaEr1LDzsx4S8MKuKD0noxRRuVPbpFNrgLHxImP+Z3WhwS6zHTuZgRseALDUQn32Ido 89IvC6dtNnHmNBmk47FYQLrLG7525Qb5engFr7TZ3P/3tT7zMwj8cZG/+bUywewzisYKVus+ZAZ DdyJze4X48QwKBgQC5Q8YDafkPhO0/riXfHE4L5NnPLWX6t3TINt+eYYnF47Hph1o+TQTCSF9SK BSZLFwpH1i/y1P/+z2rOuqrAuSkK462Uz6u7mslFVXb82baLM1Kf0h48Y+YuEJRlRVnNCpRHR3d xo0q1Hy6tHThjXl2WXxTQEKyA7olA+T2uI6x1Q== -----END PRIVATE KEY-----¶
This example uses the following OID as definid in Open Quantum Safe, which correspond to NIST Round3 candidates:¶
https://github.com/open-quantum-safe/oqs-provider/blob/main/ALGORITHMS.md¶
id-falcon512 1.3.9999.3.1¶
A Falcon512-ECDSA-P256 public key:¶
-----BEGIN PUBLIC KEY----- MIIEBTAMBgpghkgBhvprUAUDA4ID8wAwggPuMIIDjzAHBgUrzg8DAQOCA4IACZdJCeFxldpfuli HAR1VY2ntR4Rc6Q9UvTsy6vo7xDbFSewjE1Ei4gmUTWz6PfkpoDkrOVqA4tkTvQZE23jQKVfglH DziGZuOtsw2aCjXlJsIdJieTytFvEegdOsagJJLd3IjqQOu41LCiLGXLQ+widcNBcZ/Bs1oCANw qJtjofEiRcUCie6vnMiMiLsMLl8S8MBn3CIDMB/319AmgQro0YqMjEsS3VBzIyCnkmwy3QAPN+m oJkrrBDUqtLkXyh5vaeirZk9DnFDJc6Yq9Fz5yHVoE120ZjVyJBC0O8p2BX2YXm3YhOXWoDgo3v gJhRlYHnUg28oMpaBav7V+0fyNAalD3dpLHGVqAVblvY6uDSLv1uBY9DcHMhPrHDBjaE1MbkBZp wGrHQh4AM5p5pFwcAGSIKYZsiUmPWctwItvMV+ydsdQvEyISfBq+1FyLdTFqsQv4GfUlpk3MlZe cvNVdSD2FjHgLOqkZZyqspZil4jCNRCUW64cSOOT7m0I6nC2U+s4Lcbh6yuu0z8mBcj0nWud1E1 WICEjviAo8dkevJMU63lOxbAXXe/ZSgJ8ZDhL4dXfSXLhFeg07aOmKFUah5a8i5JrFSnh6zku/L nf1GyfdnDBiAcsYlxtFEjYkG8cTJIOwhRslem6TAJhtxSM+cHUKIQY+Dl6QmNFKR1wBGqap0w+A WAtu4VK2rTSL6ENRmBB+pwStWl0+rAVjRtONLkCX7aSfh10yaaJBloTJ1NLqQI2aTBM0EcjhhmI PBCgtf4+2bQTFLe0pKcW2aB7TvMHcUKyHQFMu5erQXbY1FmP1w2y5R+GK1myuJIQMrWCKZxd74d nk5EaunOYxIGgslmINGjmKmzwTiuIwsF2oimRdMUla36Ss4nmcCzlONcQ1NKtdvXaWJotbGIIGs xCFUvspsIdZemJ8MZxZIAotW5u12IaIgmiMdTUoH1O5mpjso5iUhynqlOqfw6aJbJH3+FxMT85P N0UdzR65uiMfSiq/HVb0zhB0gJLrqpPAXaMgiYZHBqQqeQeB5pwTYM5xuiKIbW9KG+gBIOCimVG mTUd5U+4hceULMCpaTff2636q/ofEAZlrfQC2aV/GAWx6iOm67AQMVTKG34XFqVY+C9eLyipwPq FLAQt8WaxSAuEScapj1+xpCpUlUhm8Ca2AbvfEi9pit9Rj8y9t7TIpDmMFkwEwYHKoZIzj0CAQY IKoZIzj0DAQcDQgAEFFnVIrPg3W3QEt95Z4WQn1cmoZV9tpo20FG9umA2B7CSaf7q9FwgVY7qvD HymrF59in1pXEPnEWLZ9xLO5A6cg== -----END PUBLIC KEY-----¶
The corresponding explicit private key is as follows. Note that the PQ key comes from OpenQuantumSafe-openssl and is in the {privatekey || publickey} concatenated format. This may cause interoperability issues with some clients, and also makes the private keys appear larger than they would be if generated by a non-openssl client.¶
-----BEGIN PRIVATE KEY----- MIII9gIBADAMBgpghkgBhvprUAUDBIII4TCCCN0wggiWAgEAMAcGBSvODwMBBIIIhgSCCIJZ+EB +0I+BBBHBEB9A//69D3BA65EC9A/A//D/E/G5666D5+EA7787H/BE+CD868BJB8DDCC/+C98/+C A669+A/93GB+/HB4AEB77+/D/4F+CF5+B86B5FA6AC+A7//6/+D+7CE9/GAAE8CE/DDD4+FK97B AD489BA/6/AADC4C9B7B9//EA+FBE7BAFAAD9/BBC4G798/E6D/EB+FHCFDAABEDABB4BCAJAA+ CA46GBBB/8F9++C99+D4DD6F+AECAEBDDDE+A++GBD9+AEC9C/5/9A+D/EBF+DE/B/A48/E754B /8A++495CCDABENGB37C6D5+92C9F8/D9HDH/AB76CFAA+CIAGBEJGA3JFB68BGBAAC6HDHC/6E ++8/9EHBE/BECF+7/5/CE7FD4+CD99BHB/w+/9BLB98/ACJ9FDB+/EA+CCDA+8988F+E8A8B5A5 D9/5995AAG//88+BHB9C+2B7GCH9CD56F956EACBDEB+AEDGL/D+6IB9GBFAD6CF6F7D6KD9D9D DDEC/CED8E97B+45FCF1z6CDD9DBJFCA9/A+CCFDKG/+EA+A7BA79KABB7717C5/CB//+FC+/A9 E9C+7H7+CF/358GC//FBB46/+F/4/++B+A/B6G9DFB6G/8CE9B3+7C/D+FABB9/EDFAAEF+D6CD 88D7CDEFAI2HG87BGB/C+/A/ACDC/AFF/3/8F/E/D966B+97DBDB9EA/9D/FD8++8/B/AC5/A84 C9HDE+5DA/CDBFB1AC8FBFE/+/DA9AD/+85A+CE+D6+BB9/H5C+CDFCCE7+B/GD6+C/CEE8G7B+ AEC/F6ADA6CF9B+C8D+D+B+K+4ABAAA4/8CDE/A+FBD/9I/A79E/8++C/+AB79D2BE5F4C9+G/B E/5+ID/A/AI//J/A+D5F8CA+9/EEEA+6DD98B4DHC8CDBI/C8BCC5IK+9+7CAFBH9BH3ABCDE/D C9AGDD+8CC8EADBC/94F5B+6F8++EK6G8879BEECFCABC+6OvxsQz3+SHpzfP35AjW/Cfp9g7oB P776gMtBxMJ3woSCuzpJi0p2dnrByfhDSreIBELDycfAgAo7AACKfYQ97kPBBMW9iYzOdNIGxjv FuzxFQsWuy4qQxgDLBYe1AIBLPIqFgPj/fFo9vwDDO4W+vnq1fP68hkZCSDl/yfpGhTvHhHoB/X b+STpCf0S5wMhyvIR2/L75BcC7xozCxH88fXHBy/1ChPZ+fsP/hsF+djx/+MKBesPzwP/+hcLBu 8MFxX53hwAKwYfPOkuLfjUBQfnId4IDeTfIUFkHhox+u8l9QUq4vgVBff1EwjVLhsC6w/z9hf1+ xESFeoHBewGCg8XtdDnCRjo0fcF0yDTEv4uzxYA0BT8++gIAQ708d/z79nS5/YO5fYi7RwJ9AoK BOLsANLV3hP/Af/zDvS71RLv1dP25t2wGwfdNesxEgIlKgPzAfr85rAWDAkG7f4n+hMA+wzuJAg RDwoVADYvBjoz6gjmAwcV2gf+4AT5BSgCAun97gX2+Qq39BUT39nx3/DAtxAZ3PgOCg8MKfAL9/ n+/eMHD9TuHu365OQE9/0BA87qyvX36BMOFB39OfXx/AsC0fb+39EJCuUS3BH75ub38Or6HuD2y 9wFAvK7BBYQFf0TGxAB6P/7GvwUBxMVA+sZJDEHMjwH9e8J2BFO1AMJl0kJ4XGV2l+6WIcBHVVj ae1HhFzpD1S9OzLq+jvENsVJ7CMTUSLiCZRNbPo9+SmgOSs5WoDi2RO9BkTbeNApV+CUcPOIZm4 62zDZoKNeUmwh0mJ5PK0W8R6B06xqAkkt3ciOpA67jUsKIsZctD7CJ1w0Fxn8GzWgIA3Com2Oh8 SJFxQKJ7q+cyIyIuwwuXxLwwGfcIgMwH/fX0CaBCujRioyMSxLdUHMjIKeSbDLdAA836agmSusE NSq0uRfKHm9p6KtmT0OcUMlzpir0XPnIdWgTXbRmNXIkELQ7ynYFfZhebdiE5dagOCje+AmFGVg edSDbygyloFq/tX7R/I0BqUPd2kscZWoBVuW9jq4NIu/W4Fj0NwcyE+scMGNoTUxuQFmnAasdCH gAzmnmkXBwAZIgphmyJSY9Zy3Ai28xX7J2x1C8TIhJ8Gr7UXIt1MWqxC/gZ9SWmTcyVl5y81V1I PYWMeAs6qRlnKqylmKXiMI1EJRbrhxI45PubQjqcLZT6zgtxuHrK67TPyYFyPSda53UTVYgISO+ ICjx2R68kxTreU7FsBdd79lKAnxkOEvh1d9JcuEV6DTto6YoVRqHlryLkmsVKeHrOS78ud/UbJ9 2cMGIByxiXG0USNiQbxxMkg7CFGyV6bpMAmG3FIz5wdQohBj4OXpCY0UpHXAEapqnTD4BYC27hU ratNIvoQ1GYEH6nBK1aXT6sBWNG040uQJftpJ+HXTJpokGWhMnU0upAjZpMEzQRyOGGYg8EKC1/ j7ZtBMUt7SkpxbZoHtO8wdxQrIdAUy7l6tBdtjUWY/XDbLlH4YrWbK4khAytYIpnF3vh2eTkRq6 c5jEgaCyWYg0aOYqbPBOK4jCwXaiKZF0xSVrfpKzieZwLOU41xDU0q129dpYmi1sYggazEIVS+y mwh1l6YnwxnFkgCi1bm7XYhoiCaIx1NSgfU7mamOyjmJSHKeqU6p/Dpolskff4XExPzk83RR3NH rm6Ix9KKr8dVvTOEHSAkuuqk8BdoyCJhkcGpCp5B4HmnBNgznG6Iohtb0ob6AEg4KKZUaZNR3lT 7iFx5QswKlpN9/brfqr+h8QBmWt9ALZpX8YBbHqI6brsBAxVMobfhcWpVj4L14vKKnA+oUsBC3x ZrFIC4RJxqmPX7GkKlSVSGbwJrYBu98SL2mK31GPzL23tMikOYwQQIBADATBgcqhkjOPQIBBggq hkjOPQMBBwQnMCUCAQEEICXQxbtuhGjYSkyLz+K0V0tRyxgEBlQcElOVwHZSA4QL -----END PRIVATE KEY-----¶
TODO: we switched to using a pub key identifier without the signing mode, ie just id-SPHINCSplusSHA256-ECDSA-P256¶
This example uses the following OID as definid in Open Quantum Safe:¶
https://github.com/open-quantum-safe/oqs-provider/blob/main/ALGORITHMS.md¶
id-SPHINCSplusSHA256256frobust 1.3.9999.6.6.1¶
A SPHINCSplusSHA256256frobust-ECDSA-P256 public key:¶
-----BEGIN PUBLIC KEY----- MIG/MAwGCmCGSAGG+mtQBQcDga4AMIGqME0wCAYGK84PBgYBA0EA6HRU4f2vmr2LV5vZVlaniti Ly8ZCfheVqolJGrY5GxpNwvIt8fK6swNtftSgmrC+fCDE48/fbzX7a2U3F1/S3TBZMBMGByqGSM 49AgEGCCqGSM49AwEHA0IABFjKamMP3nn7Ua8Y8XEJtqnp7ya+Ino3UoxjMhhVKHx0fQxAz7lB7 Eytrtq3H7e59JYdkceK1h+T8jZFyUP5e0M= -----END PUBLIC KEY-----¶
which decodes as:¶
algorithm: AlgorithmIdentifier{id-Dilithium3-ECDSA-P256}
subjectPublicKey: CompositePublicKey {
SubjectPublicKeyInfo {
algorithm: AlgorithmIdentifier {
algorithm: id-SPHINCSplusSHA256256frobust
}
subjectPublicKey: <sphincs key octet string>
},
SubjectPublicKeyInfo {
algorithm: AlgorithmIdentifier {
algorithm: ecPublicKey
parameters: prime256v1
}
subjectPublicKey: <ec octet string>
}
}
¶
The corresponding explicit private key is as follows. Note that the PQ key comes from OpenQuantumSafe-openssl and is in the {privatekey || publickey} concatenated format. This may cause interoperability issues with some clients, and also makes the private keys appear larger than they would be if generated by a non-openssl client.¶
-----BEGIN PRIVATE KEY----- MIIBMgIBADAMBgpghkgBhvprUAUHBIIBHTCCARkwgdMCAQAwCAYGK84PBgYBBIHDBIHA0PwPCww Ulg3VLrZC7cGLqF0jRZrREj/l4kKF4JsLTjRR2P4RLqEm0qBa7ukb4ytHE6HDfM0h6dJ19F02hO SO6Oh0VOH9r5q9i1eb2VZWp4rYi8vGQn4XlaqJSRq2ORsaTcLyLfHyurMDbX7UoJqwvnwgxOPP3 281+2tlNxdf0t3odFTh/a+avYtXm9lWVqeK2IvLxkJ+F5WqiUkatjkbGk3C8i3x8rqzA21+1KCa sL58IMTjz99vNftrZTcXX9LdMEECAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQcEJzAlAgEBBCAwCM4 KKsZbXlaZBph1ixcUhlNiZ1qp4LnA90Nm/rArZw== -----END PRIVATE KEY-----¶
This section addresses practical issues of how this draft affects other protocols and standards.¶
EDNOTE 10: Possible topics to address:¶
CompositePrivateKeys can be encoded to the Privacy-Enhanced Mail (PEM) [RFC1421] format by placing a CompositePrivateKey into the privateKey field of a PrivateKeyInfo (OneAsymmetricKey) object, and then applying the PEM encoding rules as defined in [RFC7468] section 10 and 11 for plaintext and encrypted private keys, respectively.¶
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 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 public key objects, from online negotiated protocols such as TLS 1.3 [RFC8446] and IKEv2 [RFC7296], to non-negotiated asynchronous protocols such as S/MIME signed and encrypted email [RFC8551], document signing such as in the context of the European eIDAS regulations [eIDAS2014], and publicly trusted code signing [codeSigningBRsv2.8], as well as myriad other standardized and proprietary protocols and applications that leverage CMS [RFC5652] signed or encrypted structures.¶
This document purposefully does not specify how clients are to combine component keys together to form a single cryptographic operation; this is left up to the specifications of signature and encryption algorithms that make use of the composite key type. One possible way to combine component keys is through an OR relation, or OR-like client policies for acceptable algorithm combinations, where senders and / or receivers are permitted to ignore some component keys. Some envisioned uses of this include environments where the client encounters a component key for which it does not possess a compatible algorithm implementation but wishes to proceed with the cryptographic operation using the subset of component keys for which it does have compatible implementations. Such a mechanism could be designed to provide ease of migration by allowing for composite keys to be distributed and used before all clients in the environment are fully upgraded, but it does not allow for full backwards compatibility since clients would at least need to be upgraded from their current state to be able to parse the composite structures.¶
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 key type (signature, key establishment, etc) for the same identity (name, SAN), 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). This concept contains strong overlap with other documented approaches, such as [I-D.becker-guthrie-noncomposite-hybrid-auth] and highlights the synergy between composite and non-composite hybrid approaches.¶
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 cryptographic operation.¶
For negotiated protocols, the client could choose which public key(s) or certificate(s) to use based on the negotiated algorithms, or could combine two of the public keys for example in a non-composite hybrid method such as [I-D.becker-guthrie-noncomposite-hybrid-auth] or [I-D.guthrie-ipsecme-ikev2-hybrid-auth]. Note that it is possible to use the signature algorithm defined in [I-D.ounsworth-pq-composite-sigs] as a way to carry the multiple signature values generated by a non-composite public mechanism in protocols where it is easier to support the composite signature algorithms than to implement such a mechanism in the protocol itself. There is also nothing precluding a composite public key from being one of the components used within a non-composite authentication operation; this may lead to greater convenience in setting up parallel PKI hierarchies that need to service a range of clients implementing different styles of post-quantum migration strategies.¶
For non-negotiated protocols, the details for obtaining backwards compatibility will vary by protocol, but for example in CMS [RFC5652], the inclusion of multiple SignerInfo or RecipientInfo objects is often already treated as an OR relationship, so including one for each of the end entity's parallel PKI public keys would, in many cases, have the desired effect of allowing the receiver to choose one they are compatible with and ignore the others, thus achieving full backwards compatibility.¶
The following IPR Disclosure relates to this draft:¶
https://datatracker.ietf.org/ipr/3588/¶
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:¶
John Gray (Entrust),
Serge Mister (Entrust),
Scott Fluhrer (Cisco Systems),
Panos Kampanakis (Cisco Systems),
Daniel Van Geest (ISARA),
Tim Hollebeek (Digicert),
Klaus-Dieter Wirth (D-Trust),
Patrick Kelsey (Not for Radio LLC),
Anthony Hu (wolfSSL), and
Francois Rousseau.¶
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].¶
Additional contributions to this draft are welcome. Please see the working copy of this draft at, as well as open issues at:¶
https://github.com/EntrustCorporation/draft-ounsworth-pq-composite-keys¶