idnits 2.17.1 draft-ounsworth-pq-composite-sigs-03.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 is 1 instance of too long lines in the document, the longest one being 6 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 (July 28, 2020) is 1368 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 658, but not defined == Unused Reference: 'RFC1421' is defined on line 748, but no explicit reference was found in the text == Unused Reference: 'RFC4648' is defined on line 769, but no explicit reference was found in the text == Unused Reference: 'I-D.pala-composite-crypto' is defined on line 807, but no explicit reference was found in the text == Unused Reference: 'I-D.truskovsky-lamps-pq-hybrid-x509' is defined on line 812, 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 8411 == Outdated reference: A later version (-03) exists of draft-pala-composite-crypto-00 == Outdated reference: A later version (-02) exists of draft-truskovsky-lamps-pq-hybrid-x509-01 Summary: 4 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 (Editor) 3 Internet-Draft Entrust Datacard 4 Intended status: Standards Track M. Pala 5 Expires: January 29, 2021 CableLabs 6 July 28, 2020 8 Composite Keys and Signatures For Use In Internet PKI 9 draft-ounsworth-pq-composite-sigs-03 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 29, 2021. 47 Copyright Notice 49 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Composite Structures . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Algorithm Identifier . . . . . . . . . . . . . . . . . . 5 68 2.2. Composite Keys . . . . . . . . . . . . . . . . . . . . . 5 69 2.2.1. Key Usage Bits . . . . . . . . . . . . . . . . . . . 6 70 2.3. Composite Public Key . . . . . . . . . . . . . . . . . . 6 71 2.4. Composite Private Key . . . . . . . . . . . . . . . . . . 7 72 2.5. Composite Signature . . . . . . . . . . . . . . . . . . . 7 73 2.6. Encoding Rules . . . . . . . . . . . . . . . . . . . . . 8 74 3. Composite Signature Algorithm . . . . . . . . . . . . . . . . 8 75 3.1. Composite Signature Generation . . . . . . . . . . . . . 8 76 3.2. Composite Signature Verification . . . . . . . . . . . . 9 77 4. In Practice . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 4.1. PEM Storage of Composite Private Keys . . . . . . . . . . 11 79 4.2. Asymmetric Key Packages (CMS) . . . . . . . . . . . . . . 11 80 4.3. Cryptographic protocols . . . . . . . . . . . . . . . . . 12 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 6.1. Policy for Deprecated and Acceptable Algorithms . . . . . 13 84 6.2. Protection of Private Keys . . . . . . . . . . . . . . . 13 85 6.3. Checking for Compromised Key Reuse . . . . . . . . . . . 14 86 6.4. Composite Encryption and KEMs . . . . . . . . . . . . . . 14 87 7. Appendices . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 7.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 14 89 7.2. Intellectual Property Considerations . . . . . . . . . . 16 90 8. Contributors and Acknowledgements . . . . . . . . . . . . . . 16 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 93 9.2. Informative References . . . . . . . . . . . . . . . . . 18 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 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 private keys and signature values into existing public key and 126 signature fields, as well as an algorithm for validating a composite 127 signature. The issue of backwards compatibility is left open to be 128 addressed in 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. While the CompositePublicKey structure defined herein is 133 equally applicable to asymmetric encryption keys, this document is 134 intentionally restricted to signatures. 136 1.1. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in BCP 141 14 [RFC2119] [RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 The following terms are used in this document: 146 ALGORITHM: An information object class for identifying the type of 147 cryptographic operation to be performed. This document is primarily 148 concerned with algorithms for producing digital signatures, though 149 the public key structure could just as easily hold encryption keys. 151 BER: Basic Encoding Rules (BER) as defined in [X.690]. 153 COMPONENT ALGORITHM: A single basic algorithm which is contained 154 within a composite algorithm. 156 COMPOSITE ALGORITHM: An algorithm which is a sequence of one or more 157 component algorithms, as defined in Section 2. 159 DER: Distinguished Encoding Rules as defined in [X.690]. 161 PUBLIC / PRIVATE KEY: The public and private portion of an asymmetric 162 cryptographic key, making no assumptions about which algorithm. 164 PRIMITIVE PUBLIC KEY / SIGNATURE: A public key or signature object of 165 a non-composite algorithm type. 167 SIGNATURE: A digital cryptographic signature, making no assumptions 168 about which algorithm. 170 2. Composite Structures 172 In order for public keys and signatures to be composed of multiple 173 algorithms, we define encodings consisting of a sequence of public 174 key and signature primitives (aka "component algorithms") such that 175 these structures can be used as a drop-in replacement for existing 176 public key or signature fields such as those found in PKCS#10 177 [RFC2986], CMP [RFC4210], X.509 [RFC5280], CMS [RFC5652]. 179 This section defines the following structures: 181 o The id-alg-composite is an OID identifying a composite public key 182 or signature object. 184 o The CompositePublicKey carries all the public keys associated with 185 an identity within a single public key structure. 187 o The CompositePrivateKey carries all the private keys associated 188 with an identity within a single private key structure. 190 o The CompositeSignatureValue, carries a sequence of signatures that 191 are generated by a CompositePrivateKey, and can be verified with 192 the corresponding CompositePublicKey. 194 EDNOTE 2: the choice to define composite algorithm parameters as a 195 sequence inside the existing fields avoids the exponential 196 proliferation of OIDs that are needed for each combination of 197 signature algorithms in other schemes for achieving multi-key 198 certificates. This scheme also naturally extends from 2-keypair to 199 n-keypair keys and certificates. 201 2.1. Algorithm Identifier 203 The same algorithm identifier is used for identifying a public key, a 204 private key, and a signature. Additional encoding information is 205 provided below for each of these objects. 207 id-alg-composite OBJECT IDENTIFIER ::= { 208 iso(1) identified-organization(3) dod(6) internet(1) private(4) 209 enterprise(1) OpenCA(18227) Algorithms(2) id-alg-composite(1) } 211 EDNOTE 3: this is a temporary OID for the purposes of prototyping. 212 We are requesting IANA to assign a permanent OID, see Section 5. 214 2.2. Composite Keys 216 A composite key is a single key object that performs an atomic 217 signature or verification operation, using its encapsulated sequence 218 of component keys. 220 The ASN.1 algorithm object for composite public and private keys is: 222 pk-Composite PUBLIC-KEY ::= { 223 IDENTIFIER id-alg-composite 224 KEY CompositePublicKey 225 PARAMS ARE absent 226 CERT-KEY-USAGE 227 { digitalSignature, nonRepudiation, keyCertSign, cRLSign } 228 PRIVATE-KEY CompositePrivateKey 229 } 231 EDNOTE 4: the authors are currently unsure whether the params should 232 be absent (ie this structure simply says "I am a composite 233 algorithm"), or used to duplicate some amount of information about 234 what the component algoritms are. See Section 2.3 for a longer 235 ENDOTE on this. 237 2.2.1. Key Usage Bits 239 The intended application for the key is indicated in the keyUsage 240 certificate extension and defined in the CERT-KEY-USAGE field of pk- 241 Composite. 243 If the keyUsage extension is present in an end-entity certificate 244 that indicates id-alg-composite, then the keyUsage extension MUST 245 contain one or both of the following values: 247 nonRepudiation; and 248 digitalSignature. 250 If the keyUsage extension is present in a certification authority 251 certificate that indicates id-alg-composite, then the keyUsage 252 extension MUST contain one or more of the following values: 254 nonRepudiation; 255 digitalSignature; 256 keyCertSign; and 257 cRLSign. 259 As this draft only covers composite signatures, the key usage bits 260 specified here apply to all component keys within a composite key. 262 2.3. Composite Public Key 264 Composite public key data is represented by the following structure: 266 CompositePublicKey ::= SEQUENCE SIZE (1..MAX) OF SubjectPublicKeyInfo 268 The corresponding AlgorithmIdentifier for a composite public key MUST 269 use the id-alg-composite object identifier, defined in Section 2.1, 270 and the parameters field MUST be absent. 272 A composite public key MUST contain at least one component public 273 key. 275 A CompositePublicKey MUST NOT contain a component public key which 276 itself describes a composite key; ie recursive CompositePublicKeys 277 are not allowed 279 Each element of a CompositePublicKey is a SubjectPublicKeyInfo object 280 one of the component public keys. When the CompositePublicKey must 281 be provided in octet string or bit string format, the data structure 282 is encoded as specified in Section 2.6. 284 2.4. Composite Private Key 286 The composite private key data is represented by the following 287 structure: 289 CompositePrivateKey ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey 291 Each element is a OneAsymmetricKey [RFC5958] object for a component 292 private key. 294 The corresponding AlgorithmIdentifier for a composite private key 295 MUST use the id-alg-composite object identifier, and the parameters 296 field MUST be absent. 298 A CompositePrivateKey MUST contain at least one component private 299 key, and they MUST be in the same order as in the corresponding 300 CompositePublicKey. 302 2.5. Composite Signature 304 The ASN.1 algorithm object for a composite signature is: 306 sa-CompositeSignature SIGNATURE-ALGORITHM ::= { 307 IDENTIFIER id-alg-composite 308 VALUE CompositeSignatureValue 309 PARAMS TYPE CompositeParams ARE required 310 PUBLIC-KEYS { pk-Composite } 311 SMIME-CAPS { IDENTIFIED BY id-alg-composite } } 312 } 314 The id-alg-composite object identifier MUST be used to identify when 315 a signature has been created by a CompositePrivateKey and following 316 algorithm parameters MUST be included: 318 CompositeParams ::= SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier 320 The signature's CompositeParams sequence MUST contain the same 321 component algorithms listed in the same order as in the associated 322 CompositePrivateKey and CompositePublicKey. 324 The output of the composite signature algorithm is the DER encoding 325 of the following structure: 327 CompositeSignatureValue ::= SEQUENCE SIZE (1..MAX) OF BIT STRING 329 Where each BIT STRING within the SEQUENCE is a signature value 330 produced by one of the component keys. It MUST contain one signature 331 value produced by each component algorithm, and in the same order as 332 in the associated CompositeParams object. 334 The choice of "SEQUENCE OF BIT STRING", rather than for example a 335 single BIT STRING containing the concatenated signature values, is to 336 gracefully handle variable-length signature values by taking 337 advantage of ASN.1's build-in length fields. 339 2.6. Encoding Rules 341 Many protocol specifications will require that the composite public 342 key, composite private key, and composite signature data structures 343 be represented by an octet string or bit string. 345 When an octet string is required, the DER encoding of the composite 346 data structure SHALL be used directly. 348 When a bit string is required, the octets of the DER encoded 349 composite data structure SHALL be used as the bits of the bit string, 350 with the most significant bit of the first octet becoming the first 351 bit, and so on, ending with the least significant bit of the last 352 octet becoming the last bit of the bit string. 354 In the interests of simplicity and avoiding compatibility issues, 355 implementations that parse these structures MAY accept both BER and 356 DER. 358 3. Composite Signature Algorithm 360 This section specifies the algorithms for generating and verifying 361 composite signatures. 363 This algorithm addresses algorithm strength uncertainty by providing 364 the verifier with parallel signatures from all the component 365 signature algorithms; thus breaking the composite signature would 366 require breaking all of the component signatures. 368 3.1. Composite Signature Generation 370 Generation of a composite signature involves applying each component 371 algorithm's signature routine to the input message according to its 372 specification, and then placing each component signature value into 373 the CompositeSignatureValue structure defined in Section 2.5. 375 The following algorithm is used to generate composite signature 376 values. 378 Input: 379 K1, K2, .., Kn Private keys for the n component signature 380 algorithms, a CompositePrivateKey 381 M Message to be signed, an octet string 383 Output: 384 S The signatures, a CompositeSignatureValue 386 Signature Generation Procedure: 387 1. Generate the n component signatures independently, 388 according to their algorithm specifications. 390 for i := 1 to n 391 Si := Sign( Ki, M ) 393 2. Encode each component signature S1, S2, .., Sn into a BIT STRING 394 according to its algorithm specification.2020-01-21g 396 S ::= Sequence { S1, S2, .., Sn } 398 3. Output S 400 Since recursive composite public keys are disallowed in Section 2.3, 401 no component signature may itself be a composite; ie the signature 402 generation routine MUST fail if one of the private keys K1, K2, .., 403 Kn is a composite with the OID id-alg-composite. 405 A composite signature MUST produce and include in the output a 406 signature value for every component key in the corresponding 407 CompositePrivateKey. While it may be tempting to allow a signer to 408 produce a signature with a subset of their keys, the complexity of 409 securely verifying such a "subset signature" is high and out of scope 410 for this document. 412 3.2. Composite Signature Verification 414 Verification of a composite signature involves applying each 415 component algorithm's verification routine according to its 416 specification. 418 In the absence of an application profile specifying otherwise, 419 compliant applications MUST output "Valid signature" (true) if and 420 only if all component signatures were successfully validated, and 421 "Invalid signature" (false) otherwise. 423 The following algorithm is used to perform this verification. 425 Input: 426 P Signer's composite public key 427 M Message whose signature is to be verified, an octet string 428 S Composite Signature to be verified 429 A Composite Algorithm identifier 431 Output: 432 Validity "Valid signature" (true) if the composite signature 433 is valid, "Invalid signature" (false) otherwise. 435 Signature Verification Procedure:: 436 1. Parse P, S, A into the component public keys, signatures, 437 and algorithm identifiers 439 P1, P2, .., Pn := Desequence( P ) 440 S1, S2, .., Sn := Desequence( S ) 441 A1, A2, .., An := Desequence( A ) 443 If Error during Desequencing, or the three sequences have 444 different numbers of elements, or any of the public keys P1, P2, .., Pn or 445 algorithm identifiers A1, A2, .., An are composite with the OID 446 id-alg-composite then output "Invalid signature" and stop. 448 2. Check each component signature individually, according to its 449 algorithm specification. 450 If any fail, then the entire signature validation fails. 452 for i := 1 to n 453 if not verify( Pi, M, Si ), then 454 output "Invalid signature" 456 if all succeeded, then 457 output "Valid signature" 459 Since recursive composite public keys are disallowed in Section 2.3, 460 no component signature may be composite; ie the signature 461 verification procedure MUST fail if any of the public keys P1, P2, 462 .., Pn or algorithm identifiers A1, A2, .., An are composite with the 463 OID id-alg-composite. 465 It is expected that some use-cases for algorithm migration or high 466 performance will require verifiers to succeed when only a subset of 467 the component algorithms have been verified. Defining this 468 verification behaviour is out of scope for this document, and falls 469 to an application profile. 471 4. In Practice 473 This section addresses practical issues of how this draft affects 474 other protocols and standards. 476 ~~~ BEGIN EDNOTE 10~~~ 478 EDNOTE 10: Possible topics to address: 480 o The size of these certs and cert chains. 482 o In particular, implications for (large) composite keys / 483 signatures / certs on the handshake stages of TLS and IKEv2. 485 o If a cert in the chain is a composite cert then does the whole 486 chain need to be of composite Certs? 488 o We could also explain that the root CA cert does not have to be of 489 the same algorithms. The root cert SHOULD NOT be transferred in 490 the authentication exchange to save transport overhead and thus it 491 can be different than the intermediate and leaf certs. 493 o We could talk about overhead (size and processing). 495 o We could also discuss backwards compatibility. 497 o We could include a subsection about implementation considerations. 499 ~~~ END EDNOTE 10~~~ 501 4.1. PEM Storage of Composite Private Keys 503 CompositePrivateKeys can be encoded to the PEM format by placing a 504 CompositePrivateKey into the privateKey field of a PrivateKeyInfo or 505 OneAsymmetricKey object, and then applying the PEM encoding rules as 506 defined in [RFC7468] section 10 and 11 for plaintext and encrypted 507 private keys, respectively. 509 4.2. Asymmetric Key Packages (CMS) 511 The Cryptographic Message Syntax (CMS), as defined in [RFC5652], can 512 be used to digitally sign, digest, authenticate, or encrypt the 513 asymmetric key format content type. 515 When encoding composite private keys, the privateKeyAlgorithm in the 516 OneAsymmetricKey SHALL be set to id-alg-composite. 518 The parameters of the privateKeyAlgorithm SHALL be a sequence of 519 AlgorithmIdentifier objects, each of which are encoded according to 520 the rules defined for each of the different keys in the composite 521 private key. 523 The value of the privateKey field in the OneAsymmetricKey SHALL be 524 set to the DER encoding of the SEQUENCE of private key values that 525 make up the composite key. The number and order of elements in the 526 sequence SHALL be the same as identified in the sequence of 527 parameters in the privateKeyAlgorithm. 529 The value of the publicKey (if present) SHALL be set to the DER 530 encoding of the corresponding CompositePublicKey. If this field is 531 present, the number and order of component keys MUST be the same as 532 identified in the sequence of parameters in the privateKeyAlgorithm. 534 The value of the attributes is encoded as usual. 536 4.3. Cryptographic protocols 538 This section talks about how protocols like (D)TLS and IKEv2 are 539 affected by this specifications. It will not attempt to solve all 540 these problems, but it will explain the rationale, how things will 541 work and what open problems need to be solved. Obvious issues that 542 need to be discussed. 544 o How does the protocol declare support for composite signatures? 545 TLS has hooks for declaring support for specific signature 546 algorithms, however it would need to be extended, because the 547 client would need to declare support for both the composite 548 infrastructure, as well as for the various component signature 549 algorithms. 551 o How does the protocol use the multiple keys. The obvious way 552 would be to have the server sign using its composite public key; 553 is this sufficient. 555 o Overhead; including certificate size, signature processing time, 556 and size of the signature. 558 o How to deal with crypto protocols that use public key encryption 559 algorithms; this document only lists how to work with signature 560 algorithms. Encoding composite public keys is straightforward; 561 encoding composite ciphertexts is less so - we decided to put that 562 off to another draft. 564 5. IANA Considerations 566 The ASN.1 module OID is TBD. The id-alg-composite OID is to be 567 assigned by IANA. The authors suggest that IANA assign an OID on the 568 id-pkix arc: 570 id-alg-composite OBJECT IDENTIFIER ::= { 571 iso(1) identified-organization(3) dod(6) internet(1) security(5) 572 mechanisms(5) pkix(7) algorithms(6) composite(??) } 574 6. Security Considerations 576 6.1. Policy for Deprecated and Acceptable Algorithms 578 Traditionally, a public key, certificate, or signature contains a 579 single cryptographic algorithm. If and when an algorithm becomes 580 deprecated (for example, RSA-512, or SHA1), it is obvious that 581 structures using that algorithm are implicitly revoked. 583 In the composite model this is less obvious since a single public 584 key, certificate, or signature may contain a mixture of deprecated 585 and non-deprecated algorithms. Moreover, implementers may decide 586 that certain cryptographic algorithms have complementary security 587 properties and are acceptable in combination even though neither 588 algorithm is acceptable by itself. 590 Specifying a modified verification algorithm to handle these 591 situations is beyond the scope of this draft, but could be desirable 592 as the subject of an application profile document, or to be up to the 593 discretion of implementers. 595 2. Check policy to see whether A1, A2, ..., An constitutes a valid 596 combination of algorithms. 598 if not checkPolicy(A1, A2, ..., An), then 599 output "Invalid signature" 601 While intentionally not specified in this document, implementors 602 should put careful thought into implementing a meaningfull policy 603 mechinism within the context of their signature verification engines, 604 for example only algorithms that provide similar security levels 605 should be combined together. 607 6.2. Protection of Private Keys 609 Structures described in this document do not protect private keys in 610 any way unless combined with a security protocol or encryption 611 properties of the objects (if any) where the CompositePrivateKey is 612 used (see next Section). 614 Protection of the private keys is vital to public key cryptography. 615 The consequences of disclosure depend on the purpose of the private 616 key. If a private key is used for signature, then the disclosure 617 allows unauthorized signing. If a private key is used for key 618 management, then disclosure allows unauthorized parties to access the 619 managed keying material. The encryption algorithm used in the 620 encryption process must be at least as 'strong' as the key it is 621 protecting. 623 6.3. Checking for Compromised Key Reuse 625 CA implementations need to be careful when checking for compromised 626 key reuse, for example as required by WebTrust regulations; when 627 checking for compromised keys, you MUST unpack the CompositePublicKey 628 structure and compare individual component keys. In other words, 629 when marking a key as revoked for key compromise, the individual 630 component keys should be marked, not the composite key as a whole. 632 6.4. Composite Encryption and KEMs 634 This document deals only with signature keys. While the 635 CompositePublicKey and CompositePrivateKey structures could equally 636 be used to hold encryption or KEM keys, the authors warn that there 637 are non-trivial design decisions to be made when constructing a 638 multi-key public key encryption or KEM algorithm. Some of these 639 design and implementation decisions, if done incorrectly will result 640 in a catastrophic loss of security. We leave it to the community to 641 standardize analogous composite encryption and KEM schemes. 643 7. Appendices 645 7.1. ASN.1 Module 647 649 Composite-Signatures-2019 650 { TBD } 652 DEFINITIONS IMPLICIT TAGS ::= BEGIN 654 EXPORTS ALL; 656 IMPORTS 657 PUBLIC-KEY, SIGNATURE-ALGORITHM 658 FROM AlgorithmInformation-2009 -- RFC 5912 [X509ASN1] 659 { iso(1) identified-organization(3) dod(6) internet(1) 660 security(5) mechanisms(5) pkix(7) id-mod(0) 661 id-mod-algorithmInformation-02(58) } 663 SubjectPublicKeyInfo 664 FROM PKIX1Explicit-2009 665 { iso(1) identified-organization(3) dod(6) internet(1) 666 security(5) mechanisms(5) pkix(7) id-mod(0) 667 id-mod-pkix1-explicit-02(51) } 669 OneAsymmetricKey 670 FROM AsymmetricKeyPackageModuleV1 671 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 672 pkcs-9(9) smime(16) modules(0) 673 id-mod-asymmetricKeyPkgV1(50) } ; 675 -- 676 -- Object Identifiers 677 -- 679 id-alg-composite OBJECT IDENTIFIER ::= { TBD } 681 -- 682 -- Public Key 683 -- 685 pk-Composite PUBLIC-KEY ::= { 686 IDENTIFIER id-alg-composite 687 KEY CompositePublicKey 688 PARAMS ARE absent 689 CERT-KEY-USAGE 690 { digitalSignature, nonRepudiation, keyCertSign, cRLSign } 691 PRIVATE-KEY CompositePrivateKey 692 } 694 CompositePublicKey ::= SEQUENCE SIZE (1..MAX) OF SubjectPublicKeyInfo 696 CompositePrivateKey ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey 698 -- 699 -- Signature Algorithm 700 -- 702 sa-CompositeSignature SIGNATURE-ALGORITHM ::= { 703 IDENTIFIER id-alg-composite 704 VALUE CompositeSignatureValue 705 PARAMS TYPE CompositeParams ARE required 706 PUBLIC-KEYS { pk-Composite } 707 SMIME-CAPS { IDENTIFIED BY id-alg-composite } } 709 CompositeParams ::= SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier 711 CompositeSignatureValue ::= SEQUENCE SIZE (1..MAX) OF BIT STRING 713 END 715 717 7.2. Intellectual Property Considerations 719 The following IPR Disclosure relates to this draft: 721 https://datatracker.ietf.org/ipr/3588/ 723 8. Contributors and Acknowledgements 725 This document incorporates contributions and comments from a large 726 group of experts. The Editors would especially like to acknowledge 727 the expertise and tireless dedication of the following people, who 728 attended many long meetings and generated millions of bytes of 729 electronic mail and VOIP traffic over the past year in pursuit of 730 this document: 732 John Gray (Entrust Datacard), Serge Mister (Entrust Datacard), Scott 733 Fluhrer (Cisco Systems), Panos Kampanakis (Cisco Systems), Daniel Van 734 Geest (ISARA), and Tim Hollebeek (Digicert). 736 We are grateful to all, including any contributors who may have been 737 inadvertently omitted from this list. 739 This document borrows text from similar documents, including those 740 referenced below. Thanks go to the authors of those documents. 741 "Copying always makes things easier and less error prone" - 742 [RFC8411]. 744 9. References 746 9.1. Normative References 748 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 749 Mail: Part I: Message Encryption and Authentication 750 Procedures", RFC 1421, DOI 10.17487/RFC1421, February 751 1993, . 753 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 754 Requirement Levels", BCP 14, RFC 2119, 755 DOI 10.17487/RFC2119, March 1997, 756 . 758 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 759 Request Syntax Specification Version 1.7", RFC 2986, 760 DOI 10.17487/RFC2986, November 2000, 761 . 763 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 764 "Internet X.509 Public Key Infrastructure Certificate 765 Management Protocol (CMP)", RFC 4210, 766 DOI 10.17487/RFC4210, September 2005, 767 . 769 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 770 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 771 . 773 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 774 Housley, R., and W. Polk, "Internet X.509 Public Key 775 Infrastructure Certificate and Certificate Revocation List 776 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 777 . 779 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 780 RFC 5652, DOI 10.17487/RFC5652, September 2009, 781 . 783 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 784 DOI 10.17487/RFC5958, August 2010, 785 . 787 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 788 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 789 April 2015, . 791 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 792 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 793 May 2017, . 795 [RFC8411] Schaad, J. and R. Andrews, "IANA Registration for the 796 Cryptographic Algorithm Object Identifier Range", 797 RFC 8411, DOI 10.17487/RFC8411, August 2018, 798 . 800 [X.690] ITU-T, "Information technology - ASN.1 encoding Rules: 801 Specification of Basic Encoding Rules (BER), Canonical 802 Encoding Rules (CER) and Distinguished Encoding Rules 803 (DER)", ISO/IEC 8825-1:2015, November 2015. 805 9.2. Informative References 807 [I-D.pala-composite-crypto] 808 Pala, M., "Composite Public Keys and Signatures", draft- 809 pala-composite-crypto-00 (work in progress), February 810 2019. 812 [I-D.truskovsky-lamps-pq-hybrid-x509] 813 Truskovsky, A., Geest, D., Fluhrer, S., Kampanakis, P., 814 Ounsworth, M., and S. Mister, "Multiple Public-Key 815 Algorithm X.509 Certificates", draft-truskovsky-lamps-pq- 816 hybrid-x509-01 (work in progress), August 2018. 818 Authors' Addresses 820 Mike Ounsworth 821 Entrust Datacard Limited 822 1000 Innovation Drive 823 Ottawa, Ontario K2K 1E3 824 Canada 826 Email: mike.ounsworth@entrustdatacard.com 828 Massimiliano Pala 829 CableLabs 831 Email: director@openca.org