idnits 2.17.1 draft-ounsworth-pq-composite-sigs-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 04, 2019) is 1751 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 768, but not defined == Unused Reference: 'RFC1421' is defined on line 867, but no explicit reference was found in the text == Unused Reference: 'RFC4648' is defined on line 883, but no explicit reference was found in the text == Unused Reference: 'I-D.pala-composite-crypto' is defined on line 911, but no explicit reference was found in the text == Unused Reference: 'I-D.truskovsky-lamps-pq-hybrid-x509' is defined on line 915, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1421 == Outdated reference: A later version (-02) exists of draft-truskovsky-lamps-pq-hybrid-x509-01 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS M. Ounsworth (Editor) 3 Internet-Draft Entrust Datacard 4 Intended status: Standards Track M. Pala 5 Expires: January 5, 2020 CableLabs 6 July 04, 2019 8 Composite Keys and Signatures For Use In Internet PKI 9 draft-ounsworth-pq-composite-sigs-01 11 Abstract 13 With the widespread adoption of post-quantum cryptography will come 14 the need for an entity to possess multiple public keys on different 15 cryptographic algorithms. Since the trustworthiness of individual 16 post-quantum algorithms is at question, a multi-key cryptographic 17 operation will need to be performed in such a way that breaking it 18 requires breaking each of the component algorithms individually. 19 This requires defining new structures for holding composite public 20 keys and composite signature data. 22 This document defines the structures CompositePublicKey, 23 CompositeSignatureValue, and CompositeParams, which are sequences of 24 the respective structure for each component algorithm. This document 25 also defines algorithms for generating and verifying composite 26 signatures. This document makes no assumptions about what the 27 component algorithms are, provided that their algorithm identifiers 28 and signature generation and verification algorithms are defined. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 5, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Composite Structures . . . . . . . . . . . . . . . . . . . . 5 67 2.1. Algorithm Identifier . . . . . . . . . . . . . . . . . . 5 68 2.2. Composite Keys . . . . . . . . . . . . . . . . . . . . . 6 69 2.2.1. Key Usage Bits . . . . . . . . . . . . . . . . . . . 6 70 2.3. Composite Public Key . . . . . . . . . . . . . . . . . . 7 71 2.4. Composite Private Key . . . . . . . . . . . . . . . . . . 8 72 2.5. Composite Signature . . . . . . . . . . . . . . . . . . . 9 73 2.6. Encoding Rules . . . . . . . . . . . . . . . . . . . . . 9 74 3. Composite Signature Algorithm . . . . . . . . . . . . . . . . 10 75 3.1. Composite Signature Generation . . . . . . . . . . . . . 10 76 3.2. Composite Signature Verification . . . . . . . . . . . . 12 77 4. In Practice . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 4.1. PEM Storage of Composite Private Keys . . . . . . . . . . 14 79 4.2. Asymmetric Key Packages (CMS) . . . . . . . . . . . . . . 15 80 4.3. Cryptographic protocols . . . . . . . . . . . . . . . . . 15 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 83 6.1. Policy for Deprecated and Acceptable Algorithms . . . . . 16 84 6.2. Protection of Private Keys . . . . . . . . . . . . . . . 17 85 6.3. Checking for Compromised Key Reuse . . . . . . . . . . . 17 86 6.4. Composite Encryption and KEMs . . . . . . . . . . . . . . 17 87 7. Appendices . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 7.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 17 89 7.2. Intellectual Property Considerations . . . . . . . . . . 19 90 8. Contributors and Acknowledgements . . . . . . . . . . . . . . 19 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 93 9.2. Informative References . . . . . . . . . . . . . . . . . 21 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 96 1. Introduction 98 During the transition to post-quantum cryptography, there will be 99 uncertainty as to the strength of cryptographic algorithms; we will 100 no longer fully trust traditional cryptography such as RSA, Diffie- 101 Hellman, DSA and their elliptic curve variants, but we will also not 102 fully trust their post-quantum replacements until they have had 103 sufficient scrutiny. Unlike previous cryptographic algorithm 104 migrations, the choice of when to migrate and which algorithms to 105 migrate to, is not so clear. Even after the migration period, it may 106 be advantageous for an entity's cryptographic identity to be composed 107 of multiple public-key algorithms. 109 The deployment of composite public keys and composite signatures 110 using post-quantum algorithms will face two challenges 112 o Algorithm strength uncertainty: During the transition period, some 113 post-quantum signature and encryption algorithms will not be fully 114 trusted, while also the trust in legacy public key algorithms will 115 also start to erode. A relying party may learn some time after 116 deployment that a public key algorithm has become untrustworthy, 117 but in the interim, they may not know which algorithm an adversary 118 has compromised. 120 o Backwards compatibility: During the transition period, post- 121 quantum algorithms will not be supported by all clients. 123 This document provides a mechanism to address algorithm strength 124 uncertainty by providing formats for encoding multiple public keys 125 and multiple signature values into existing public key and signature 126 fields, as well as an algorithm for validating a composite signature. 127 The issue of backwards compatibility is left open to be addressed in 128 separate draft(s). 130 This document is intended for general applicability anywhere that 131 public key structures or digital signatures are used within PKIX 132 structures. 134 EDNOTE: While the scope of this document is restricted to signatures, 135 we note that the same "CompositePublicKey" structure is equally 136 applicable to asymmetric encryption keys. Though a word of warning 137 that the corresponding "encrypt / decrypt with a composite public 138 key" logic is somewhat less obvious; a naive implementer might be 139 tempted to follow the same pattern as below and encrypt the message 140 with each public key separately and then concatenate the ciphertexts, 141 which is wrong, they need to be nested. Specifying the correct 142 implementation of such an encryption scheme is out of scope for this 143 document, but would be good work for someone in the standards 144 community to pick up. 146 1.1. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in BCP 151 14 [RFC2119] [RFC8174] when, and only when, they appear in all 152 capitals, as shown here. 154 The following terms are used in this document: 156 ALGORITHM: 157 An information object class for identifying the type of cryptographic 158 operation to be performed. This document is primarily concerned with 159 algorithms for producing digital signatures, though the public key 160 structure could just as easily hold encryption keys. 162 BER: 163 Basic Encoding Rules (BER) as defined in [X.690]. 165 COMPONENT ALGORITHM: 166 A single basic algorithm which is contained within a composite 167 algorithm. 169 COMPOSITE ALGORITHM: 170 An algorithm which is a sequence of one or more basic algorithm, as 171 defined in Section 2. 173 DER: 174 Distinguished Encoding Rules as defined in [X.690]. 176 PUBLIC / PRIVATE KEY: 177 The public and private portion of an asymmetric cryptographic key, 178 making no assumptions about which algorithm. 180 PRIMITIVE PUBLIC KEY / SIGNATURE: 181 A public key or signature object of a non-composite algorithm type. 183 SIGNATURE: 184 A digital cryptographic signature, making no assumptions about which 185 algorithm. 187 2. Composite Structures 189 In order for public keys and signatures to be composed of multiple 190 algorithms, we define encodings consisting of a sequence of public 191 key and signature primitives (aka "component algorithms") such that 192 these structures can be used an a drop-in compatible way with 193 existing public key or signature fields such as those found in 194 PKCS#10 [RFC2986], CMP [RFC4210], X.509 [RFC5280], CMS [RFC5652]. 196 This section defines the following structures: 198 o The id-alg-composite is an OID identifying a composite public key 199 or signature object. 201 o The CompositePublicKey carries all the public keys associated with 202 an identity within a single public key structure. 204 o The CompositePrivateKey carries all the private keys associated 205 with an identity within a single private key structure. 207 o The CompositeSignatureValue, carries a sequence of signatures that 208 are generated by a CompositePrivateKey, and can be verified with 209 the corresponding compositePublicKey. 211 EDNOTE: the choice to define composite algorithm parameters as a 212 sequence inside the existing fields avoids the exponential 213 proliferation of OIDs that are needed for each pairwise combination 214 of signature algorithms in other schemes for achieving multi-key 215 certificates. This scheme also naturally extends from 2-keypair to 216 n-keypair keys and certificates. 218 2.1. Algorithm Identifier 220 The same algorithm identifier is used for identifying a public key, a 221 private key, and a signature. Additional encoding information is 222 provided below for each of these objects. 224 id-alg-composite OBJECT IDENTIFIER ::= { 225 iso(1) identified-organization(3) dod(6) internet(1) private(4) 226 enterprise(1) OpenCA(18227) Algorithms(2) id-alg-composite(1) } 228 EDNOTE: this is a temporary OID for the purposes of prototyping. We 229 are requesting IANA to assign a permanent OID, see Section 5. 231 2.2. Composite Keys 233 A composite key is a single key object that performs an atomic 234 signature or verification operation, using its encapsulated sequence 235 of component keys. 237 The ASN.1 algorithm object for composite public and private keys is: 239 pk-Composite PUBLIC-KEY ::= { 240 IDENTIFIER id-alg-composite 241 KEY CompositePublicKey 242 PARAMS ARE absent 243 CERT-KEY-USAGE 244 { digitalSignature, nonRepudiation, keyCertSign, cRLSign } 245 PRIVATE-KEY CompositePrivateKey 246 } 248 EDNOTE1: the authors are currently unsure whether the params should 249 be absent (ie this structure simply says "I am a composite 250 algorithm"), or used to duplicate some amount of information about 251 what the component algoritms are. See Section 2.3 for a longer 252 ENDOTE on this. 254 EDNOTE2: In order to reduce complexity, we are intentionally limiting 255 the scope of this draft to signature-type CERT-KEY-USAGEs, but we 256 note that it would be trivial to extend it to encryption-type keys. 258 2.2.1. Key Usage Bits 260 The intended application for the key is indicated in the keyUsage 261 certificate extension and defined in the CERT-KEY-USAGE field of pk- 262 Composite. 264 If the keyUsage extension is present in an end-entity certificate 265 that indicates id-alg-composite, then the keyUsage extension MUST 266 contain one or both of the following values: 268 nonRepudiation; and 269 digitalSignature. 271 If the keyUsage extension is present in a certification authority 272 certificate that indicates id-alg-composite, then the keyUsage 273 extension MUST contain one or more of the following values: 275 nonRepudiation; 276 digitalSignature; 277 keyCertSign; and 278 cRLSign. 280 As this draft only covers composite signatures, the key usage bits 281 specified here apply to all component keys within a composite key. 283 2.3. Composite Public Key 285 Composite public key data is represented by the following structure: 287 CompositePublicKey ::= SEQUENCE SIZE (1..MAX) OF SubjectPublicKeyInfo 289 The corresponding AlgorithmIdentifier for a composite public key MUST 290 use the id-alg-composite object identifier, defined in Section 2.1, 291 and the parameters field MUST be absent. 293 A composite public key MUST contain at least one component public 294 key. 296 A CompositePublicKey MUST NOT contain a component public key which 297 itself describes a composite key; ie recursive CompositePublicKeys 298 are not allowed. 300 Each element of a CompositePublicKey is a SubjectPublicKeyInfo object 301 one of the component public keys. When the CompositePublicKey must 302 be provided in octet string or bit string format, the data structure 303 is encoded as specified in Section 2.6. 305 ~~~ Begin EDNOTE ~~~ 307 EDNOTE: there has been a fair amout of discussion among the authors 308 about whether the component public key should contain a full 309 SubjectPublicKeyInfo for each component algorithm, or whether the 310 {algID, and algParams} should be move to the params of the PUBLIC-KEY 311 or OID, and only the BIT STRINGs of the component public key values 312 contained in the CompositePublicKey. 314 Using a wonky, simplified notation, the alternatives considered were: 316 Current composite: 317 CompositeAlg: { 318 algorithm={id-alg-composite, none} 319 subjectPublicKey=SEQ SPKI[{{algID1, algParams1}, value1}, 320 SPKI{{algID2, algParams2}, value2}, ..] 321 } 323 Alternative 1: 324 CompositeAlg: { 325 algorithm={id-alg-composite, {{algID1, algParams1}, 326 {algID2, algParams2}, ..} 327 subjectPublicKey=SEQ BIT STRING[value1, value2, ..] 328 } 330 Alternative 2: 331 CompositeAlg: { 332 algorithm={id-alg-composite, {algID1, algID2, ..}} 333 subjectPublicKey=SEQ SPKI[{{algID1, algParams1}, value1}, 334 {{algID2, algParams2}, value2}, ..] 335 } 337 The authors have decided, for the time being, to use the current 338 approach since it A) promotes ease of modifying existing software 339 whose APIs require SubjectPublicKeyInfos to be passed, and B) avoids 340 bloating wire protocols with duplicated information. 342 We note that the chosen approach means that the algorithm field 343 essentially carries no useful information about the key it's 344 describing. Analysis is required to see if there are any 345 circumstances in which this opens up cryptographic attacks, such as 346 algorithm substitution or stripping attacks. ~~~ End EDNOTE ~~~ 348 2.4. Composite Private Key 350 The composite private key data is represented by the following 351 structure: 353 CompositePrivateKey ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey 355 Each element is a OneAsymmetricKey [RFC5958] object for a component 356 private key. 358 The corresponding AlgorithmIdentifier for a composite private key 359 MUST use the id-alg-composite object identifier, and the parameters 360 field MUST be absent. 362 A CompositePrivateKey MUST contain at least one component private 363 key, and they MUST be in the same order as in the corresponding 364 CompositePublicKey. 366 2.5. Composite Signature 368 The ASN.1 algorithm object for a composite signature is: 370 sa-CompositeSignature SIGNATURE-ALGORITHM ::= { 371 IDENTIFIER id-alg-composite 372 VALUE CompositeSignatureValue 373 PARAMS TYPE CompositeParams ARE required 374 PUBLIC-KEYS { pk-Composite } 375 SMIME-CAPS { IDENTIFIED BY id-alg-composite } } 376 } 378 The id-alg-composite object identifier MUST be used to identify when 379 a signature has been created by a composite private key, and te 380 following algorithm parameters MUST be included: 382 CompositeParams ::= SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier 384 The signature's CompositeParams sequence MUST contain the same 385 component algorithms listed in the same order as in the associated 386 CompositePrivateKey and CompositePublicKey. 388 The output of the composite signature algorithm is the DER encoding 389 of the following structure: 391 CompositeSignatureValue ::= SEQUENCE SIZE (1..MAX) OF BIT STRING 393 Where each BIT STRING within the SEQUENCE is a signature value 394 produced by one of the component keys. It MUST contain MUST contain 395 one signature value produced by each componet key, and in the same 396 order as in the associated "CompositeParams", CompositePublicKey, and 397 CompositePrivateKey objects. 399 The choice of "SEQUENCE OF BIT STRING", rather than for example a 400 single BIT STRING containing the concatenated signature values, is to 401 gracefully handle variable-length signature values by taking 402 advantage of ASN.1's build-in length fields. 404 2.6. Encoding Rules 406 Many protocol specifications will require that the composite public 407 key, composite private key, and composite signature data structures 408 be represented by an octet string or bit string. 410 When an octet string is required, the DER encoding of the composite 411 data structure SHALL be used directly. 413 When a bit string is required, the octets of the DER encoded 414 composite data structure SHALL be used as the bits of the bit string, 415 with the most significant bit of the first octet becoming the first 416 bit, and so on, ending with the least significant bit of the last 417 octet becoming the last bit of the bit string. 419 In the interests of simplicity and avoiding compatibility issues, 420 implementations that parse these structures MAY accept both BER and 421 DER. 423 3. Composite Signature Algorithm 425 This section specifies the algorithms for generating and verifying 426 composite signatures. 428 This algorithm addresses algorithm strength uncertainty by providing 429 the verifier with parallel signatures from all the component 430 signature algorithms; thus breaking the composite signature would 431 require breaking all of the component signatures. 433 3.1. Composite Signature Generation 435 Generation of a composite signature involves applying each component 436 algorithm's signature routine to the input message according to its 437 specification, and then placing each component signature value into 438 the "CompositeSignatureValue" structure defined in Section 2.5. 440 The following algorithm is used to generate composite signature 441 values. 443 Input: 444 K1, K2, .., Kn Private keys for the n component signature 445 algorithms 446 M Message to be signed, an octet string 448 Output: 449 S The signature, a CompositeSignatureValue 451 Signature Generation Procedure: 452 1. Generate the n component signatures independently, 453 according to their algorithm specifications. 455 for i := 1 to n 456 Si := Sign( Ki, M ) 458 2. Encode each component signature S1, S2, .., Sn into a BIT STRING 459 according to its algorithm specification. 461 S ::= Sequence { S1, S2, .., Sn } 463 3. Output S 465 Since recursive composite public keys are disallowed in Section 2.3, 466 no component signature may itself be composite; ie the signature 467 generation routine MUST fail if one of the private keys K1, K2, .., 468 Kn is composite with the OID id-alg-composite. 470 A composite signature MUST produce and include in the output a 471 signature value for every component key in the corresponding 472 CompositePublicKey. 474 EDNOTE1: With NIST's position that they will standardize use-case- 475 specific algorithm suites, the authors are aware of potential use- 476 cases where a PKI entity may want to have many public keys, but only 477 sign with a subset for each signature. At the present time, this 478 draft does not allow for this because the algorithm for verifying 479 "subset-signatures" in a way that is secure against algorithm 480 stripping attacks would be very complex and prone to implementation 481 errors (currently, the verifier can detect omitted signatures even if 482 it does not recognize all the algorithm OIDs because the count will 483 be wrong. In a subset-signature algorithm, additional mechanisms 484 would be needed to specify for each component key, whether it is 485 meant to produce a signature or not). The draft-compliant way to 486 achieve a "subset-signature" behaviour would be for each PKI entity 487 to have multiple public keys (and certificates) with overlapping 488 subsets of their component keys. We welcome public opinions on 489 whether this is sufficient, or whether this draft should specify a 490 subset-signature algorithm. 492 EDNOTE2: The authors are also aware of a potential use-case of 493 combining signature and KEM keys inside a single public key / 494 certificate. This would give us back the "dual-usage key" property 495 that was so appealing about RSA. At the present time, this draft 496 does not allow for this because, again, the algorithm for verifying 497 "subset-signatures" in a secure way would be very complex. We also 498 welcome public opinions on this. 500 3.2. Composite Signature Verification 502 Verification of a composite signature involves applying each 503 component algorithm's verification routine according to its 504 specification, and then outputting "Valid signature" (true) if a 505 sufficient number of component algorithms were valid, and "Invalid 506 signature" (false) otherwise. 508 In order to future-proof implementations of verifiers against 509 evolutions in cryptographic algorithms and attacks against them, 510 implementations SHOULD include a field-updatable policy mechanism for 511 determining which and/or how many component algorithms must be valid 512 in order for the composite signature as a whole to be considered 513 valid. This section assumes the existence of such a policy 514 mechanism, denoted as "checkPolicy(A1, A2, ..., An)" in the algorithm 515 below. The implementation of such a policy mechanism is largely the 516 responsibility of the verifier / client and therefore is out of scope 517 for this document, but at a minimum, one component signature MUST be 518 recognized and validated for the composite signature to be considered 519 valid. 521 Modifications of the provided verification algorithm are permitted, 522 so long as they are strengthening, and not weakening, this algorithm. 523 In other words, any modified versions of this algorithm MUST return 524 "Invalid signature" whenever the sample algorithm does, with the one 525 exception noted below. 527 Input: 528 P Signer's composite public key 529 M Message whose signature is to be verified, an octet string 530 S Composite Signature to be verified 531 A Composite Algorithm identifier 533 Output: 534 Validity "Valid signature" (true) if the composite signature 535 is valid, "Invalid signature" (false) otherwise. 537 Signature Verification Procedure:: 538 1. Parse P, S, A into the component public keys, signatures, 539 and algorithm identifiers 541 P1, P2, .., Pn := Desequence( P ) 542 S1, S2, .., Sn := Desequence( S ) 543 A1, A2, .., An := Desequence( A ) 545 If Error during Desequencing, or the three sequences have 546 different numbers of elements, then output "Invalid signature" 547 and stop. 549 2. Check client policy to see whether A1, A2, .., An constitutes an 550 acceptable combination of algorithms. 552 if not checkPolicy(A1, A2, .., An), then 553 output "Invalid signature" 555 3. Check each component signature individually, according to its 556 algorithm specification. 557 If any fail, then the entire signature validation fails. 559 for i := 1 to n 560 if not verify( Pi, M, Si ), then 561 output "Invalid signature" 563 if all succeeded, then 564 output "Valid signature" 566 Since recursive composite public keys are disallowed in Section 2.3, 567 no component signature may be composite; ie the signature 568 verification procedure MUST fail if any of the public keys P1, P2, 569 .., Pn or algorithm identifiers A1, A2, .., An are composite with the 570 OID id-alg-composite. 572 Exception to this algorithm: There will be circumstances in which the 573 verifier does not have cryptographic libraries for all of the 574 provided component algorithms, or where the performance gains from 575 omitting algorithms justifies the loss of security. In these cases, 576 an acceptable modification to this algorithm is to produce in step 2 577 one or more subsets of the algorithms "A1, A2, ..., An" which 578 constitute acceptable combinations, outputting "Invalid signature" if 579 an acceptable subset can not be found, and then in step 3 only 580 perform verification of the necessary component algorithms. 582 Implementations SHOULD verify all recognized and supported 583 algorithms, and output "Invalid signature" if the verification of any 584 component signature fails, but MAY choose to only verify a subset of 585 the algorithms for the reasons stated above. 587 4. In Practice 589 This section addresses practical issues of how this draft affects 590 other protocols and standards. 592 ~~~ BEGIN EDNOTE ~~~ 594 EDNOTE: Possible topics to address: 596 o The size of these certs and cert chains. 598 o In particular, implications for (large) composite keys / 599 signatures / certs on the handshake stages of TLS and IKEv2. 601 o If a cert in the chain is a composite cert then does the whole 602 chain need to be of composite Certs? 604 o We could also explain that the root CA cert does not have to be of 605 the same algorithms. The root cert SHOULD NOT be transferred in 606 the authentication exchange to save transport overhead and thus it 607 can be different than the intermediate and leaf certs. 609 o We could talk about overhead (size and processing). 611 o We could also discuss backwards compatibility. 613 o We could include a subsection about implementation considerations. 615 ~~~ END EDNOTE ~~~ 617 4.1. PEM Storage of Composite Private Keys 619 CompositePrivateKeys can be encoded to the PEM format by placing a 620 CompositePrivateKey into the privateKey field of a PrivateKeyInfo or 621 OneAsymmetricKey object, and then applying the PEM encoding rules as 622 defined in [RFC7468] section 10 and 11 for plaintext and encrypted 623 private keys, respectively. 625 EDNOTE: Do we really need this? Isn't it obvious? 627 4.2. Asymmetric Key Packages (CMS) 629 The Cryptographic Message Syntax (CMS), as defined in [RFC5652], can 630 be used to digitally sign, digest, authenticate, or encrypt the 631 asymmetric key format content type. 633 When encoding composite private keys, the privateKeyAlgorithm in the 634 OneAsymmetricKey SHALL be set to id-alg-composite. 636 The parameters of the privateKeyAlgorithm SHALL be a sequence of 637 AlgorithmIdentifier objects, each of which are encoded according to 638 the rules defined for each of the different keys in the composite 639 private key. 641 The value of the privateKey field in the OneAsymmetricKey SHALL be 642 set to the DER encoding of the SEQUENCE of private key values that 643 make up the composite key. The number and order of elements in the 644 sequence SHALL be the same as identified in the sequence of 645 parameters in the privateKeyAlgorithm. 647 The value of the publicKey (if present) SHALL be set to the DER 648 encoding of the corresponding CompositePublicKey. If this field is 649 present, the number and order of component keys MUST be the same as 650 identified in the sequence of parameters in the privateKeyAlgorithm. 652 The value of the attributes is encoded as usual. 654 4.3. Cryptographic protocols 656 This section talks about how protocols like (D)TLS and IKEv2 are 657 affected by this specifications. It will not attempt to solve all 658 these problems, but it will explain the rationale, how things will 659 work and what open problems need to be solved. Obvious issues that 660 need to be discussed. 662 o How does the protocol declare support for composite signatures? 663 TLS has hooks for declaring support for specific signature 664 algorithms, however it would need to be extended, because the 665 client would need to declare support for both the composite 666 infrastructure, as well as for the various component signature 667 algorithms. 669 o How does the protocol use the multiple keys. The obvious way 670 would be to have the server sign using its composite public key; 671 is this sufficient. 673 o Overhead; including certificate size, signature processing time, 674 and size of the signature. 676 o How to deal with crypto protocols that use public key encryption 677 algorithms; this document only lists how to work with signature 678 algorithms. Encoding composite public keys is straightforward; 679 encoding composite ciphertexts is less so - we decided to put that 680 off to another draft. 682 5. IANA Considerations 684 The ASN.1 module OID is TBD. The id-alg-composite OID is to be 685 assigned by IANA. The authors suggest to use the id-pkix arc for 686 this usage: 688 id-alg-composite OBJECT IDENTIFIER ::= { 689 iso(1) identified-organization(3) dod(6) internet(1) security(5) 690 mechanisms(5) pkix(7) algorithms(6) composite(??) } 692 6. Security Considerations 694 6.1. Policy for Deprecated and Acceptable Algorithms 696 Traditionally, a public key, certificate, or signature contains a 697 single cryptographic algorithm. If and when an algorithm becomes 698 deprecated (for example, RSA-512, or SHA1), it is obvious that 699 structures using that algorithm are implicitly revoked. 701 In the composite model this is less obvious since a single public 702 key, certificate, or signature may contain a mixture of deprecated 703 and non-depricated algorithms. Moreover, implementers may decide 704 that certain cryptographic algorithms have complementary security 705 properties and are acceptable in combination even though neither 706 algoritm is acceptable by itself. 708 In Section 3.2, we specify that the signature verification routine 709 must include a step to check that the combination of algorithms is 710 acceptable under local policy: 712 2. Check policy to see whether A1, A2, ..., An constitutes a valid 713 combination of algorithms. 714 if not checkPolicy(A1, A2, ..., An), then 715 output "Invalid signature" 717 While intentionally not specified in this document, implementors 718 should put careful thought into implementing a meaningfull policy 719 mechinism within the context of their signature verification engines. 721 6.2. Protection of Private Keys 723 This structures described in this document do not protect the private 724 keys information in any way unless combined with a security protocol 725 or encryption properties of the objects (if any) where the 726 CompositePrivateKey is used (see next Section). 728 Protection of the private key information is vital to public key 729 cryptography. The consequences of disclosure depend on the purpose 730 of the private key. If a private key is used for signature, then the 731 disclosure allows unauthorized signing. If a private key is used for 732 key management, then disclosure allows unauthorized parties to access 733 the managed keying material. The encryption algorithm used in the 734 encryption process must be as 'strong' as the key it is protecting. 736 6.3. Checking for Compromised Key Reuse 738 CA implementations need to be careful when checking for compromised 739 key reuse, for example as required by WebTrust regulations; when 740 checking for compromised keys, you MUST unpack the CompositePublicKey 741 structure and compare individual component keys. 743 6.4. Composite Encryption and KEMs 745 This document deals only with signature keys. While the 746 CompositePublicKey and CompositePrivateKey structures could equally 747 be used to hold encryption or KEM keys, the authors warn that there 748 are non-trivial design decisions to be made when constructing a 749 multi-key public key encryption or KEM algorithm. Some of these 750 design and implementation decisions, if done incorrectly will result 751 in a catastrophic loss of security. We leave it to the community to 752 standardize analogous composite encryption and KEM schemes. 754 7. Appendices 756 7.1. ASN.1 Module 758 760 Composite-Signatures-2019 761 { TBD } 763 DEFINITIONS IMPLICIT TAGS ::= BEGIN 764 EXPORTS ALL; 766 IMPORTS 767 PUBLIC-KEY, SIGNATURE-ALGORITHM 768 FROM AlgorithmInformation-2009 -- RFC 5912 [X509ASN1] 769 { iso(1) identified-organization(3) dod(6) internet(1) 770 security(5) mechanisms(5) pkix(7) id-mod(0) 771 id-mod-algorithmInformation-02(58) } 773 SubjectPublicKeyInfo 774 FROM PKIX1Explicit-2009 775 { iso(1) identified-organization(3) dod(6) internet(1) 776 security(5) mechanisms(5) pkix(7) id-mod(0) 777 id-mod-pkix1-explicit-02(51) } 779 OneAsymmetricKey 780 FROM AsymmetricKeyPackageModuleV1 781 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 782 pkcs-9(9) smime(16) modules(0) 783 id-mod-asymmetricKeyPkgV1(50) } ; 785 -- 786 -- Object Identifiers 787 -- 789 id-alg-composite OBJECT IDENTIFIER ::= { TBD } 791 -- 792 -- Public Key 793 -- 795 pk-Composite PUBLIC-KEY ::= { 796 IDENTIFIER id-alg-composite 797 KEY CompositePublicKey 798 PARAMS ARE absent 799 CERT-KEY-USAGE 800 { digitalSignature, nonRepudiation, keyCertSign, cRLSign } 801 PRIVATE-KEY CompositePrivateKey 802 } 804 CompositePublicKey ::= SEQUENCE SIZE (1..MAX) OF SubjectPublicKeyInfo 806 CompositePrivateKey ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey 808 -- 809 -- Signature Algorithm 810 -- 811 sa-CompositeSignature SIGNATURE-ALGORITHM ::= { 812 IDENTIFIER id-alg-composite 813 VALUE CompositeSignatureValue 814 PARAMS TYPE CompositeParams ARE required 815 PUBLIC-KEYS { pk-Composite } 816 SMIME-CAPS { IDENTIFIED BY id-alg-composite } } 818 CompositeParams ::= SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier 820 CompositeSignatureValue ::= SEQUENCE SIZE (1..MAX) OF BIT STRING 822 END 824 826 7.2. Intellectual Property Considerations 828 The authors are aware that Massimiliano Pala and CableLabs have 829 applied for Intellectual Property Rights around composite key, 830 signatures, and certificates. We have a verbal agreement with Max 831 that this IP will be made freely available to the community. 833 As of this version of the draft, the authors have reviewed and 834 provided feedback on the March 24, 2019 version of the IPR 835 disclosure, available at https://datatracker.ietf.org/ipr/3481/, and 836 are awaiting the posting of an updated version that covers this 837 draft. 839 EDNOTE: remove this section once the IPR disclosure is posted and 840 tagged against this draft. 842 8. Contributors and Acknowledgements 844 This document incorporates contributions and comments from a large 845 group of experts. The Editors would especially like to acknowledge 846 the expertise and tireless dedication of the following people, who 847 attended many long meetings and generated millions of bytes of 848 electronic mail and VOIP traffic over the past year in pursuit of 849 this document: 851 John Gray (Entrust Datacard), Serge Mister (Entrust Datacard), Scott 852 Fluhrer (Cisco Systems), Panos Kampanakis (Cisco Systems), Daniel Van 853 Geest (ISARA), and Tim Hollebeek (Digicert). 855 We are grateful to all, including any contributors who may have been 856 inadvertently omitted from this list. 858 This document borrows text from similar documents, including those 859 referenced below. Thanks go to the authors of those documents. 860 "Copying always makes things easier and less error prone" - 861 [RFC8411]. 863 9. References 865 9.1. Normative References 867 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 868 Mail: Part I: Message Encryption and Authentication 869 Procedures", RFC 1421, DOI 10.17487/RFC1421, February 870 1993, . 872 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 873 Requirement Levels", BCP 14, RFC 2119, 874 DOI 10.17487/RFC2119, March 1997, 875 . 877 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 878 "Internet X.509 Public Key Infrastructure Certificate 879 Management Protocol (CMP)", RFC 4210, 880 DOI 10.17487/RFC4210, September 2005, 881 . 883 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 884 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 885 . 887 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 888 Housley, R., and W. Polk, "Internet X.509 Public Key 889 Infrastructure Certificate and Certificate Revocation List 890 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 891 . 893 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 894 RFC 5652, DOI 10.17487/RFC5652, September 2009, 895 . 897 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 898 DOI 10.17487/RFC5958, August 2010, 899 . 901 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 902 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 903 April 2015, . 905 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 906 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 907 May 2017, . 909 9.2. Informative References 911 [I-D.pala-composite-crypto] 912 Pala, M., "Composite Public Keys and Signatures", draft- 913 pala-composite-crypto-03 (work in progress), March 2019. 915 [I-D.truskovsky-lamps-pq-hybrid-x509] 916 Truskovsky, A., Geest, D., Fluhrer, S., Kampanakis, P., 917 Ounsworth, M., and S. Mister, "Multiple Public-Key 918 Algorithm X.509 Certificates", draft-truskovsky-lamps-pq- 919 hybrid-x509-01 (work in progress), August 2018. 921 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 922 Request Syntax Specification Version 1.7", RFC 2986, 923 DOI 10.17487/RFC2986, November 2000, 924 . 926 [RFC8411] Schaad, J. and R. Andrews, "IANA Registration for the 927 Cryptographic Algorithm Object Identifier Range", 928 RFC 8411, DOI 10.17487/RFC8411, August 2018, 929 . 931 Authors' Addresses 933 Mike Ounsworth 934 Entrust Datacard Limited 935 1000 Innovation Drive 936 Ottawa, Ontario K2K 1E3 937 Canada 939 Email: mike.ounsworth@entrustdatacard.com 941 Massimiliano Pala 942 CableLabs 944 Email: director@openca.org