| Internet-Draft | PQ Explicit Composite Keys | February 2022 |
| Ounsworth, et al. | Expires 16 August 2022 | [Page] |
With the widespread adoption of post-quantum cryptography will come the need for an entity to possess multiple public keys on different cryptographic algorithms. Since the trustworthiness of individual post-quantum algorithms is at question, a multi-key cryptographic operation will need to be performed in such a way that breaking it requires breaking each of the component algorithms individually. This requires defining new structures for holding composite public keys and composite signature data. This draft defines a structure generic enough to be useful beyond the post-quantum transition for any situation where a widely-supported but untrusted algorithm is being migrated to newer cryptography.¶
This document defines structures for binding an explicit pair of cryptographic algorithms together into a single object identifier, and it provides ASN.1 structures for encoding these pairwise composite public keys, private keys in wire protocols, as well as using them in conjunction with composite signatures, encryption and key transport mechanisms.¶
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 16 August 2022.¶
Copyright (c) 2022 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.¶
During the transition to post-quantum cryptography, there will be uncertainty as to the strength of cryptographic algorithms; we will no longer fully trust traditional cryptography such as RSA, Diffie-Hellman, DSA and their elliptic curve variants, but we will also not fully trust their post-quantum replacements until they have had sufficient scrutiny. 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.¶
The deployment of composite public keys and composite signatures using post-quantum algorithms will face two challenges¶
This document provides a mechanism to address algorithm strength uncertainty by providing formats for encoding multiple public keys and private keys into existing fields.¶
This document provides structures to encode explicit composite algorithm identifiers and parameters for use with composite signature, encryption, and key transport mechanisms defined in ~~ TODO cite corresponding drafts properly ~~.¶
This document is intended for general applicability anywhere that public key or private key structures are used within PKIX protocols.¶
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.¶
The following terms are used in this document:¶
ALGORITHM: An information object class for identifying the type of cryptographic operation to be performed. This document is primarily concerned with algorithms for producing digital signatures, though the public key structure could just as easily hold encryption keys.¶
BER: Basic Encoding Rules (BER) as defined in [X.690].¶
COMPONENT ALGORITHM: A single basic algorithm which is contained within a composite algorithm.¶
COMPOSITE ALGORITHM: An algorithm which is a sequence of one or more component algorithms, as defined in Section 2.¶
DER: Distinguished Encoding Rules as defined in [X.690].¶
EXPLICIT COMPOSITE: Composite structures where the AlgorithmIdentifier OID explicitly defines the component algorithms. This case allows simplification and compression of the data structures.¶
GENERIC COMPOSITE: Composite structures that are agnostic to the choice of Algorithms that they carry.¶
PUBLIC / PRIVATE KEY: The public and private portion of an asymmetric cryptographic key, making no assumptions about which algorithm.¶
PRIMITIVE PUBLIC KEY / SIGNATURE: A public key or signature object of a non-composite algorithm type.¶
SIGNATURE: A digital cryptographic signature, making no assumptions about which algorithm.¶
In order for public keys and signatures to be composed of pairs of algorithms, we define encodings consisting of a sequence of public key and signature primitives (aka "component algorithms") such that these structures can be used as a drop-in replacement for existing public key or signature fields such as those found in PKCS#10 [RFC2986], CMP [RFC4210], X.509 [RFC5280], CMS [RFC5652].¶
This section defines the following structures:¶
~~ TODO ~~¶
A composite key is a single key object that performs an atomic signature or verification operation, using its encapsulated pair of component keys.¶
Explicit pairs can easily be defined by simply providing an OBJECT IDENTIFIER and two existing PUBLIC-KEY types to the pk-explicitComposite object class, and assigning an OID to the resulting structure. See examples of defining explicit pairs in Section 6.2.¶
-- TODO - CERT-KEY-USAGE should contain the intersection of the usages from firstPublicKey, secondPublicKey and the four listed below
-- pk-explicitComposite - Composite public key information object
pk-explicitComposite{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}
}
¶
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-alg-identifier 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
}
}
¶
EDNOTE: THIS IS WRONG. (copied from generic draft) we need to do some work to come up with a private key structure.¶
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 corresponding AlgorithmIdentifier for a composite private key MUST use the id-alg-composite object identifier, and the parameters field MUST be absent.¶
A CompositePrivateKey MUST contain at least one component private key, and they MUST be in the same order as in the corresponding CompositePublicKey.¶
The structure pk-explicitComposite contains all the necessary information in order for the ASN.1 compiler to generate composite signature structures that are explicitely bound to the specified pair of algorithms.¶
EDNOTE: Is this helping, or adding complexity for no reason? In theory, explicit composite public keys can be used with generic composite signature and encryption structures (ie the SEQUENC OF model).¶
The following ASN.1 object class then automatically generates the signature params structure from the types defined in pk-explicitComposite.¶
-- ExplicitSignatureParams - The data structure for composite signature parameters
-- TODO firstParams and secondParams should be optional only if they are marked optional
-- in SIGNATURE-ALGORITHM
ExplicitSignatureParams{SIGNATURE-ALGORITHM:firstAlg, SIGNATURE-ALGORITHM:secondAlg} ::= SEQUENCE {
firstParams firstAlg.&Params OPTIONAL,
secondParams secondAlg.&Params OPTIONAL
}
¶
EDNOTE: we need some help from the community on the ASN.1 here: "OPTIONAL" is not really the right semantics here; we really mean that they params here should be present or absent when the corresponding params are present or absent in ExplicitCompositePublicKey, which ought to be enforcable by the ASN.1 compiler, but we can't figure out the syntax for declaring that.¶
The following ASN.1 object class then automatically generates the signature algorithm structure from the types defined in pk-explicitComposite.¶
-- TODO - Would it be possible to make these definitions compatible with n signature algorithms instead of 2? Is it desired?
-- sa-explicitCompositeSignatureAlgorithm - Composite signature algorithm information object
sa-explicitCompositeSignatureAlgorithm{OBJECT IDENTIFIER:algId, SIGNATURE-ALGORITHM:firstAlg, PUBLIC-KEY:firstPublicKey, FirstPublicKeyType, SIGNATURE-ALGORITHM:secondAlg, PUBLIC-KEY:secondPublicKey, SecondPublicKeyType} SIGNATURE-ALGORITHM ::= {
IDENTIFIER algId
VALUE ExplicitCompositeSignatureValue{firstAlg.&Value, secondAlg.&Value}
PARAMS TYPE ExplicitSignatureParams{firstAlg, secondAlg} ARE required
PUBLIC-KEYS { pk-explicitComposite{algId, firstPublicKey, FirstPublicKeyType, secondPublicKey, SecondPublicKeyType} }
SMIME-CAPS { IDENTIFIED BY algId }
}
¶
~~ TODO ~~ Need analogous structures to the signature ones above.¶
Many protocol specifications will require that the composite public key, composite private key, and composite signature data structures be represented by an octet string.¶
When an octet string is required, the DER encoding of the composite data structure SHALL be used directly.¶
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.¶
In the interests of simplicity and avoiding compatibility issues, implementations that parse these structures MAY accept both BER and DER.¶
This section addresses practical issues of how this draft affects other protocols and standards.¶
~~~ BEGIN EDNOTE 10~~~¶
EDNOTE 10: Possible topics to address:¶
~~~ END EDNOTE 10~~~¶
CompositePrivateKeys can be encoded to the PEM format by placing a CompositePrivateKey into the privateKey field of a PrivateKeyInfo or OneAsymmetricKey object, and then applying the PEM encoding rules as defined in [RFC7468] section 10 and 11 for plaintext and encrypted private keys, respectively.¶
The Cryptographic Message Syntax (CMS), as defined in [RFC5652], can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type.¶
When encoding composite private keys, the privateKeyAlgorithm in the OneAsymmetricKey SHALL be set to id-alg-composite.¶
The parameters of the privateKeyAlgorithm SHALL be a sequence of AlgorithmIdentifier objects, each of which are encoded according to the rules defined for each of the different keys in the composite private key.¶
The value of the privateKey field in the OneAsymmetricKey SHALL be set to the DER encoding of the SEQUENCE of private key values that make up the composite key. The number and order of elements in the sequence SHALL be the same as identified in the sequence of parameters in the privateKeyAlgorithm.¶
The value of the publicKey (if present) SHALL be set to the DER encoding of the corresponding CompositePublicKey. If this field is present, the number and order of component keys MUST be the same as identified in the sequence of parameters in the privateKeyAlgorithm.¶
The value of the attributes is encoded as usual.¶
This section talks about how protocols like (D)TLS and IKEv2 are affected by this specifications. It will not attempt to solve all these problems, but it will explain the rationale, how things will work and what open problems need to be solved. Obvious issues that need to be discussed.¶
This draft does not define any OIDs, however derivative drafts that define concrete algorithm pairs will. The authors suggest that IANA assign OIDs for explicit composite pairs on the id-pkix arc under a composite() arc.¶
id-alg-composite OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) algorithms(6) composite(??) }
¶
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 structures using that algorithm are implicitly revoked.¶
In the composite model this is less obvious since a single public key, certificate, or signature may contain a mixture of deprecated and non-deprecated algorithms. Moreover, implementers may decide that certain cryptographic algorithms have complementary security properties and are acceptable in combination even though neither algorithm is acceptable by itself.¶
Specifying a modified verification algorithm to handle these situations is beyond the scope of this draft, but could be desirable as the subject of an application profile document, or to be up to the discretion of implementers.¶
2. Check policy to see whether A1, A2, ..., An constitutes a valid
combination of algorithms.
if not checkPolicy(A1, A2, ..., An), then
output "Invalid signature"
¶
While intentionally not specified in this document, implementors should put careful thought into implementing a meaningfull policy mechinism within the context of their signature verification engines, for example only algorithms that provide similar security levels should be combined together.¶
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 (see next Section).¶
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.¶
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, when marking a key as revoked for key compromise, the individual component keys should be marked, not the composite key as a whole.¶
<CODE STARTS>
Composite-Signatures-2019
{ TBD }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL;
IMPORTS
PUBLIC-KEY, SIGNATURE-ALGORITHM
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) } ;
--
-- Object Identifiers
--
id-alg-composite OBJECT IDENTIFIER ::= { TBD }
--
-- Public Key
--
pk-Composite PUBLIC-KEY ::= {
IDENTIFIER id-alg-composite
KEY CompositePublicKey
PARAMS ARE absent
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
PRIVATE-KEY CompositePrivateKey
}
CompositePublicKey ::= SEQUENCE SIZE (2..MAX) OF SubjectPublicKeyInfo
CompositePrivateKey ::= SEQUENCE SIZE (2..MAX) OF OneAsymmetricKey
--
-- Signature Algorithm
--
sa-CompositeSignature SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-composite
VALUE CompositeSignatureValue
PARAMS TYPE CompositeParams ARE required
PUBLIC-KEYS { pk-Composite }
SMIME-CAPS { IDENTIFIED BY id-alg-composite } }
CompositeParams ::= SEQUENCE SIZE (2..MAX) OF AlgorithmIdentifier
CompositeSignatureValue ::= SEQUENCE SIZE (2..MAX) OF BIT STRING
END
<CODE ENDS>
¶
To add support for a new pair of algorithms, all that is required is the following two constructs:¶
id-sa-entrust-sha256RSAandECDSA OBJECT IDENTIFIER ::= { 1 2 3 4 }
sa-entrust-sha256RSAandECDSA SIGNATURE-ALGORITHM ::= sa-explicitCompositeSignatureAlgorithm{
id-sa-entrust-sha256RSAandECDSA,
sa-sha256WithRSAEncryption,
pk-rsa,
RSAPublicKey,
sa-ecdsaWithSHA256,
pk-ec,
ECPoint
}
¶
TODO: run this through an ASN.1 compiler and list here what the final generated structures look like.¶
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 Datacard), Serge Mister (Entrust Datacard), Scott Fluhrer (Cisco Systems), Panos Kampanakis (Cisco Systems), Daniel Van Geest (ISARA), and Tim Hollebeek (Digicert).¶
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].¶