idnits 2.17.1 draft-ounsworth-pq-composite-keys-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 30 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 June 2022) is 686 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'X509ASN1' is mentioned on line 1125, but not defined == Unused Reference: 'Bindel2017' is defined on line 770, but no explicit reference was found in the text == Unused Reference: 'I-D.becker-guthrie-noncomposite-hybrid-auth' is defined on line 792, but no explicit reference was found in the text == Unused Reference: 'I-D.guthrie-ipsecme-ikev2-hybrid-auth' is defined on line 800, but no explicit reference was found in the text == Unused Reference: 'I-D.ounsworth-pq-composite-sigs' is defined on line 807, but no explicit reference was found in the text == Unused Reference: 'RFC3279' is defined on line 814, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1421 ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Downref: Normative reference to an Informational RFC: RFC 5912 ** Downref: Normative reference to an Informational RFC: RFC 8411 == Outdated reference: A later version (-13) exists of draft-ounsworth-pq-composite-sigs-05 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS M. Ounsworth 3 Internet-Draft Entrust 4 Intended status: Standards Track M. Pala 5 Expires: 9 December 2022 CableLabs 6 J. Klaussner 7 D-Trust GmbH 8 7 June 2022 10 Composite Public and Private Keys For Use In Internet PKI 11 draft-ounsworth-pq-composite-keys-02 13 Abstract 15 The migration to post-quantum cryptography is unique in the history 16 of modern digital cryptography in that neither the old outgoing nor 17 the new incoming algorithms are fully trusted to protect data for the 18 required data lifetimes. The outgoing algorithms, such as RSA and 19 elliptic curve, may fall to quantum cryptalanysis, while the incoming 20 post-quantum algorithms face uncertainty about both the underlying 21 mathematics as well as hardware and software implementations that 22 have not had sufficient maturing time to rule out classical 23 cryptanalytic attacks and implementation bugs. 25 Cautious implementors may wish to layer cryptographic algorithms such 26 that an attacker would need to break all of them in order to 27 compromise the data being protected. For digital signatures, this is 28 referred to as "dual", and for encryption key establishment this as 29 reffered to as "hybrid". This document, and its companions, defines 30 a specific instantiation of the dual and hybrid paradigm called 31 "composite" where multiple cryptographic algorithms are combined to 32 form a single key, signature, or key encapsulation mechanism (KEM) 33 such that they can be treated as a single atomic object at the 34 protocol level. 36 EDNOTE: the terms "dual" and "hybrid" are currently in flux. We 37 anticipate an Informational draft to normalize terminology, and will 38 update this draft accordingly. 40 This document defines the structures CompositePublicKey and 41 CompositePrivateKey, which are sequences of the respective structure 42 for each component algorithm. The generic composite variant is 43 defined which allows arbitrary combinations of key types to be placed 44 in the CompositePublicKey and CompositePrivateKey structures without 45 needing the combination to be pre-registered or pre-agreed. The 46 explicit variant is also defined which allows for a set of algorithm 47 identifier OIDs to be registered together as an explicit composite 48 algorithm and assigned an OID. 50 This document is intended to be coupled with corresponding documents 51 that define the structure and semantics of composite signatures and 52 encryption, such as [draft-ounsworth-pq-composite-sigs-05] and draft- 53 ounsworth-pq-composite-kem (yet to be published). 55 Status of This Memo 57 This Internet-Draft is submitted in full conformance with the 58 provisions of BCP 78 and BCP 79. 60 Internet-Drafts are working documents of the Internet Engineering 61 Task Force (IETF). Note that other groups may also distribute 62 working documents as Internet-Drafts. The list of current Internet- 63 Drafts is at https://datatracker.ietf.org/drafts/current/. 65 Internet-Drafts are draft documents valid for a maximum of six months 66 and may be updated, replaced, or obsoleted by other documents at any 67 time. It is inappropriate to use Internet-Drafts as reference 68 material or to cite them other than as "work in progress." 70 This Internet-Draft will expire on 9 December 2022. 72 Copyright Notice 74 Copyright (c) 2022 IETF Trust and the persons identified as the 75 document authors. All rights reserved. 77 This document is subject to BCP 78 and the IETF Trust's Legal 78 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 79 license-info) in effect on the date of publication of this document. 80 Please review these documents carefully, as they describe your rights 81 and restrictions with respect to this document. Code Components 82 extracted from this document must include Revised BSD License text as 83 described in Section 4.e of the Trust Legal Provisions and are 84 provided without warranty as described in the Revised BSD License. 86 Table of Contents 88 1. Changes in version -02 . . . . . . . . . . . . . . . . . . . 3 89 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 90 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 91 3. Composite Key Structures . . . . . . . . . . . . . . . . . . 5 92 3.1. pk-Composite . . . . . . . . . . . . . . . . . . . . . . 6 93 3.1.1. Key Usage . . . . . . . . . . . . . . . . . . . . . . 6 94 3.2. CompositePublicKey . . . . . . . . . . . . . . . . . . . 7 95 3.3. CompositePrivateKey . . . . . . . . . . . . . . . . . . . 7 96 3.4. Encoding Rules . . . . . . . . . . . . . . . . . . . . . 8 97 4. Algorithm Identifiers . . . . . . . . . . . . . . . . . . . . 8 98 4.1. id-composite-key (Generic Composite Keys) . . . . . . . . 9 99 4.2. Explicit Composite Keys . . . . . . . . . . . . . . . . . 9 100 5. Implementation Considerations . . . . . . . . . . . . . . . . 10 101 5.1. Textual encoding of Composite Private Keys . . . . . . . 11 102 5.2. Asymmetric Key Packages (CMS) . . . . . . . . . . . . . . 11 103 5.3. Backwards Compatibility . . . . . . . . . . . . . . . . . 12 104 5.3.1. OR modes . . . . . . . . . . . . . . . . . . . . . . 12 105 5.3.2. Parallel PKIs . . . . . . . . . . . . . . . . . . . . 13 106 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 107 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 108 7.1. Reuse of keys in a Composite public key . . . . . . . . . 14 109 7.2. Key mismatch in explicit composite . . . . . . . . . . . 14 110 7.3. Policy for Deprecated and Acceptable Algorithms . . . . . 15 111 7.4. Protection of Private Keys . . . . . . . . . . . . . . . 15 112 7.5. Checking for Compromised Key Reuse . . . . . . . . . . . 15 113 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 114 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 115 8.2. Informative References . . . . . . . . . . . . . . . . . 17 116 Appendix A. Creating explicit combinations . . . . . . . . . . . 19 117 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 20 118 B.1. Generic Composite Public Key Examples . . . . . . . . . . 20 119 B.2. Explicit Composite Public Key Examples . . . . . . . . . 23 120 Appendix C. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 26 121 Appendix D. Intellectual Property Considerations . . . . . . . . 29 122 Appendix E. Contributors and Acknowledgements . . . . . . . . . 29 123 E.1. Making contributions . . . . . . . . . . . . . . . . . . 29 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 126 1. Changes in version -02 128 * Merged Generic Composite (Section 4.1) and Explicit Composite 129 (Section 4.2) into one document and made them share a wire 130 encoding (only differing by the OIDs used). 132 * Removed Composite-OR Public Key. 134 * Synced document structure with -sigs 136 * Added Section 5.3 addressing backwards compatibility and ease of 137 migration concerns. 139 TODO diff this against the public version and see if there are any 140 more changes. 142 2. Introduction 144 During the transition to post-quantum cryptography, there will be 145 uncertainty as to the strength of cryptographic algorithms; we will 146 no longer fully trust traditional cryptography such as RSA, Diffie- 147 Hellman, DSA and their elliptic curve variants, but we may also not 148 fully trust their post-quantum replacements until further time has 149 passed to allow additional scrutiny and the discovery of 150 implementation bugs. Unlike previous cryptographic algorithm 151 migrations, the choice of when to migrate and which algorithms to 152 migrate to, is not so clear. Even after the migration period, it may 153 be advantageous for an entity's cryptographic identity to be composed 154 of multiple public-key algorithms. 156 The deployment of composite public keys, and composite signatures and 157 composite encryption using post-quantum algorithms will face two 158 challenges: 160 * Algorithm strength uncertainty: During the transition period, some 161 post-quantum signature and encryption algorithms will not be fully 162 trusted, while also the trust in legacy public key algorithms will 163 start to erode. A relying party may learn some time after 164 deployment that a public key algorithm has become untrustworthy, 165 but in the interim, they may not know which algorithm an adversary 166 has compromised. 168 * Migration: During the transition period, systems will require 169 mechanisms that allow for staged migrations from fully classical 170 to fully post-quantum-aware cryptography. 172 This document provides a mechanism to address algorithm strength 173 uncertainty concerns by providing formats for encoding multiple 174 public key and private key values into existing public key and 175 private key fields. Backwards compatibility is not directly 176 addressed via the composite mechanisms defined in the document, but 177 some notes on how it can be obtained can be found in Section 5.3. 179 This document is intended for general applicability anywhere that 180 keys are used within PKIX or CMS structures. 182 2.1. Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 186 "OPTIONAL" in this document are to be interpreted as described in BCP 187 14 [RFC2119] [RFC8174] when, and only when, they appear in all 188 capitals, as shown here. 190 The following terms are used in this document: 192 ALGORITHM: A standardized cryptographic primitive, as well as any 193 ASN.1 structures needed for encoding data and metadata needed to use 194 the algorithm. This document is concerned with algorithms for 195 producing either digital signatures or ciphertexts for the purpose of 196 key exchange. 198 BER: Basic Encoding Rules (BER) as defined in [X.690]. 200 CLIENT: Any software that is making use of a cryptographic key. This 201 includes a signer, verifier, encrypter, decrypter. 203 COMPONENT ALGORITHM: A single basic algorithm which is contained 204 within a composite algorithm. 206 COMPOSITE ALGORITHM: An algorithm which is a combination of two or 207 more component algorithms. 209 DER: Distinguished Encoding Rules as defined in [X.690]. 211 LEGACY: For the purposes of this document, a legacy algorithm is any 212 cryptographic algorithm currently in use which is not believed to be 213 resistant to quantum cryptanalysis. 215 PKI: Public Key Infrastructure, as defined in [RFC5280]. 217 POST-QUANTUM AGLORITHM: Any cryptographic algorithm which is believed 218 to be resistant to classical and quantum cryptanalysis, such as the 219 algorithms being considered for standardization by NIST. 221 PUBLIC / PRIVATE KEY: The public and private portion of an asymmetric 222 cryptographic key, making no assumptions about which algorithm. 224 3. Composite Key Structures 226 In order to represent public keys and private keys that are composed 227 of multiple algorithms, we define encodings consisting of a sequence 228 of public key or private key primitives (aka "components") such that 229 these structures can be used directly in existing public key fields 230 such as those found in PKCS#10 [RFC2986], CMP [RFC4210], X.509 231 [RFC5280], CMS [RFC5652], and the Trust Anchor Format [RFC5914]. 233 A composite key is a single key object that performs an atomic 234 cryptographic operation -- such a signing, verifying, encapsulating, 235 or decapsulating -- using its encapsulated sequence of component keys 236 as if it was a single key. This generally means that the complexity 237 of combining algorithms can be deferred from the protocol layer to 238 the cryptographic library layer. 240 3.1. pk-Composite 242 The PUBLIC-KEY ASN.1 information object class is defined in 243 [RFC5912]. The PUBLIC-KEY information object for generic 244 (Section 4.1) and explicit (Section 4.2) composite public and private 245 keys has the following form: 247 pk-Composite PUBLIC-KEY ::= { 248 id , 249 KeyValue CompositePublicKey, 250 Params ARE ABSENT, 251 PrivateKey CompositePrivateKey, 252 } 254 The identifier may be an OID representing any composite key type. 256 Section 4.1 defines the object identifier id-composite-key which 257 indicates that this is a "generic composite key" which allows 258 arbitrary combinations of key types to be placed in the 259 CompositePublicKey and CompositePrivateKey structures without needing 260 the combination to be pre-registered or pre-agreed. 262 Section 4.2 defines a framework for defining new "explicit" 263 combinations that use the same wire encoding structures as generic, 264 but with OIDs that dictate specific combinations of component 265 algorithms. 267 3.1.1. Key Usage 269 For protocols such as X.509 [RFC5280] that specify key usage along 270 with the public key, any key usage may be used with composite keys, 271 with the requirement that the specified key usage MUST apply to all 272 component keys. For example if a composite key is marked with a 273 KeyUsage of digitalSignature, then all component keys MUST be capable 274 of producing digital signatures. The composite mechanism MUST NOT be 275 used to implement mixed-usage keys, for example, where a 276 digitalSignature and a keyEncipherment key are combined together into 277 a single composite key. 279 3.2. CompositePublicKey 281 Composite public key data is represented by the following structure: 283 CompositePublicKey ::= SEQUENCE SIZE (2..MAX) OF SubjectPublicKeyInfo 285 A composite key MUST contain at least two component public keys. 287 A CompositePublicKey MUST NOT contain a component public key which 288 itself describes a composite key; i.e. recursive CompositePublicKeys 289 are not allowed. 291 EDNOTE: unclear that banning recursive composite keys actually 292 accomplishes anything other than a general reduction in complexity 293 and therefore reduction in attack surface. 295 Each component SubjectPublicKeyInfo SHALL contain an 296 AlgorithmIdentifier OID which identifies the public key type and 297 parameters for the public key contained within it. See Appendix B 298 for examples. 300 Each element of a CompositePublicKey is a SubjectPublicKeyInfo object 301 encoding a component public key. When the CompositePublicKey must be 302 provided in octet string or bit string format, the data structure is 303 encoded as specified in Section 3.4. 305 3.3. CompositePrivateKey 307 EDNOTE: we need to put a bit more effort into private keys, 308 specifically defining what OIDs to use in the generic and explicit 309 cases. 311 This section provides an encoding for composite private keys intended 312 for PKIX protocols and other applications that require an 313 interoperable format for transmitting private keys, such as PKCS #12 314 [RFC7292] or CMP / CRMF [RFC4210], [RFC4211]. It is not intended to 315 dictate a storage format in implementations not requiring 316 interoperability of private key formats. 318 In some cases the private keys that comprise a composite key may not 319 be represented in a single structure or even be contained in a single 320 cryptographic module. The establishment of correspondence between 321 public keys in a CompositePublicKey and private keys not represented 322 in a single composite structure is beyond the scope of this document. 324 The composite private key data is represented by the following 325 structure: 327 CompositePrivateKey ::= SEQUENCE SIZE (2..MAX) OF OneAsymmetricKey 329 Each element is a OneAsymmetricKey [RFC5958] object for a component 330 private key. 332 The parameters field MUST be absent. 334 A CompositePrivateKey MUST contain at least two component private 335 keys, and they MUST be in the same order as in the corresponding 336 CompositePublicKey. 338 EDNOTE: does this also need an explicit version? It would probably 339 reduce attack surface of tricking a client into running the wrong 340 parser and a given piece of data. 342 3.4. Encoding Rules 344 Many protocol specifications will require that the composite public 345 key and composite private key data structures be represented by an 346 octet string or bit string. 348 When an octet string is required, the DER encoding of the composite 349 data structure SHALL be used directly. 351 CompositePublicKeyOs ::= OCTET STRING (CONTAINING CompositePublicKey ENCODED BY der) 353 EDNOTE: will this definition include an ASN.1 tag and length byte 354 inside the OCTET STRING object? If so, that's probably an extra 355 uneccessary layer. 357 When a bit string is required, the octets of the DER encoded 358 composite data structure SHALL be used as the bits of the bit string, 359 with the most significant bit of the first octet becoming the first 360 bit, and so on, ending with the least significant bit of the last 361 octet becoming the last bit of the bit string. 363 CompositePublicKeyBs ::= BIT STRING (CONTAINING CompositePublicKey ENCODED BY der) 365 4. Algorithm Identifiers 367 This section defines the algorithm identifier for generic composite, 368 as well as a framework for defining explicit combinations. This 369 section is not intended to be exhaustive and other authors may define 370 others so long as they are compatible with the structures and 371 processes defined in this and companion signature and encryption 372 documents. 374 Some use-cases desire the flexibility for client to use any 375 combination of supported algorithms, while others desire the rigidity 376 of explicitly-specified combinations of algorithms. 378 4.1. id-composite-key (Generic Composite Keys) 380 The id-composite-key algorithm identifier is used for identifying a 381 generic composite public key and a generic composite private key. 382 This allows arbitrary combinations of key types to be placed in the 383 CompositePublicKey and CompositePrivateKey structures without needing 384 the combination to be pre-registered or pre-agreed. 386 id-composite-key OBJECT IDENTIFIER ::= { 387 joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027) 388 Algorithm(80) Composite(4) CompositeKey(1) } 390 EDNOTE: this is a temporary OID for the purposes of prototyping. We 391 are requesting IANA to assign a permanent OID, see Section 6. 393 Which yields an information object: 395 pk-Composite PUBLIC-KEY ::= { 396 id id-composite-key, 397 KeyValue CompositePublicKey, 398 Params ARE ABSENT, 399 PrivateKey CompositePrivateKey, 400 } 402 The motivation for this variant is primarily for prototyping work 403 prior to the standardization of algorithm identifiers for explicit 404 combinations of algorithms. However, the authors envision that this 405 variant will remain relevant beyond full standardization for example 406 in environments requiring very high levels of crypto agility, for 407 example where clients support a large number of algorithms or where a 408 large number of keys will be used at a time and it is therefore 409 prohibitive to define algorithm identifiers for every combination of 410 pairs, triples, quadruples, etc of algorithms. 412 4.2. Explicit Composite Keys 414 This variant provides a rigid way of specifying supported 415 combinations of key types. This document does not define any 416 explicit combinations, but provides a framework for doing so. 418 The motivation for this variant is to make it easier to reference and 419 enforce specific combinations of algorithms. The authors envision 420 this being useful for client-server negotiated protocols, protocol 421 designers who wish to place constraints on allowable algorithm 422 combinations in the protocol specification, as well as audited 423 environments that wish to prove that only certain combinations will 424 be supported by clients. 426 Profiles need to define an explicit composite key type which consists 427 of: 429 * A new algorithm identifier OID for the explicit algorithm. 431 * The PUBLIC-KEY information object of each component public key 432 type. 434 See Appendix A for guidance on creating and registering OIDs for 435 specific explicit combinations. 437 In this variant, the public key is encoded as defined in Section 3 438 and Section 3.2, however the PUBLIC-KEY.id SHALL be an OID which is 439 registered to represent a specific combination of component public 440 key types. See Appendix B for examples. 442 The SubjectPublicKeyInfo.algorithm for each component key is 443 redundant information which MUST match -- and can be inferred from -- 444 the specification of the explicit algorithm. It has been left here 445 for ease of implementation as the component SubjectPublicKeyInfo 446 structures are the same between generic and explicit, as well as with 447 single-algorithm keys. However, it introduces the risk of mismatch 448 and leads to the following security consideration: 450 Security consideration: Implementations MUST check that the component 451 AlgorithmIdentifier OIDs and parameters match those expected by the 452 definition of the explicit algorithm. Implementations SHOULD first 453 parse a component's SubjectPublicKeyInfo.algorithm, and ensure that 454 it matches what is expected for that position in the explicit key, 455 and then proceed to parse the SubjectPublicKeyInfo.subjectPublicKey. 456 This is to reduce the attack surface associated with parsing the 457 public key data of an unexpected key type, or worse; to parse and use 458 a key which does not match the explicit algorithm definition. 459 Similar checks MUST be done when handling the corresponding private 460 key. 462 5. Implementation Considerations 464 This section addresses practical issues of how this draft affects 465 other protocols and standards. 467 EDNOTE 10: Possible topics to address: 469 * The size of these certs and cert chains. 471 * In particular, implications for (large) composite keys / 472 signatures / certs on the handshake stages of TLS and IKEv2. 474 * If a cert in the chain is a composite cert then does the whole 475 chain need to be of composite Certs? 477 * We could also explain that the root CA cert does not have to be of 478 the same algorithms. The root cert SHOULD NOT be transferred in 479 the authentication exchange to save transport overhead and thus it 480 can be different than the intermediate and leaf certs. 482 5.1. Textual encoding of Composite Private Keys 484 CompositePrivateKeys can be encoded to the Privacy-Enhanced Mail 485 (PEM) [RFC1421] format by placing a CompositePrivateKey into the 486 privateKey field of a PrivateKeyInfo or OneAsymmetricKey object, and 487 then applying the PEM encoding rules as defined in [RFC7468] section 488 10 and 11 for plaintext and encrypted private keys, respectively. 490 5.2. Asymmetric Key Packages (CMS) 492 The Cryptographic Message Syntax (CMS), as defined in [RFC5652], can 493 be used to digitally sign, digest, authenticate, or encrypt the 494 asymmetric key format content type. 496 When encoding composite private keys, the privateKeyAlgorithm in the 497 OneAsymmetricKey SHALL be set to id-composite-key or to an OID 498 corresponding to an explicit composite key. 500 The parameters of the privateKeyAlgorithm SHALL be a sequence of 501 AlgorithmIdentifier objects, each of which are encoded according to 502 the rules defined for each of the different keys in the composite 503 private key. 505 The value of the privateKey field in the OneAsymmetricKey SHALL be 506 set to the DER encoding of the SEQUENCE of private key values that 507 make up the composite key. The number and order of elements in the 508 sequence SHALL be the same as identified in the sequence of 509 parameters in the privateKeyAlgorithm. 511 The value of the publicKey (if present) SHALL be set to the DER 512 encoding of the corresponding CompositePublicKey. If this field is 513 present, the number and order of component keys MUST be the same as 514 identified in the sequence of parameters in the privateKeyAlgorithm. 516 The value of the attributes is encoded as usual. 518 EDNOTE: I wonder whether this has value as its own section, or if we 519 should take what's relevant and merge it into Section 3.3? 521 5.3. Backwards Compatibility 523 As noted in the introduction, the post-quantum cryptographic 524 migration will face challenges in both ensuring cryptographic 525 strength against adversaries of unknown capabilities, as well as 526 providing ease of migration. The composite mechanisms defined in 527 this document primarily address cryptographic strength, however this 528 section contains notes on how backwards compatibility may be 529 obtained. 531 The term "ease of migration" is used here to mean that existing 532 systems can be gracefully transitioned to the new technology without 533 requiring large service disruptions or expensive upgrades. The term 534 "backwards compatibility" is used here to mean something more 535 specific; that existing systems as they are deployed today can 536 interoperate with the upgraded systems of the future. 538 These migration and interoperability concerns need to be thought 539 about in the context of various types of protocols that make use of 540 X.509 and PKIX with relation to public key objects, from online 541 negotiated protocols such as TLS 1.3 [RFC8446] and IKEv2 [RFC7296], 542 to non-negotiated asynchronous protocols such as S/MIME signed and 543 encrypted email [RFC8551], document signing such as in the context of 544 the European eIDAS regulations [eIDAS2014], and publicly trusted code 545 signing [codeSigningBRsv2.8], as well as myriad other standardized 546 and proprietary protocols and applications that leverage CMS 547 [RFC5652] signed or encrypted structures. 549 5.3.1. OR modes 551 This document purposefully does not specify how clients are to 552 combine component keys together to form a single cryptographic 553 operation; this is left up to the specifications of signature and 554 encryption algorithms that make use of the composite key type. One 555 possible way to combine component keys is through an OR relation, or 556 OR-like client policies for acceptable algorithm combinations, where 557 senders and / or receivers are permitted to ignore some component 558 keys. Some envisioned uses of this include environments where the 559 client encounters a component key for which it does not possess a 560 compatible algorithm implementation but wishes to proceed with the 561 cryptographic operation using the subset of component keys for which 562 it does have compatible implementations. Such a mechanism could be 563 designed to provide ease of migration by allowing for composite keys 564 to be distributed and used before all clients in the environment are 565 fully upgraded, but it does not allow for full backwards 566 compatibility since clients would at least need to be upgraded from 567 their current state to be able to parse the composite structures. 569 5.3.2. Parallel PKIs 571 We present the term "Parallel PKI" to refer to the setup where a PKI 572 end entity possesses two or more distinct public keys or certificates 573 for the same key type (signature, key establishment, etc) for the 574 same identity (name, SAN), but containing keys for different 575 cryptographic algorithms. One could imagine a set of parallel PKIs 576 where an existing PKI using legacy algorithms (RSA, ECC) is left 577 operational during the post-quantum migration but is shadowed by one 578 or more parallel PKIs using pure post quantum algorithms or composite 579 algorithms (legacy and post-quantum). 581 Equipped with a set of parallel public keys in this way, a client 582 would have the flexibility to choose which public key(s) or 583 certificate(s) to use in a given cryptographic operation. 585 For negotiated protocols, the client could choose which public key(s) 586 or certificate(s) to use based on the negotiated algorithms, or could 587 combine two of the public keys for example in a non-composite hybrid 588 method such as [draft-becker-guthrie-noncomposite-hybrid-auth-00] 589 (NOTE: need kramdown formatting help with this ref) or [draft- 590 guthrie-ipsecme-ikev2-hybrid-auth-00]. Note that it is possible to 591 use the signature algorithm defined in [draft-ounsworth-pq-composite- 592 sigs-06] as a way to carry the multiple signature values generated by 593 a non-composite public mechanism in protocols where it is easier to 594 support the composite signature algorithms than to implement such a 595 mechanism in the protocol itself. There is also nothing precluding a 596 composite public key from being one of the components used within a 597 non-composite authentication operation; this may lead to greater 598 convenience in setting up parallel PKI hierarchies that need to 599 service a range of clients implementing different styles of post- 600 quantum migration strategies. 602 For non-negotiated protocols, the details for obtaining backwards 603 compatibility will vary by protocol, but for example in CMS 604 [RFC5652], the inclusion of multiple SignerInfo or RecipientInfo 605 objects is often already treated as an OR relationship, so including 606 one for each of the end entity's parallel PKI public keys would, in 607 many cases, have the desired effect of allowing the receiver to 608 choose one they are compatible with and ignore the others, thus 609 achieving full backwards compatibility. 611 6. IANA Considerations 613 The ASN.1 module OID is TBD. The id-composite-key and id-composite- 614 or-key OIDs are to be assigned by IANA. The authors suggest that 615 IANA assign an OID on the id-pkix arc: 617 id-composite-key OBJECT IDENTIFIER ::= { 618 iso(1) identified-organization(3) dod(6) internet(1) security(5) 619 mechanisms(5) pkix(7) algorithms(6) composite(??) } 621 7. Security Considerations 623 7.1. Reuse of keys in a Composite public key 625 There is an additional security consideration that some use cases 626 such as signatures remain secure against downgrade attacks if and 627 only if component keys are never used outside of their composite 628 context and therefore it is RECOMMENDED that component keys in a 629 composite key are not to be re-used in other contexts. In 630 particular, the components of a composite key SHOULD NOT also appear 631 in single-key certificates. This is particularly relevant for 632 protocols that use composite keys in a logical AND mode since the 633 appearance of the same component keys in single-key contexts 634 undermines the binding of the component keys into a single composite 635 key by allowing messages signed in a multi-key AND mode to be 636 presented as if they were signed in a single key mode in what is 637 known as a "stripping attack". 639 7.2. Key mismatch in explicit composite 641 This security consideration copied from Section 4.2. 643 Implementations MUST check that that the component 644 AlgorithmIdentifier OIDs and parameters match those expected by the 645 definition of the explicit algorithm. Implementations SHOULD first 646 parse a component's SubjectPublicKeyInfo.algorithm, and ensure that 647 it matches what is expected for that position in the explicit key, 648 and then proceed to parse the SubjectPublicKeyInfo.subjectPublicKey. 649 This is to reduce the attack surface associated with parsing the 650 public key data of an unexpected key type, or worse; to parse and use 651 a key which does not match the explicit algorithm definition. 652 Similar checks MUST be done when handling the corresponding private 653 key. 655 7.3. Policy for Deprecated and Acceptable Algorithms 657 Traditionally, a public key, certificate, or signature contains a 658 single cryptographic algorithm. If and when an algorithm becomes 659 deprecated (for example, RSA-512, or SHA1), it is obvious that 660 clients performing signature verification or encryption operations 661 should be updated to fail to validate or refuse to encrypt for these 662 algorithms. 664 In the composite model this is less obvious since implementers may 665 decide that certain cryptographic algorithms have complementary 666 security properties and are acceptable in combination even though one 667 or both algorithms are deprecated for individual use. As such, a 668 single composite public key, certificate, signature, or ciphertext 669 MAY contain a mixture of deprecated and non-deprecated algorithms. 671 Specifying behaviour in these cases is beyond the scope of this 672 document, but should be considered by implementers and potentially in 673 additional standards. 675 EDNOTE: Max is working on a CRL mechanism to accomplish this. 677 7.4. Protection of Private Keys 679 Structures described in this document do not protect private keys in 680 any way unless combined with a security protocol or encryption 681 properties of the objects (if any) where the CompositePrivateKey is 682 used (see next Section). 684 Protection of the private keys is vital to public key cryptography. 685 The consequences of disclosure depend on the purpose of the private 686 key. If a private key is used for signature, then the disclosure 687 allows unauthorized signing. If a private key is used for key 688 management, then disclosure allows unauthorized parties to access the 689 managed keying material. The encryption algorithm used in the 690 encryption process must be at least as 'strong' as the key it is 691 protecting. 693 7.5. Checking for Compromised Key Reuse 695 Certification Authority (CA) implementations need to be careful when 696 checking for compromised key reuse, for example as required by 697 WebTrust regulations; when checking for compromised keys, you MUST 698 unpack the CompositePublicKey structure and compare individual 699 component keys. In other words, for the purposes of key reuse 700 checks, the composite public key structures need to be un-packed so 701 that primitive keys are being compared. For example if the composite 702 key {RSA1, PQ1} is revoked for key compromise, then the keys RSA1 and 703 PQ1 need to be individually considered revoked. If the composite key 704 {RSA1, PQ2} is submitted for certification, it SHOULD be rejected 705 because the key RSA1 was previously declared compromised even though 706 the key PQ2 is unique. 708 8. References 710 8.1. Normative References 712 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 713 Mail: Part I: Message Encryption and Authentication 714 Procedures", RFC 1421, DOI 10.17487/RFC1421, February 715 1993, . 717 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 718 Requirement Levels", BCP 14, RFC 2119, 719 DOI 10.17487/RFC2119, March 1997, 720 . 722 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 723 Request Syntax Specification Version 1.7", RFC 2986, 724 DOI 10.17487/RFC2986, November 2000, 725 . 727 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 728 Housley, R., and W. Polk, "Internet X.509 Public Key 729 Infrastructure Certificate and Certificate Revocation List 730 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 731 . 733 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 734 RFC 5652, DOI 10.17487/RFC5652, September 2009, 735 . 737 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 738 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 739 DOI 10.17487/RFC5912, June 2010, 740 . 742 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 743 Format", RFC 5914, DOI 10.17487/RFC5914, June 2010, 744 . 746 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 747 DOI 10.17487/RFC5958, August 2010, 748 . 750 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 751 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 752 April 2015, . 754 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 755 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 756 May 2017, . 758 [RFC8411] Schaad, J. and R. Andrews, "IANA Registration for the 759 Cryptographic Algorithm Object Identifier Range", 760 RFC 8411, DOI 10.17487/RFC8411, August 2018, 761 . 763 [X.690] ITU-T, "Information technology - ASN.1 encoding Rules: 764 Specification of Basic Encoding Rules (BER), Canonical 765 Encoding Rules (CER) and Distinguished Encoding Rules 766 (DER)", ISO/IEC 8825-1:2015, November 2015. 768 8.2. Informative References 770 [Bindel2017] 771 Bindel, N., Herath, U., McKague, M., and D. Stebila, 772 "Transitioning to a quantum-resistant public key 773 infrastructure", 2017, . 776 [codeSigningBRsv2.8] 777 CAB Forum, ., "Baseline Requirements for the Issuance and 778 Management of Publicly-Trusted Code Signing Certificates 779 v2.8", May 2022, . 783 [eIDAS2014] 784 "REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT 785 AND OF THE COUNCIL of 23 July 2014 on electronic 786 identification and trust services for electronic 787 transactions in the internal market and repealing 788 Directive 1999/93/EC", July 2014, 789 . 792 [I-D.becker-guthrie-noncomposite-hybrid-auth] 793 Becker, A., Guthrie, R., and M. J. Jenkins, "Non-Composite 794 Hybrid Authentication in PKIX and Applications to Internet 795 Protocols", Work in Progress, Internet-Draft, draft- 796 becker-guthrie-noncomposite-hybrid-auth-00, 22 March 2022, 797 . 800 [I-D.guthrie-ipsecme-ikev2-hybrid-auth] 801 Guthrie, R., "Hybrid Non-Composite Authentication in 802 IKEv2", Work in Progress, Internet-Draft, draft-guthrie- 803 ipsecme-ikev2-hybrid-auth-00, 25 March 2022, 804 . 807 [I-D.ounsworth-pq-composite-sigs] 808 Ounsworth, M. and M. Pala, "Composite Signatures For Use 809 In Internet PKI", Work in Progress, Internet-Draft, draft- 810 ounsworth-pq-composite-sigs-05, 12 July 2021, 811 . 814 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 815 Identifiers for the Internet X.509 Public Key 816 Infrastructure Certificate and Certificate Revocation List 817 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 818 2002, . 820 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 821 "Internet X.509 Public Key Infrastructure Certificate 822 Management Protocol (CMP)", RFC 4210, 823 DOI 10.17487/RFC4210, September 2005, 824 . 826 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 827 Certificate Request Message Format (CRMF)", RFC 4211, 828 DOI 10.17487/RFC4211, September 2005, 829 . 831 [RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., 832 and M. Scott, "PKCS #12: Personal Information Exchange 833 Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, 834 . 836 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 837 Kivinen, "Internet Key Exchange Protocol Version 2 838 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 839 2014, . 841 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 842 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 843 . 845 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 846 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 847 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 848 April 2019, . 850 Appendix A. Creating explicit combinations 852 The following ASN.1 Information Objects may be useful in defining and 853 parsing explicit pairs of public key types. Given an ASN.1 2002 854 compliant ASN.1 compiler, these Information Objects will enforce the 855 binding between the public key types specified in the instantiation 856 of pk-explicitComposite, and the wire objects which implement it. 857 The one thing that is not enforced automatically by this Information 858 Object is that publicKey.params are intended to be absent if and only 859 if they are absent for the declared public key type. This ASN.1 860 module declares them OPTIONAL and leaves it to implementers to 861 perform this check explicitly. 863 EDNOTE this ASN.1 needs to change. The current definition doesn't 864 put a component AlgorithmIdentifier with each component key. Once we 865 agree as a group that the text accurately describes what we want, we 866 can spend a bit of time figuring out if the ASN.1 machinery lets us 867 express it in a readable way and/or a way that will actually help 868 people creating explicit pairs. 870 -- pk-explicitComposite - Composite public key information object 872 pk-explicitComposite{OBJECT IDENTIFIER:id, PUBLIC-KEY:firstPublicKey, 873 FirstPublicKeyType, PUBLIC-KEY:secondPublicKey, SecondPublicKeyType} 874 PUBLIC-KEY ::= {PUBLIC-KEYPUBLIC-KEY 875 IDENTIFIER id 876 KEY ExplicitCompositePublicKey{firstPublicKey, FirstPublicKeyType, 877 secondPublicKey, SecondPublicKeyType} 878 PARAMS ARE absent 879 CERT-KEY-USAGE {digitalSignature, nonRepudiation, keyCertSign, 880 cRLSign} 881 } 883 The following ASN.1 object class then automatically generates the 884 public key structure from the types defined in pk-explicitComposite. 886 -- ExplicitCompositePublicKey - The data structure for a composite 887 -- public key sec-composite-pub-keys and SecondPublicKeyType are needed 888 -- because PUBLIC-KEY contains a set of public key types, not a single 889 -- type. 890 -- TODO The parameters should be optional only if they are marked 891 -- optional in the PUBLIC-KEY. 893 ExplicitCompositePublicKey{PUBLIC-KEY:firstPublicKey, FirstPublicKeyType, 894 PUBLIC-KEY:secondPublicKey, SecondPublicKeyType} ::= SEQUENCE { 895 firstPublicKey SEQUENCE { 896 params firstPublicKey.&Params OPTIONAL, 897 publicKey FirstPublicKeyType 898 }, 899 secondPublicKey SEQUENCE { 900 params secondPublicKey.&Params OPTIONAL, 901 publicKey SecondPublicKeyType 902 } 903 } 905 Using this module, it becomes trivial to define explicit pairs. For 906 an example, see Appendix B.2. 908 To define explicit triples, quadruples, etc, these Information 909 Objects can be extended to have thirdPublicKey, fourthPublicKey, etc 910 throughout. 912 Appendix B. Examples 914 B.1. Generic Composite Public Key Examples 916 This is an example generic composite public key 918 -----BEGIN PUBLIC KEY----- 919 MIIBmDAMBgpghkgBhvprUAQBA4IBhgAwggGBMFkwEwYHKoZIzj0CAQYIKoZIzj0D 920 AQcDQgAExGPhrnuSG/fGyw1FN+l5h4p4AGRQCS0LBXnBO+djhcI6qnF2TvrQEaIY 921 GGpQT5wHS+7y5iJJ+dE5qjxcv8loRDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC 922 AQoCggEBANsVQK1fcLQObL4ZYtczWbObECAFSsng0OLpRTPr9VGV3SsS/VoMRZqX 923 F+sszz6I2UcFTaMF9CwNRbWLuIBczzuhbHSjn65OuoN+Om2wsPo+okw46RTekB4a 924 d9QQvYRVzPlILUQ8NvZ4W0BKLviXTXWIggjtp/Y1pKRHKz8n35J6OmFWz4TKGNth 925 n87D28kmdwQYH5NLsDePHbfdw3AyLrPvQLlQw/hRPz/9Txf7yi9Djg9HtJ88ES6+ 926 ZbfE1ZHxLYLSDt25tSL8A2pMuGMD3P81nYWO+gJ0vYV2WcRpXHRkjmliGqiCg4eB 927 mC4//tm0J4r9Ll8b/pp6xyOMI7jppVUCAwEAAQ== 928 -----END PUBLIC KEY----- 930 which decodes as: 932 algorithm: AlgorithmIdentifier{id-composite-key} 934 subjectPublicKey: CompositePublicKey { 935 SubjectPublicKeyInfo { 936 algorithm: AlgorithmIdentifier { 937 algorithm: ecPublicKey 938 parameters: prime256v1 939 } 940 subjectPublicKey: 941 }, 942 SubjectPublicKeyInfo { 943 algorithm: AlgorithmIdentifier { 944 algorithm: rsaEncryption 945 parameters: NULL 946 } 947 subjectPublicKey: 948 } 949 } 951 The corresponding generic private key is: 953 -----BEGIN PRIVATE KEY----- 954 MIIFHgIBADAMBgpghkgBhvprUAQBBIIFCTCCBQUwQQIBADATBgcqhkjOPQIBBggq 955 hkjOPQMBBwQnMCUCAQEEICN0ihCcgg5n8ALtk9tkQZqg/WLEm5NefMi/kdN06Z9u 956 MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDbFUCtX3C0Dmy+ 957 GWLXM1mzmxAgBUrJ4NDi6UUz6/VRld0rEv1aDEWalxfrLM8+iNlHBU2jBfQsDUW1 958 i7iAXM87oWx0o5+uTrqDfjptsLD6PqJMOOkU3pAeGnfUEL2EVcz5SC1EPDb2eFtA 959 Si74l011iIII7af2NaSkRys/J9+SejphVs+EyhjbYZ/Ow9vJJncEGB+TS7A3jx23 960 3cNwMi6z70C5UMP4UT8//U8X+8ovQ44PR7SfPBEuvmW3xNWR8S2C0g7dubUi/ANq 961 TLhjA9z/NZ2FjvoCdL2FdlnEaVx0ZI5pYhqogoOHgZguP/7ZtCeK/S5fG/6aescj 962 jCO46aVVAgMBAAECggEAFtT6LpdZuYofTxh6Mo9Jc+xfG9cxWiSx4FQLQEQBBwWl 963 TQ3nlXDd+CRy+7Fpz8yXSE2HL8w5DDY945OyIL6LYl2KXgWHaLUPvxByqmfVqd7J 964 L0RnFiOzxU9g2Zr9BUOj3v7kqM3VtI4KhIK2rnWmPu+BDckmzgP9Kpm4KhbPuAYP 965 iqUZSkxpSUsd5ALLsk9b0xjR7UEYkEpV2/vORwieEhOmPLzuXh+Px0yavkazT/vU 966 +h/rDSoLQn7v4fVsQgNdOaaOG/gHemGuuiLPJJlX5ZZ6mmsIaEjz+MNk0aJDH2po 967 KbAr4B709dTsnYgv7YtkEfSyOeMEdhMiswI1c9FpwQKBgQD6kdHmHCoeWNNvlqxU 968 v57e7ZDAXDA6WcfrypcsF0l72rI3J8oOPmFaNaCmwIH/Icz+Zy7fr2IYxVjyDjCa 969 zi8qTnj2ZNds71hUYOcq60u0TcSVrtocA4HW7NoWJqK5thNlNaa1M358cYBopGoN 970 ocS9yf10q2MBZtpF0fc5PbFf+QKBgQDf1L4cezoebbNTaN4KoapycHXxKozP2GwI 971 r15YRYjt0ZpHstdUPABQuwlL9CuL+5Q17VRiM81cUVNfFsBzKIXYb/PBC5UD+DmR 972 qGlT6v6uUWY6jifUgEjfyPxO0oJ3M6cChHR/TvpkT5SyaEwHpIH7IeXbMFcS5m4G 973 mSNBECO/PQKBgCD0CoHT1Go3Tl9PloxywwcYgT/7H9CcvCEzfJws19o1EdkVH4qu 974 A4mkoeMsUCxompgeo9iBLUqKsb7rxNKnKSbMOTZWXsqR07ENKXnIhiVJUQBKhZ7H 975 i0zjy268WAxKeNSHsMwF4K2nE7cvYE84pjI7nVy5qYSmrTAfg/8AMRKpAoGBAN/G 976 wN6WsE9Vm5BLapo0cMUC/FdFFAyEMdYpBei4dCJXiKgf+7miVypfI/dEwPitZ8rW 977 YKPhaHHgeLq7c2JuZAo0Ov2IR831MBEYz1zvtvmuNcda8iU4sCLTvLRNL9Re1pzk 978 sdfJrPn2uhH3xfNqG+1oQXZ3CMbDi8Ka/a0Bpst9AoGBAPR4p6WN0aoZlosyT6NI 979 4mqzNvLE4KBasmfoMmTJih7qCP3X4pqdgiI0SjsQQG/+utHLoJARwzhWHOZf1JKk 980 D8lSJH02cp/Znrjn5wPpfYKLphJBiKSPwyIjuFwcR1ck84ONeYq421NDqf7lXbvx 981 oMqjTPagXUpzHvwluDjtSi8+ 982 -----END PRIVATE KEY----- 984 which decodes as: 986 algorithm: AlgorithmIdentifier{id-composite-key} 988 SEQUENCE { 989 OneAsymmetricKey { 990 version: 0, 991 privateKeyAlgorithm: PrivateKeyAlgorithmIdentifier{ 992 algorithm: ecPublicKey 993 parameters: prime256v1 994 } 995 privateKey: 996 }, 997 OneAsymmetricKey { 998 version: 0, 999 privateKeyAlgorithm: PrivateKeyAlgorithmIdentifier{ 1000 algorithm: rseEncryption 1001 parameters: NULL 1002 } 1003 privateKey: 1004 } 1005 } 1007 B.2. Explicit Composite Public Key Examples 1009 Assume that the following is a defined explicit pair: 1011 id-pk-example-ECandRSA OBJECT IDENTIFIER ::= { 1 2 3 4 } 1013 pk-example-ECandRSA PUBLIC-KEY ::= pk-explicitComposite{ 1014 id-pk-example-ECandRSA, 1015 ecPublicKey, 1016 pk-ec, 1017 rsaEncryption, 1018 pk-rsa, 1019 } 1021 Then the same key as above could be encoded as an explicit composite 1022 public key as: 1024 -----BEGIN PUBLIC KEY----- 1025 MIIBkTAFBgMqAwQDggGGADCCAYEwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATE 1026 Y+Gue5Ib98bLDUU36XmHingAZFAJLQsFecE752OFwjqqcXZO+tARohgYalBPnAdL 1027 7vLmIkn50TmqPFy/yWhEMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 1028 2xVArV9wtA5svhli1zNZs5sQIAVKyeDQ4ulFM+v1UZXdKxL9WgxFmpcX6yzPPojZ 1029 RwVNowX0LA1FtYu4gFzPO6FsdKOfrk66g346bbCw+j6iTDjpFN6QHhp31BC9hFXM 1030 +UgtRDw29nhbQEou+JdNdYiCCO2n9jWkpEcrPyffkno6YVbPhMoY22GfzsPbySZ3 1031 BBgfk0uwN48dt93DcDIus+9AuVDD+FE/P/1PF/vKL0OOD0e0nzwRLr5lt8TVkfEt 1032 gtIO3bm1IvwDaky4YwPc/zWdhY76AnS9hXZZxGlcdGSOaWIaqIKDh4GYLj/+2bQn 1033 iv0uXxv+mnrHI4wjuOmlVQIDAQAB 1034 -----END PUBLIC KEY----- 1036 which decodes as: 1038 algorithm: AlgorithmIdentifier{id-pk-example-ECandRSA} 1040 subjectPublicKey: CompositePublicKey { 1041 SubjectPublicKeyInfo { 1042 algorithm: AlgorithmIdentifier { 1043 algorithm: ecPublicKey 1044 parameters: prime256v1 1045 } 1046 subjectPublicKey: 1047 }, 1048 SubjectPublicKeyInfo { 1049 algorithm: AlgorithmIdentifier { 1050 algorithm: rsaEncryption 1051 parameters: NULL 1052 } 1053 subjectPublicKey: 1054 } 1055 } 1057 The corresponding explicit private key is: 1059 -----BEGIN PRIVATE KEY----- 1060 MIIFFwIBADAFBgMqAwQEggUJMIIFBTBBAgEAMBMGByqGSM49AgEGCCqGSM49AwEH 1061 BCcwJQIBAQQgI3SKEJyCDmfwAu2T22RBmqD9YsSbk158yL+R03Tpn24wggS+AgEA 1062 MA0GCSqGSIb3DQEBAQUABIIEqDCCBKQCAQACggEBANsVQK1fcLQObL4ZYtczWbOb 1063 ECAFSsng0OLpRTPr9VGV3SsS/VoMRZqXF+sszz6I2UcFTaMF9CwNRbWLuIBczzuh 1064 bHSjn65OuoN+Om2wsPo+okw46RTekB4ad9QQvYRVzPlILUQ8NvZ4W0BKLviXTXWI 1065 ggjtp/Y1pKRHKz8n35J6OmFWz4TKGNthn87D28kmdwQYH5NLsDePHbfdw3AyLrPv 1066 QLlQw/hRPz/9Txf7yi9Djg9HtJ88ES6+ZbfE1ZHxLYLSDt25tSL8A2pMuGMD3P81 1067 nYWO+gJ0vYV2WcRpXHRkjmliGqiCg4eBmC4//tm0J4r9Ll8b/pp6xyOMI7jppVUC 1068 AwEAAQKCAQAW1Poul1m5ih9PGHoyj0lz7F8b1zFaJLHgVAtARAEHBaVNDeeVcN34 1069 JHL7sWnPzJdITYcvzDkMNj3jk7IgvotiXYpeBYdotQ+/EHKqZ9Wp3skvRGcWI7PF 1070 T2DZmv0FQ6Pe/uSozdW0jgqEgraudaY+74ENySbOA/0qmbgqFs+4Bg+KpRlKTGlJ 1071 Sx3kAsuyT1vTGNHtQRiQSlXb+85HCJ4SE6Y8vO5eH4/HTJq+RrNP+9T6H+sNKgtC 1072 fu/h9WxCA105po4b+Ad6Ya66Is8kmVfllnqaawhoSPP4w2TRokMfamgpsCvgHvT1 1073 1OydiC/ti2QR9LI54wR2EyKzAjVz0WnBAoGBAPqR0eYcKh5Y02+WrFS/nt7tkMBc 1074 MDpZx+vKlywXSXvasjcnyg4+YVo1oKbAgf8hzP5nLt+vYhjFWPIOMJrOLypOePZk 1075 12zvWFRg5yrrS7RNxJWu2hwDgdbs2hYmorm2E2U1prUzfnxxgGikag2hxL3J/XSr 1076 YwFm2kXR9zk9sV/5AoGBAN/Uvhx7Oh5ts1No3gqhqnJwdfEqjM/YbAivXlhFiO3R 1077 mkey11Q8AFC7CUv0K4v7lDXtVGIzzVxRU18WwHMohdhv88ELlQP4OZGoaVPq/q5R 1078 ZjqOJ9SASN/I/E7SgnczpwKEdH9O+mRPlLJoTAekgfsh5dswVxLmbgaZI0EQI789 1079 AoGAIPQKgdPUajdOX0+WjHLDBxiBP/sf0Jy8ITN8nCzX2jUR2RUfiq4DiaSh4yxQ 1080 LGiamB6j2IEtSoqxvuvE0qcpJsw5NlZeypHTsQ0peciGJUlRAEqFnseLTOPLbrxY 1081 DEp41IewzAXgracTty9gTzimMjudXLmphKatMB+D/wAxEqkCgYEA38bA3pawT1Wb 1082 kEtqmjRwxQL8V0UUDIQx1ikF6Lh0IleIqB/7uaJXKl8j90TA+K1nytZgo+FoceB4 1083 urtzYm5kCjQ6/YhHzfUwERjPXO+2+a41x1ryJTiwItO8tE0v1F7WnOSx18ms+fa6 1084 EffF82ob7WhBdncIxsOLwpr9rQGmy30CgYEA9HinpY3RqhmWizJPo0jiarM28sTg 1085 oFqyZ+gyZMmKHuoI/dfimp2CIjRKOxBAb/660cugkBHDOFYc5l/UkqQPyVIkfTZy 1086 n9meuOfnA+l9goumEkGIpI/DIiO4XBxHVyTzg415irjbU0Op/uVdu/GgyqNM9qBd 1087 SnMe/CW4OO1KLz4= 1088 -----END PRIVATE KEY----- 1090 which decodes as: 1092 algorithm: AlgorithmIdentifier{id-pk-example-ECandRSA} 1094 SEQUENCE { 1095 OneAsymmetricKey { 1096 version: 0, 1097 privateKeyAlgorithm: PrivateKeyAlgorithmIdentifier{ 1098 algorithm: ecPublicKey 1099 parameters: prime256v1 1100 } 1101 privateKey: 1102 }, 1103 OneAsymmetricKey { 1104 version: 0, 1105 privateKeyAlgorithm: PrivateKeyAlgorithmIdentifier{ 1106 algorithm: rseEncryption 1107 parameters: NULL 1108 } 1109 privateKey: 1110 } 1111 } 1113 Appendix C. ASN.1 Module 1115 1117 Composite-Keys-2022 1119 DEFINITIONS IMPLICIT TAGS ::= BEGIN 1121 EXPORTS ALL; 1123 IMPORTS 1124 PUBLIC-KEY, SIGNATURE-ALGORITHM, ParamOptions, AlgorithmIdentifier{} 1125 FROM AlgorithmInformation-2009 -- RFC 5912 [X509ASN1] 1126 { iso(1) identified-organization(3) dod(6) internet(1) 1127 security(5) mechanisms(5) pkix(7) id-mod(0) 1128 id-mod-algorithmInformation-02(58) } 1130 SubjectPublicKeyInfo 1131 FROM PKIX1Explicit-2009 1132 { iso(1) identified-organization(3) dod(6) internet(1) 1133 security(5) mechanisms(5) pkix(7) id-mod(0) 1134 id-mod-pkix1-explicit-02(51) } 1136 OneAsymmetricKey 1137 FROM AsymmetricKeyPackageModuleV1 1138 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1139 pkcs-9(9) smime(16) modules(0) 1140 id-mod-asymmetricKeyPkgV1(50) } ; 1142 -- 1143 -- Object Identifiers 1144 -- 1146 der OBJECT IDENTIFIER ::= 1147 {joint-iso-itu-t asn1(1) ber-derived(2) distinguished-encoding(1)} 1149 -- To be replaced by IANA 1150 id-composite-key OBJECT IDENTIFIER ::= { 1151 joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027) 1152 Algorithm(80) Composite(4) CompositeKey(1) 1154 -- COMPOSITE-KEY-ALGORITHM 1155 -- 1156 -- Describes the basic properties of a composite key algorithm 1157 -- 1158 -- &id - contains the OID identifying the composite algorithm 1159 -- &Params - if present, contains the type for the algorithm 1160 -- parameters; if absent, implies no parameters 1161 -- ¶mPresence - parameter presence requirement 1162 -- 1163 -- } 1165 COMPOSITE-KEY-ALGORITHM ::= CLASS { 1166 &id OBJECT IDENTIFIER UNIQUE, 1167 &Params OPTIONAL, 1168 ¶mPresence ParamOptions DEFAULT absent 1169 } WITH SYNTAX { 1170 IDENTIFIER &id 1171 [PARAMS [TYPE &Params] ARE ¶mPresence ] 1172 } 1174 CompositeAlgorithmIdentifier ::= AlgorithmIdentifier{COMPOSITE-KEY-ALGORITHM, {CompositeAlgorithmSet}} 1176 CompositeAlgorithmSet COMPOSITE-KEY-ALGORITHM ::= { 1177 CompositeAlgorithms, ... 1178 } 1180 -- 1181 -- Public Key 1182 -- 1184 pk-Composite PUBLIC-KEY ::= { 1185 IDENTIFIER id-composite-key 1186 KEY CompositePublicKey 1187 PARAMS TYPE CompositeAlgorithmIdentifier ARE optional 1188 PRIVATE-KEY CompositePrivateKey 1189 } 1191 CompositePublicKey ::= SEQUENCE SIZE (2..MAX) OF SubjectPublicKeyInfo 1193 CompositePublicKeyOs ::= OCTET STRING (CONTAINING CompositePublicKey ENCODED BY der) 1195 CompositePublicKeyBs ::= BIT STRING (CONTAINING CompositePublicKey ENCODED BY der) 1197 CompositePrivateKey ::= SEQUENCE SIZE (2..MAX) OF OneAsymmetricKey 1199 -- pk-explicitComposite - Composite public key information object 1201 pk-explicitComposite{OBJECT IDENTIFIER:id, PUBLIC-KEY:firstPublicKey, 1202 FirstPublicKeyType, PUBLIC-KEY:secondPublicKey, SecondPublicKeyType} 1203 PUBLIC-KEY ::= { 1204 IDENTIFIER id 1205 KEY ExplicitCompositePublicKey{firstPublicKey, FirstPublicKeyType, 1206 secondPublicKey, SecondPublicKeyType} 1207 PARAMS ARE absent 1208 } 1210 -- The following ASN.1 object class then automatically generates the 1211 -- public key structure from the types defined in pk-explicitComposite. 1213 -- ExplicitCompositePublicKey - The data structure for a composite 1214 -- public key sec-composite-pub-keys and SecondPublicKeyType are needed 1215 -- because PUBLIC-KEY contains a set of public key types, not a single 1216 -- type. 1217 -- TODO The parameters should be optional only if they are marked 1218 -- optional in the PUBLIC-KEY 1220 ExplicitCompositePublicKey{PUBLIC-KEY:firstPublicKey, FirstPublicKeyType, 1221 PUBLIC-KEY:secondPublicKey, SecondPublicKeyType} ::= SEQUENCE { 1222 firstPublicKey SEQUENCE { 1223 params firstPublicKey.&Params OPTIONAL, 1224 publicKey FirstPublicKeyType 1225 }, 1226 secondPublicKey SEQUENCE { 1227 params secondPublicKey.&Params OPTIONAL, 1228 publicKey SecondPublicKeyType 1229 } 1230 } 1231 END 1233 1235 Appendix D. Intellectual Property Considerations 1237 The following IPR Disclosure relates to this draft: 1239 https://datatracker.ietf.org/ipr/3588/ 1241 Appendix E. Contributors and Acknowledgements 1243 This document incorporates contributions and comments from a large 1244 group of experts. The Editors would especially like to acknowledge 1245 the expertise and tireless dedication of the following people, who 1246 attended many long meetings and generated millions of bytes of 1247 electronic mail and VOIP traffic over the past year in pursuit of 1248 this document: 1250 John Gray (Entrust), Serge Mister (Entrust), Scott Fluhrer (Cisco 1251 Systems), Panos Kampanakis (Cisco Systems), Daniel Van Geest (ISARA), 1252 Tim Hollebeek (Digicert), Klaus-Dieter Wirth (D-Trust), and Francois 1253 Rousseau. 1255 We are grateful to all, including any contributors who may have been 1256 inadvertently omitted from this list. 1258 This document borrows text from similar documents, including those 1259 referenced below. Thanks go to the authors of those documents. 1260 "Copying always makes things easier and less error prone" - 1261 [RFC8411]. 1263 E.1. Making contributions 1265 Additional contributions to this draft are welcome. Please see the 1266 working copy of this draft at, as well as open issues at: 1268 https://github.com/EntrustCorporation/draft-ounsworth-pq-composite- 1269 keys 1271 Authors' Addresses 1273 Mike Ounsworth 1274 Entrust Limited 1275 2500 Solandt Road -- Suite 100 1276 Ottawa, Ontario K2K 3G5 1277 Canada 1278 Email: mike.ounsworth@entrust.com 1279 Massimiliano Pala 1280 CableLabs 1281 Email: director@openca.org 1283 Jan Klaussner 1284 D-Trust GmbH 1285 Kommandantenstr. 15 1286 10969 Berlin 1287 Germany 1288 Email: jan.klaussner@d-trust.net