idnits 2.17.1 draft-ounsworth-pq-composite-sigs-06.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 (8 February 2022) is 802 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 636, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Downref: Normative reference to an Informational RFC: RFC 8411 Summary: 3 errors (**), 0 flaws (~~), 2 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: 12 August 2022 CableLabs 6 8 February 2022 8 Composite Signatures For Use In Internet PKI 9 draft-ounsworth-pq-composite-sigs-06 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 signature 20 data. 22 This document defines the structures CompositeSignatureValue, and 23 CompositeParams, which are sequences of the respective structure for 24 each component algorithm. This document also defines processes for 25 generating and verifying composite signatures. This document makes 26 no assumptions about what the component algorithms are, provided that 27 their algorithm identifiers and signature generation and verification 28 processes 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 12 August 2022. 47 Copyright Notice 49 Copyright (c) 2022 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 (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Composite Identifiers and Structures . . . . . . . . . . . . 4 66 2.1. Algorithm Identifier . . . . . . . . . . . . . . . . . . 5 67 2.2. Composite Keys . . . . . . . . . . . . . . . . . . . . . 5 68 2.2.1. Key Usage Bits . . . . . . . . . . . . . . . . . . . 5 69 2.3. Composite Signature . . . . . . . . . . . . . . . . . . . 6 70 2.4. Encoding Rules . . . . . . . . . . . . . . . . . . . . . 6 71 3. Composite Signature Processes . . . . . . . . . . . . . . . . 7 72 3.1. Composite Signature Generation Process . . . . . . . . . 7 73 3.2. Composite-OR Signature Generation Process . . . . . . . . 8 74 3.3. Composite Signature Verification Process . . . . . . . . 9 75 3.4. Composite-OR Signature Verification . . . . . . . . . . . 11 76 3.4.1. Composite-OR Legacy Mode . . . . . . . . . . . . . . 11 77 4. In Practice . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 4.1. Cryptographic protocols . . . . . . . . . . . . . . . . . 13 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 6.1. Policy for Deprecated and Acceptable Algorithms . . . . . 14 82 7. Appendices . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 7.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 14 84 7.2. Intellectual Property Considerations . . . . . . . . . . 16 85 8. Contributors and Acknowledgements . . . . . . . . . . . . . . 16 86 8.1. Making contributions . . . . . . . . . . . . . . . . . . 17 87 9. Normative References . . . . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Introduction 92 During the transition to post-quantum cryptography, there will be 93 uncertainty as to the strength of cryptographic algorithms; we will 94 no longer fully trust traditional cryptography such as RSA, Diffie- 95 Hellman, DSA and their elliptic curve variants, but we will also not 96 fully trust their post-quantum replacements until they have had 97 sufficient scrutiny. Unlike previous cryptographic algorithm 98 migrations, the choice of when to migrate and which algorithms to 99 migrate to, is not so clear. Even after the migration period, it may 100 be advantageous for an entity's cryptographic identity to be composed 101 of multiple public-key algorithms. 103 The deployment of composite signatures using post-quantum algorithms 104 will face two challenges 106 * Algorithm strength uncertainty: During the transition period, some 107 post-quantum signature and encryption algorithms will not be fully 108 trusted, while also the trust in legacy public key algorithms will 109 start to erode. A relying party may learn some time after 110 deployment that a public key algorithm has become untrustworthy, 111 but in the interim, they may not know which algorithm an adversary 112 has compromised. 114 * Backwards compatibility: During the transition period, post- 115 quantum algorithms will not be supported by all clients. 117 This document provides a mechanism to address algorithm strength 118 uncertainty by building on ~~ reference draft-ounsworth-pq-composite- 119 pubkeys ~~ by providing formats for encoding multiple signature 120 values into existing public signature fields, as well as the process 121 for validating a composite signature. Backwards compatibility is 122 addressed via the Composite-OR mechanism described herein. 124 This document is intended for general applicability anywhere that 125 digital signatures are used within PKIX and CMS structures. 127 1.1. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 The following terms are used in this document: 137 ALGORITHM: An information object class for identifying the type of 138 cryptographic operation to be performed. This document is primarily 139 concerned with algorithms for producing digital signatures. 141 BER: Basic Encoding Rules (BER) as defined in [X.690]. 143 COMPONENT ALGORITHM: A single basic algorithm which is contained 144 within a composite algorithm. 146 COMPOSITE ALGORITHM: An algorithm which is a sequence of two or more 147 component algorithms, as defined in Section 2. 149 DER: Distinguished Encoding Rules as defined in [X.690]. 151 LEGACY: For the purposes of this document, a legacy key or signature 152 is a non-composite key or signature. 154 PUBLIC / PRIVATE KEY: The public and private portion of an asymmetric 155 cryptographic key, making no assumptions about which algorithm. 157 SIGNATURE: A digital cryptographic signature, making no assumptions 158 about which algorithm. 160 2. Composite Identifiers and Structures 162 In order for signatures to be composed of multiple algorithms, we 163 define encodings consisting of a sequence of signature primitives 164 (aka "component algorithms") such that these structures can be used 165 as a drop-in replacement for existing signature fields such as those 166 found in PKCS#10 [RFC2986], CMP [RFC4210], X.509 [RFC5280], CMS 167 [RFC5652]. 169 This section defines the following structures: 171 * The id-alg-composite is an AlgorithmIdentifier identifying a 172 composite signature object. 174 The sa-CompositeSignature AlgorithmIdentifier and the 175 corresponding CompositeParams identify the algorithm(s) used in a 176 composite signature. 178 * The CompositeSignatureValue, carries a sequence of signatures that 179 are generated by a CompositePrivateKey, and can be verified with 180 the corresponding CompositePublicKey. 182 EDNOTE 2: the choice to define composite algorithm parameters as a 183 sequence inside the existing fields avoids the exponential 184 proliferation of OIDs that are needed for each combination of 185 signature algorithms in other schemes for achieving multi-key 186 certificates. This scheme also naturally extends from 2-keypair to 187 n-keypair keys and certificates. 189 EDNOTE 2a: We have heard community feedback that the ASN.1 structures 190 presented here are too flexible in that allow arbitrary combinations 191 of an arbitrary number of signature algorithms. The feedback is that 192 this is too much of a "footgun" for implementors and sysadmins. We 193 are working on an alternative formulation using ASN.1 information 194 object classes that allow for compiling explicit pairs of 195 algorithmIDs. We would love community feedback on which approach is 196 preferred. See slide 30 of this presentation: 197 https://datatracker.ietf.org/meeting/interim-2021-lamps-01/materials/ 198 slides-interim-2021-lamps-01-sessa-position-presentation-by-mike- 199 ounsworth-00.pdf 201 2.1. Algorithm Identifier 203 The following object identifier is used for identifying a composite 204 signature. Additional encoding information is provided below for 205 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 signature MUST be associated with a Composite public key 217 as defined in ~~ reference draft-ounsworth-pq-composite-pubkey ~~. 219 2.2.1. Key Usage Bits 221 For protocols such as X.509 [RFC5280] that specify key usage along 222 with the public key, then the composite public key associated with a 223 composite signature MUST have a signing-type key usage. 225 If the keyUsage extension is present in a Certification Authority 226 (CA) certificate that indicates id-composite-key, then any 227 combination of the following values MAY be present: 229 digitalSignature; 230 nonRepudiation; 231 keyCertSign; and 232 cRLSign. 234 If the keyUsage extension is present in an End Entity (EE) 235 certificate that indicates id-composite-key, then any combination of 236 the following values MAY be present: 238 digitalSignature; and 239 nonRepudiation; 241 2.3. Composite Signature 243 The ASN.1 algorithm object for a composite signature is: 245 sa-CompositeSignature SIGNATURE-ALGORITHM ::= { 246 IDENTIFIER id-alg-composite 247 VALUE CompositeSignatureValue 248 PARAMS TYPE CompositeParams ARE required 249 PUBLIC-KEYS { pk-Composite } 250 SMIME-CAPS { IDENTIFIED BY id-alg-composite } } 251 } 253 The following algorithm parameters MUST be included: 255 CompositeParams ::= SEQUENCE SIZE (2..MAX) OF AlgorithmIdentifier 257 The signature's CompositeParams sequence MUST contain the same 258 component algorithms listed in the same order as in the associated 259 CompositePrivateKey and CompositePublicKey. 261 The output of the composite signature algorithm is the DER encoding 262 of the following structure: 264 CompositeSignatureValue ::= SEQUENCE SIZE (2..MAX) OF BIT STRING 266 Where each BIT STRING within the SEQUENCE is a signature value 267 produced by one of the component keys. It MUST contain one signature 268 value produced by each component algorithm, and in the same order as 269 in the associated CompositeParams object. 271 The choice of SEQUENCE OF BIT STRING, rather than for example a 272 single BIT STRING containing the concatenated signature values, is to 273 gracefully handle variable-length signature values by taking 274 advantage of ASN.1's built-in length fields. 276 2.4. Encoding Rules 278 Many protocol specifications will require that composite signature 279 data structures be represented by an octet string or bit string. 281 When an octet string is required, the DER encoding of the composite 282 data structure SHALL be used directly. 284 When a bit string is required, the octets of the DER encoded 285 composite data structure SHALL be used as the bits of the bit string, 286 with the most significant bit of the first octet becoming the first 287 bit, and so on, ending with the least significant bit of the last 288 octet becoming the last bit of the bit string. 290 In the interests of simplicity and avoiding compatibility issues, 291 implementations that parse these structures MAY accept both BER and 292 DER. 294 3. Composite Signature Processes 296 This section specifies the processes for generating and verifying 297 composite signatures. 299 This process addresses algorithm strength uncertainty by providing 300 the verifier with parallel signatures from all the component 301 signature algorithms; thus breaking the composite signature would 302 require breaking all of the component signatures. 304 3.1. Composite Signature Generation Process 306 Generation of a composite signature involves applying each component 307 algorithm's signature process to the input message according to its 308 specification, and then placing each component signature value into 309 the CompositeSignatureValue structure defined in Section 2.3. 311 The following process is used to generate composite signature values. 313 Input: 314 K1, K2, .., Kn Private keys for the n component signature 315 algorithms, a CompositePrivateKey 316 M Message to be signed, an octet string 318 Output: 319 S The signatures, a CompositeSignatureValue 321 Signature Generation Process: 322 1. Generate the n component signatures independently, 323 according to their algorithm specifications. 325 for i := 1 to n 326 Si := Sign( Ki, M ) 328 2. Encode each component signature S1, S2, .., Sn into a BIT STRING 329 according to its algorithm specification. 331 S ::= Sequence { S1, S2, .., Sn } 333 3. Output S 335 Since recursive composite public keys are disallowed in ~~ Reference 336 draft-ounsworth-pq-composite-pubkeys sec-composite-pub-keys ~~, no 337 component signature may itself be a composite; ie the signature 338 generation process MUST fail if one of the private keys K1, K2, .., 339 Kn is a composite with the OID id-alg-composite. 341 A composite signature MUST produce and include in the output a 342 signature value for every component key in the corresponding 343 CompositePrivateKey. For this mode, please see Composite-OR in 344 section Section 3.2. 346 3.2. Composite-OR Signature Generation Process 348 EDNOTE: This section was written with the intention of keeping the 349 primary Composite OID reserved for the simple and strict mode; if you 350 want to do either a simple OR, or a custom policy then we have given 351 a different OID. We are still debating whether this is useful to 352 specify at issuing time, or whether this is adding needless 353 complexity to the draft. 355 If the algorithm ID of the public key associated with this signature 356 is id-composite-or-key then the signer MAY use only a subset of the 357 component keys and therefore produce fewer signatures than the number 358 of component keys. 360 Composite-OR signature generation uses the same structures and 361 algorithms as Composite, with the difference that the signature 362 generation process may emit a null instead of a signature value in 363 step 1 for one or more component algorithms. A Composite-OR 364 signature MUST NOT be entirely null; it must contain at least one 365 valid signature. 367 The design intent of this mode is to support migration scenarios 368 where an end entity has been issued keys on algorithms that either 369 itself or the peer with which it is communicating do not (yet) 370 support. This design allows for both the mode where the signer omits 371 signatures that it knows its peer cannot process in order to save 372 bandwidth and performance, and the mode where it includes all 373 component signatures and allows the verifier to choose how many to 374 verify. The latter is RECOMMENDED for signatures that need both 375 sort-term backwards compatibility as well as long-term security. 377 EDNOTE: Do we want to allow a Composite-OR with only a single 378 signature to produce non-composite signatureAlgorithm and 379 signatureValua as per [RFC5280]? Advantages: bandwidth savings of an 380 extra OID and some sequences with one element. Disadvantages: 381 ambiguous whether a signature is traditional or composite until you 382 look at the corresponding public key. 384 3.3. Composite Signature Verification Process 386 Verification of a composite signature involves applying each 387 component algorithm's verification process according to its 388 specification. 390 In the absence of an application profile specifying otherwise, 391 compliant applications MUST output "Valid signature" (true) if and 392 only if all component signatures were successfully validated, and 393 "Invalid signature" (false) otherwise. 395 The following process is used to perform this verification. 397 Input: 398 P Signer's composite public key 399 M Message whose signature is to be verified, an octet string 400 S Composite Signature to be verified 401 A Composite Algorithm identifier 403 Output: 404 Validity "Valid signature" (true) if the composite signature 405 is valid, "Invalid signature" (false) otherwise. 407 Signature Verification Procedure:: 408 1. Parse P, S, A into the component public keys, signatures, 409 and algorithm identifiers 411 P1, P2, .., Pn := Desequence( P ) 412 S1, S2, .., Sn := Desequence( S ) 413 A1, A2, .., An := Desequence( A ) 415 If Error during Desequencing, or the three sequences have 416 different numbers of elements, or any of the public keys P1, P2, .., Pn or 417 algorithm identifiers A1, A2, .., An are composite with the OID 418 id-alg-composite then output "Invalid signature" and stop. 420 2. Check each component signature individually, according to its 421 algorithm specification. 422 If any fail, then the entire signature validation fails. 424 for i := 1 to n 425 if not verify( Pi, M, Si ), then 426 output "Invalid signature" 428 if all succeeded, then 429 output "Valid signature" 431 Since recursive composite public keys are disallowed in ~~ Reference 432 draft-ounsworth-pq-composite-keys sec-composite-pub-keys ~~, no 433 component signature may be composite; ie the signature verification 434 procedure MUST fail if any of the public keys P1, P2, .., Pn or 435 algorithm identifiers A1, A2, .., An are composite with the OID id- 436 alg-composite. 438 3.4. Composite-OR Signature Verification 440 EDNOTE: This section was written with the intention of keeping the 441 primary Composite OID reserved for the simple and strict mode; if you 442 want to do either a simple OR, or a custom policy then we have given 443 a different OID. We are still debating whether this is useful to 444 specify at issuing time, or whether this is adding needless 445 complexity to the draft. 447 When the public key associated with the signature being verified has 448 algorithm id-composite-or-key, then an alternate verification 449 processes MAY be used, at the discretion of the implementor. In this 450 section we provide some examples of alternate verification processes. 452 If the signature is a traditional (non-composite) algorithm and value 453 or a composite signature with a single component, then it MAY be 454 considered valid if it verifies under one of the component keys. 456 If the signature is composite, then the implementor MAY implement 457 policy for which combinations are acceptable. 459 EDNOTE: Does this mean Composite-OR end entity certificates need to 460 be issued by a PKI that is marked as Composite-OR all the way to the 461 top so that verifiers that do not support all the algorithms don't 462 fail? Need to think more about the security implications of allowing 463 a Composite-or in an end entity cert implicitely turning all 464 Composite algIDs into Composite-or algIDs in its cert chain. 466 EDNOTE: Do we need to specify the semantics of verifying an "n of m" 467 subset signature? I suspect that specifying this in general will be 468 a rat's nest of edge cases, so I propose to "leave this to the 469 implementor". 471 3.4.1. Composite-OR Legacy Mode 473 The Composite-OR Legacy Mode is provided to facilitate migration by 474 allowing existing PKI entities (including root CAs, intermediate CAs, 475 and end entities) to have their existing keys re-certified inside a 476 Composite-OR structure along with Post-Quantum keys, and for 477 signatures made by that key prior to the migration to remain valid. 478 Note that Composite-OR Legacy Mode is only provided for signature 479 verification, and not for signature generation; legacy signatures 480 SHOULD NOT be produced from a Composite key. 482 EDNOTE: to further solidify this, we could add a clause that Legacy 483 Mode signatures are to fail if the signature was produced after 484 notBefore date of the Composite-OR certificate? 485 In Composite-OR Legacy Mode, a legacy signature algorithm and legacy 486 signature value MAY be validated against a Composite-OR public key. 487 The legacy signature algorithm is to be interpreted by the verifier 488 as a sa-CompositeSignature with CompositeParams in the following way: 490 CompositeParams {legacyAlgorithmIdentifier, null, .., null} 492 with the correct number of nulls to match the Composite-OR public key 493 that the signature is being verified against. For the purposes of a 494 signature validation under Composite-OR Legacy Mode, a null 495 AlgorithmIdentifier is considered to be a match for the corresponding 496 algorithm in the Composite-OR public key. 498 The legacy signature value is to be interpreted by the verifier as a 499 sa-CompositeSignature with CompositeParams in the following way: 501 CompositeSignatureValue {legacySignatureValue, null, .., null} 503 with the correct number of nulls to match the Composite-OR public key 504 that the signature is being verified against. The verification 505 algorithm in section Section 3.4 applies. 507 Security consideration: when implementing Composite-OR Legacy Mode, 508 it is important to catch the edge case of {null, null, .., null} for 509 both AlgorithmIdentifier and SignatureValue and return Invalid 510 Signature. 512 It is RECOMMENDED that Composite-OR Legacy Mode be implemented as an 513 optional mode in the verifier that can be enabled or disabled by 514 runtime configuration or policy. 516 EDNOTE: the signing public key is often identified in the signed 517 document by issuer+serialNumber or by an SKI containing a hash of the 518 public key value. Might need X.509 extensions identifying the SKI of 519 the legacy cert it's replacing? 521 4. In Practice 523 This section addresses practical issues of how this draft affects 524 other protocols and standards. 526 ~~~ BEGIN EDNOTE 10~~~ 528 EDNOTE 10: Possible topics to address: 530 * The size of these certs and cert chains. 532 * In particular, implications for (large) composite keys / 533 signatures / certs on the handshake stages of TLS and IKEv2. 535 * If a cert in the chain is a composite cert then does the whole 536 chain need to be of composite Certs? 538 * We could also explain that the root CA cert does not have to be of 539 the same algorithms. The root cert SHOULD NOT be transferred in 540 the authentication exchange to save transport overhead and thus it 541 can be different than the intermediate and leaf certs. 543 * We could talk about overhead (size and processing). 545 * We could also discuss backwards compatibility. 547 * We could include a subsection about implementation considerations. 549 ~~~ END EDNOTE 10~~~ 551 4.1. Cryptographic protocols 553 This section talks about how protocols like (D)TLS and IKEv2 are 554 affected by this specifications. It will not attempt to solve all 555 these problems, but it will explain the rationale, how things will 556 work and what open problems need to be solved. Obvious issues that 557 need to be discussed. 559 * How does the protocol declare support for composite signatures? 560 TLS has hooks for declaring support for specific signature 561 algorithms, however it would need to be extended, because the 562 client would need to declare support for both the composite 563 infrastructure, as well as for the various component signature 564 algorithms. 566 * How does the protocol use the multiple keys. The obvious way 567 would be to have the server sign using its composite public key; 568 is this sufficient. 570 * Overhead; including certificate size, signature processing time, 571 and size of the signature. 573 * How to deal with crypto protocols that use public key encryption 574 algorithms; this document only lists how to work with signature 575 algorithms. Encoding composite public keys is straightforward; 576 encoding composite ciphertexts is less so - we decided to put that 577 off to another draft. 579 5. IANA Considerations 581 The ASN.1 module OID is TBD. The id-alg-composite OID is to be 582 assigned by IANA. The authors suggest that IANA assign an OID on the 583 id-pkix arc: 585 id-alg-composite OBJECT IDENTIFIER ::= { 586 iso(1) identified-organization(3) dod(6) internet(1) security(5) 587 mechanisms(5) pkix(7) algorithms(6) composite(??) } 589 6. Security Considerations 591 6.1. Policy for Deprecated and Acceptable Algorithms 593 Traditionally, a public key, certificate, or signature contains a 594 single cryptographic algorithm. If and when an algorithm becomes 595 deprecated (for example, RSA-512, or SHA1), it is obvious that 596 structures using that algorithm are implicitly revoked. 598 In the composite model this is less obvious since a single public 599 key, certificate, or signature may contain a mixture of deprecated 600 and non-deprecated algorithms. Moreover, implementers may decide 601 that certain cryptographic algorithms have complementary security 602 properties and are acceptable in combination even though neither 603 algorithm is acceptable by itself. 605 Specifying a modified verification algorithm to handle these 606 situations is beyond the scope of this draft, but could be desirable 607 as the subject of an application profile document, or to be up to the 608 discretion of implementers. 610 2. Check policy to see whether A1, A2, ..., An constitutes a valid 611 combination of algorithms. 613 if not checkPolicy(A1, A2, ..., An), then 614 output "Invalid signature" 616 While intentionally not specified in this document, implementors 617 should put careful thought into implementing a meaningfull policy 618 mechinism within the context of their signature verification engines, 619 for example only algorithms that provide similar security levels 620 should be combined together. 622 7. Appendices 624 7.1. ASN.1 Module 625 627 Composite-Signatures-2019 628 { TBD } 630 DEFINITIONS IMPLICIT TAGS ::= BEGIN 632 EXPORTS ALL; 634 IMPORTS 635 PUBLIC-KEY, SIGNATURE-ALGORITHM 636 FROM AlgorithmInformation-2009 -- RFC 5912 [X509ASN1] 637 { iso(1) identified-organization(3) dod(6) internet(1) 638 security(5) mechanisms(5) pkix(7) id-mod(0) 639 id-mod-algorithmInformation-02(58) } 641 SubjectPublicKeyInfo 642 FROM PKIX1Explicit-2009 643 { iso(1) identified-organization(3) dod(6) internet(1) 644 security(5) mechanisms(5) pkix(7) id-mod(0) 645 id-mod-pkix1-explicit-02(51) } 647 OneAsymmetricKey 648 FROM AsymmetricKeyPackageModuleV1 649 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 650 pkcs-9(9) smime(16) modules(0) 651 id-mod-asymmetricKeyPkgV1(50) } ; 653 -- 654 -- Object Identifiers 655 -- 657 id-alg-composite OBJECT IDENTIFIER ::= { TBD } 659 -- 660 -- Public Key 661 -- 663 pk-Composite PUBLIC-KEY ::= { 664 IDENTIFIER id-alg-composite 665 KEY CompositePublicKey 666 PARAMS ARE absent 667 PRIVATE-KEY CompositePrivateKey 668 } 670 CompositePublicKey ::= SEQUENCE SIZE (2..MAX) OF SubjectPublicKeyInfo 672 CompositePrivateKey ::= SEQUENCE SIZE (2..MAX) OF OneAsymmetricKey 673 -- 674 -- Signature Algorithm 675 -- 677 sa-CompositeSignature SIGNATURE-ALGORITHM ::= { 678 IDENTIFIER id-alg-composite 679 VALUE CompositeSignatureValue 680 PARAMS TYPE CompositeParams ARE required 681 PUBLIC-KEYS { pk-Composite } 682 SMIME-CAPS { IDENTIFIED BY id-alg-composite } } 684 CompositeParams ::= SEQUENCE SIZE (2..MAX) OF AlgorithmIdentifier 686 CompositeSignatureValue ::= SEQUENCE SIZE (2..MAX) OF BIT STRING 688 END 690 692 7.2. Intellectual Property Considerations 694 The following IPR Disclosure relates to this draft: 696 https://datatracker.ietf.org/ipr/3588/ 698 8. Contributors and Acknowledgements 700 This document incorporates contributions and comments from a large 701 group of experts. The Editors would especially like to acknowledge 702 the expertise and tireless dedication of the following people, who 703 attended many long meetings and generated millions of bytes of 704 electronic mail and VOIP traffic over the past year in pursuit of 705 this document: 707 John Gray (Entrust), Serge Mister (Entrust), Scott Fluhrer (Cisco 708 Systems), Panos Kampanakis (Cisco Systems), Daniel Van Geest (ISARA), 709 Tim Hollebeek (Digicert), and Francois Rousseau. 711 We are grateful to all, including any contributors who may have been 712 inadvertently omitted from this list. 714 This document borrows text from similar documents, including those 715 referenced below. Thanks go to the authors of those documents. 716 "Copying always makes things easier and less error prone" - 717 [RFC8411]. 719 8.1. Making contributions 721 Additional contributions to this draft are weclome. Please see the 722 working copy of this draft at, as well as open issues at: 724 https://github.com/EntrustCorporation/draft-ounsworth-composite-sigs 726 9. Normative References 728 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 729 Requirement Levels", BCP 14, RFC 2119, 730 DOI 10.17487/RFC2119, March 1997, 731 . 733 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 734 Request Syntax Specification Version 1.7", RFC 2986, 735 DOI 10.17487/RFC2986, November 2000, 736 . 738 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 739 "Internet X.509 Public Key Infrastructure Certificate 740 Management Protocol (CMP)", RFC 4210, 741 DOI 10.17487/RFC4210, September 2005, 742 . 744 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 745 Housley, R., and W. Polk, "Internet X.509 Public Key 746 Infrastructure Certificate and Certificate Revocation List 747 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 748 . 750 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 751 RFC 5652, DOI 10.17487/RFC5652, September 2009, 752 . 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 Authors' Addresses 770 Mike Ounsworth 771 Entrust Limited 772 2500 Solandt Road -- Suite 100 773 Ottawa, Ontario K2K 3G5 774 Canada 776 Email: mike.ounsworth@entrust.com 778 Massimiliano Pala 779 CableLabs 781 Email: director@openca.org