idnits 2.17.1 draft-ounsworth-pq-composite-sigs-00.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 (March 08, 2019) is 1875 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) == Unused Reference: 'I-D.pala-composite-crypto' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'I-D.truskovsky-lamps-pq-hybrid-x509' is defined on line 670, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2986 == 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: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS M. Ounsworth 3 Internet-Draft S. Mister 4 Intended status: Standards Track J. Gray 5 Expires: September 9, 2019 Entrust Datacard 6 S. Fluhrer 7 P. Kampanakis 8 Cisco Systems 9 March 08, 2019 11 Composite Keys and Signatures For Use In Internet PKI 12 draft-ounsworth-pq-composite-sigs-00 14 Abstract 16 With the widespread adoption of post-quantum cryptography will come 17 the need for an entity to possess multiple public keys on different 18 cryptographic algorithms. Since the trustworthiness of individual 19 post-quantum algorithms is at question, a multi-key cryptographic 20 operation will need to be performed in such a way that breaking it 21 requires breaking each of the component algorithms individually. 22 This requires defining new structures for holding composite public 23 keys and composite signature data. 25 This document defines the structures CompositePublicKey, 26 CompositeSignatureAlgorithmParams, and CompositeSignatureValue which 27 are sequences of the respective structure for each component 28 algorithm. This document also defines algorithms for generating and 29 verifying composite signatures. This document makes no assumptions 30 about what the component algorithms are, provided that their 31 algorithm identifiers and signature generation and verification 32 algorithms are defined. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 9, 2019. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Definitions and notation . . . . . . . . . . . . . . . . . . 4 70 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4. Composite Structures . . . . . . . . . . . . . . . . . . . . 5 73 4.1. Composite Public Key . . . . . . . . . . . . . . . . . . 5 74 4.2. Composite Signature Algorithm . . . . . . . . . . . . . . 6 75 4.3. Encoding Composite Structures As Octet Strings and Bit 76 Strings . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 5. Composite Signature Algorithm . . . . . . . . . . . . . . . . 7 78 5.1. Composite Signature Generation . . . . . . . . . . . . . 7 79 5.2. Composite Signature Verification . . . . . . . . . . . . 7 80 6. Mechanisms to distribute verification policy to clients . . . 9 81 6.1. Local verifier policy . . . . . . . . . . . . . . . . . . 9 82 6.2. Extra metadata in the public key or signature . . . . . . 9 83 6.3. Extra metadata in the certificate . . . . . . . . . . . . 10 84 6.4. Policy certificate issued by the Certificate Authority . 10 85 6.5. Policy constraints in a cross-certificate . . . . . . . . 10 86 6.6. Revoked Algorithms CRL Extension . . . . . . . . . . . . 10 87 6.6.1. Implicit Revocation . . . . . . . . . . . . . . . . . 11 88 7. New Algorithm Identifiers . . . . . . . . . . . . . . . . . . 12 89 8. In Practice . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 9. Implications for existing standards . . . . . . . . . . . . . 12 91 9.1. RFC 2986 . . . . . . . . . . . . . . . . . . . . . . . . 12 92 9.2. RFC 5280 . . . . . . . . . . . . . . . . . . . . . . . . 12 93 9.3. Cryptographic protocols . . . . . . . . . . . . . . . . . 12 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 95 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 96 12. Appendices . . . . . . . . . . . . . . . . . . . . . . . . . 13 97 12.1. Intellection Property Considerations . . . . . . . . . . 13 98 12.2. Comparison with draft-truskovsky-lamps-pq-hybrid-x509 . 13 99 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 100 14. Acknowledgenents . . . . . . . . . . . . . . . . . . . . . . 14 101 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 102 15.1. Normative References . . . . . . . . . . . . . . . . . . 14 103 15.2. Informative References . . . . . . . . . . . . . . . . . 14 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 106 1. Introduction 108 During the transition to post-quantum cryptography, there will be 109 uncertainty as to the strength of cryptographic algorithms; we will 110 no longer fully trust traditional cryptography such as RSA, Diffie- 111 Hellman, DSA and their elliptic curve variants, but we will also not 112 fully trust their post-quantum replacements until they have had 113 sufficient scrutiny. Unlike previous cryptographic algorithm 114 migrations, the choice of when to migrate and which algorithms to 115 migrate to, is not so clear. Even after the migration period it may 116 be advantageous for an entity's cryptographic identity to be composed 117 of multiple public-key algorithms. Even after the transition period, 118 a composite approach may be advantageous as a single entity may have 119 multiple public keys on different algorithms or strengths to address 120 different use-cases, and a single signature may want to compase 121 multiple of them together. 123 The deployment of composite public keys and signatures using post- 124 quantum algorithms will face two challenges 126 o Algorithm strength uncertainty: During the transition period, some 127 post-quantum signature and encryption algorithms will not be fully 128 trusted, while also the trust in legacy public key algorithms will 129 also start to erode. A relying party may learn some time after 130 deployment that a public key algorithm has become untrustworthy, 131 but in the interim, they may not know which algorithm an adversary 132 has compromised. 134 o Backwards compatibility: During the transition period, post- 135 quantum algorithms will not be supported by all clients. 137 This document provides a mechanism to address algorithm strength 138 uncertainty by providing formats for encoding multiple public keys 139 and multiple signature values into existing public key and signature 140 fields. The issue of backwards compatibility is left open to be 141 addressed in separate draft(s). 143 This document is intended for general applicability anywhere that 144 public key structures or digital signatures are used, but where 145 specific design decisions needed to be made, the authors chose the 146 variant that caused the least disruption to existing X.509 147 certificates, as defined in [RFC5280]. 149 _EDNOTE: While the scope of this document is restricted to 150 signatures, we note that the same structure is equally applicable to 151 asymmetric encryption keys. Though a word of warning that the 152 corresponding "encrypt / decrypt with a composite public key" logic 153 is somewhat less obvious than; a naive implementer might be tempted 154 to follow the same pattern as bellow and encrypt the message with 155 each public key separately and then concatenate the ciphertexts, 156 which is wrong. Specifying the correct implementation of such an 157 encryption scheme is out of scope for this document, but would be 158 good work for someone in the standards community to pick 159 up._"CompositePublicKey" 161 2. Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 165 "OPTIONAL" in this document are to be interpreted as described in BCP 166 14 [RFC2119] [RFC8174] when, and only when, they appear in all 167 capitals, as shown here. 169 3. Definitions and notation 171 3.1. Definitions 173 _EDNOTE: A glossary of terms we define for this document, or terms 174 that we borrow from other RFCs._ 176 ALGORITHM: An information object class for identifying the type of 177 cryptographic operation to be performed. This document is 178 primarily concerned with algorithms for producing digital 179 signatures, though the public key structure could just as 180 easily hold encryption keys. 182 COMPONENT ALGORITHM: A single basic algorithm which is contained 183 within a composite algorithm. 185 COMPOSITE ALGORITHM: An algorithm which is a sequence of one or 186 more basic algorithm, as defined in 187 {{sec-composite-structs}}. 189 3.2. Notation 191 No special notation is used in this document. 193 4. Composite Structures 195 In order for public keys and signatures to be composed of multiple 196 algorithms, the respective structures defined in [RFC2986], [RFC5280] 197 (AND OTHERS??) need to be extended. We define encodings of sequences 198 of public keys and signature data which consist of a sequence of 199 public keys and signatures from more basic signature algorithms (aka 200 "component algorithms") such that these structures can be places into 201 any existing public key or signature structure. 203 This section defines 205 o Composite public key: A general structure for holding multiple 206 public keys within a single public key data structure. 208 o Composite signature: Data structures needed to make use of the 209 Composite Signature signature algorithm (defined in Section 5), 210 which encapsulates signatures made with multiple public keys. 212 _EDNOTE: Defining composite algorithm parameters as a sequence inside 213 the existing structure avoids an exponential proliferation of OIDs 214 that are needed for each pairwise combination of signature algorithms 215 in other competing schemes for achieving multi-key certificates. 216 This scheme also naturally extends from 2-keypair to n-keypair keys 217 and certificates._ 219 4.1. Composite Public Key 221 A composite public key is a sequence of component public keys that 222 are used together. A composite public key is identified by the 223 object identifier 225 id-ce-compositePublicKey OBJECT IDENTIFIER ::= { OID } 227 The parameters field for this public key type MUST be absent. The 228 composite public key data is represented by the following structure: 230 CompositePublicKey ::= SEQUENCE OF SubjectPublicKeyInfo 232 where each element of the sequence is a "SubjectPublicKeyInfo" of a 233 public key that MAY be used in conjunction with the other keys in the 234 sequence. When the public key must be provided in octet string or 235 bit string format, the data structure is converted as specified in 236 Section 4.3. 238 _EDNOTE: This document does not define the corresponding private key 239 formats because the authors deemed it to be out of scope. We do note 240 that the draft the Max Pala on a similar topic, does define private 241 key formats, so there could be scope to merge these 242 submissions._[I-D.pala-composite-crypto] 244 4.2. Composite Signature Algorithm 246 The Composite Signature signature algorithm defined in Section 5 is 247 identified by the following object identifier: 249 id-ce-compositeSignature OBJECT IDENTIFIER ::= { OID } 251 The following algorithm parameters MUST be included when this 252 identifier is used: 254 CompositeSignatureAlgorithmParams ::= SEQUENCE OF AlgorithmIdentifier 256 When a composite signature is generated by a key with a 257 CompositePublicKey, the signature's CompositeSignatureAlgorithmParams 258 sequence MUST contain the same component algorithms listed in the 259 same order as in the associated CompositePublicKey. 261 The Composite Signature algorithm output is the DER encoding of the 262 following structure: 264 id-ce-CompositeSignatureValue OBJECT IDENTIFIER ::= { OID } 266 CompositeSignatureValue ::= SEQUENCE OF BIT STRING 268 Where each bit string within "CompositeSignatureValue" is a signature 269 by one of the component signature algorithms. 271 The choice of "SEQUENCE OF BIT STRING" rather than "BIT STRING" is so 272 the type-length-value encoding can solve the problem of variable- 273 length signature values. The signature's "CompositeSignatureValue" 274 sequence MUST contain the same component algorithms listed in the 275 same order as in the associated "CompositeSignatureAlgorithmParams". 277 4.3. Encoding Composite Structures As Octet Strings and Bit Strings 279 Many specifications require that the composite public key and 280 composite signature data structures be represented by an octet string 281 or bit string. When an octet string is required, the DER encoding of 282 the composite data structure SHALL be used directly. When a bit 283 string is required, the octets of the DER encoded composite data 284 structure SHALL be used as the bits of the bit string, with the most 285 significant bit of the first octet becoming the first bit, and so on, 286 ending with the least significant bit of the last octet becoming the 287 last bit of the bit string. 289 5. Composite Signature Algorithm 291 The Composite Signature signature algorithm generates a single 292 composite signature by using multiple private keys to apply multiple 293 signature algorithms to the input message, with the resulting 294 signature effectively being the concatenation of the individual 295 signature values. 297 This algorithm addresses algorithm strength uncertainty by providing 298 the verifier with parallel signatures from all the component 299 signature algorithms used as part of the composite signature; 300 breaking the composite signature would require breaking each of the 301 component signatures. 303 5.1. Composite Signature Generation 305 The following algorithm is used to generate composite signature 306 values. 308 Input: 309 K1, K2, ..., Kn Private keys for the n component signature 310 algorithms 311 M Message to be signed, an octet string 313 Output: 314 S Signature, an octet string 316 Signature Generation Procedure: 317 1. Generate the n component signatures independently, 318 according to their algorithm specifications. 319 for i := 1 to n 320 Si := Sign( Ki, M ) 321 2. DER encode the component signatures into an ASN.1 value of type 322 Signature, where the type Signature has the syntax 323 Signature ::= Sequence { S1, S2, ..., Sn } 324 Let S be the DER encoding of the Signature 325 3. Output S 327 5.2. Composite Signature Verification 329 Verification of a composite signature involves applying each 330 component algorithm's verification routine according to its 331 specification, and then outputting "Valid signature" (true) if a 332 sufficient number of component algorithms were valid, and "Invalid 333 signature" (false) otherwise. 335 Implementations MAY include policy mechanisms for determining which 336 and how many component algorithms must be valid in order for the 337 composite signature to be considered valid. See Section 6 for 338 further discussion of possible standardization of such mechanisms. 339 This section assumes the existence of such a policy mechanism, 340 specifically one that allows revocation of individual component 341 algorithms. 343 This section provides a sample algorithm for validating composite 344 signatures. Compliant implementations MUST return "Invalid 345 signature" whenever the sample algorithm does, but MAY require more 346 than one signature to be valid. 348 Input: 349 P Signer's composite public key 350 M Message whose signature is to be verified, an octet string 351 S Composite Signature to be verified 352 A Composite Algorithm identifier 354 Output: 355 Validity "Valid signature" (true) if the composite signature is 356 valid, "Invalid signature" (false) otherwise. 358 Signature Verification Procedure:: 359 1. Parse P, S, A into the component public keys, signatures, 360 algorithm identifiers 361 P1, P2, ..., Pn := Desequence( P ) 362 S1, S2, ..., Sn := Desequence( S ) 363 A1, A2, ..., An := Desequence( A ) 365 If Error during Desequencing, or the three sequences have different 366 numbers of elements, then output "Invalid signature" and stop. 368 2. Check each signature individually 369 V1, V2 , ..., Vn := BOOLEAN 370 for i := 1 to n 371 Check if Ai is a recognized algorithm, if so then, 372 Check if algorithm Ai has been revoked, if not then, 373 Verify the component signature according to the component 374 algorithm's specification 375 Vi = verify( Pi, M, Si ) 377 3. Check policy to see whether V1, V2, ..., Vn constitutes a valid 378 signature 379 if isValid(V1, V2, ..., Vn), then 380 output "Valid signature" 381 else 382 output "Invalid signature" 384 If "V1 = V2 = ... = Vn = false" for all "Vi", then "isValid(V1, V2, 385 ..., Vn)" MUST return false. Implementations MAY include additional 386 policy mechanisms as discussed in Section 6. 388 6. Mechanisms to distribute verification policy to clients 390 In the traditional world of single-key public keys and signatures, 391 the semantics of a signature and a verification are straight-forward: 392 if the key is trusted (via public key pinning, a PKIX revocation 393 check, etc) and the signature is valid, then the signed content can 394 be trusted. However the semantics are less obvious in a world where 395 public keys and signatures are composed of two or more algorithms; it 396 is conceivable that even though one component algorithm fails 397 verification, for example because the algorithm is revoked, a multi- 398 algorithm signature may contain enough other trustworthy component 399 algorithms to still be considered valid. 401 This section addresses how a verifier can obtain policy information 402 for which and/or how many component algorithms must be valid in order 403 for the signature as a whole to be valid. The authors ask for 404 community feedback about whether this needs to be specified, and if 405 so, how best to do it. 407 This section lists rough outlines for several such mechanisms that 408 have come up in discussion during the drafting of this document. 409 They are mainly focused around X.509 PKIs, and provided here merely 410 for the purposes of sparking debate. The authors believe that by 411 specifying such a mechanism, the world will be able to more quickly 412 react to news of algorithm compromise with a lower service disruption 413 compared to the need to revoke and re-issue all certificates using 414 that algorithm. However, we are not sure if the gains justify the 415 added complexity. 417 6.1. Local verifier policy 419 Much as we do today, this is left up to domain administrators and 420 software vendors to implement the guidance of governing bodies on a 421 system-by-system basis. 423 6.2. Extra metadata in the public key or signature 425 This policy information could be specified by the signer at signing 426 time. Depending on the structure of the databeing signed, this 427 metadata could go into the public key, or an extension to the 428 signature, or some other field provided that it is inside the signed 429 data blob. 431 6.3. Extra metadata in the certificate 433 This policy information could be included in a certificate via an 434 X.509 v3 extension. This gives the Certificate Authority control, 435 but has the drawback that updating the policy requires revoking and 436 reissuing certificates. 438 6.4. Policy certificate issued by the Certificate Authority 440 Certificate Authorities have the ability to issue policy certificates 441 that specify the behaviour when verifying signatures performed by 442 keys in certificates within the scope of the policy certificate. 444 This method has the advantage that policy is centrally-managed, and 445 can be updated without needing to reissue any certificates, but has 446 the drawback that not all PKI implementations support policy 447 certificates. 449 6.5. Policy constraints in a cross-certificate 451 This method behaves similarly to the policy certificate method above, 452 but has better support across PKI implementations. 454 6.6. Revoked Algorithms CRL Extension 456 Add an extension to CRLs so that in addition to revoking 457 certificates, they can also revoke algorithms for all certificates 458 within the scope of that CRL. Implemented with care, this could 459 allow a single PKI to do a staged algorithm migration by only 460 revoking the algorithm for one CRL group at a time. 462 id-ce-RevokedAlgorithms OBJECT IDENTIFIER ::= { OID } 464 RevokedAlgorithms ::= SEQUENCE OF SEQUENCE { 465 algorithms AlgorithmIdentifier, 466 revocationDate Time, 467 crlEntryExtensions Extensions OPTIONAL 468 -- if present, version MUST be v2 469 } 471 _EDNOTE: do we need the crlEntryExtensions field? If so, which ones 472 from https://tools.ietf.org/html/rfc5280#section-5.3 are allowed 473 here?_ 475 There may only be one "RevokedAlgorithms" extension in a CRL. This 476 extension is OPTIONAL. If a CRL contains only composite 477 certificates, then this extension SHOULD be designated as critical. 479 If a CRL contains a mixture of composite and traditional certificates 480 then it SHOULD be designated as non-critical. 482 If the Revoked Algorithms extension is present in a CRL, then a 483 client performing a certificate validation on an otherwise non- 484 revoked certificate within the scope of that CRL MUST skip any 485 signatures corresponding to a revoked algorithm; thus a certificate 486 is valid only if it would have been valid had those Algorithm IDs and 487 Signature Values been omitted from the certificate. 489 Once a algorithm has been marked as revoked on a given CRL, it MUST 490 remain revoked on subsequent CRLs. 492 _EDNOTE: Is there corresponding wording about cert serial numbers on 493 CRLs from RFC5280? Or is this unnecessary implied?_ 495 Note that a similar mechanism could be used on a per-certificate 496 basis via CRL Entry Extensions, however the authors believe that 497 giving operators the ability to perform partial revocation of a 498 certificate (ie revoking some keys or signatures but leaving the 499 certificate as a whole valid) will greatly increase the complexity of 500 certificate validation routines, thus increasing the chance of both 501 human error, and implementation bugs leading to vulnerabilities, 502 without providing a commensurate amount of increased functionality. 503 By not defining a new CRL Entry Extension, the following requirement 504 is implied: if any key within a certificate warrant revocation, the 505 entire certificate MUST be revoked using the existing revocation 506 mechanisms (this does not apply when the algorithm is globally 507 revoked for the entire scope of this CRL). 509 6.6.1. Implicit Revocation 511 A Composite Signature Algorithm is considered to be "implicitly 512 revoked" if the certificate is otherwise valid but one of the 513 following conditions are met. 515 o A certificate using a single-key algorithm which is revoked within 516 the scope of its CRL. In this case, signature verification SHOULD 517 fail when performed by a compliant client, but of course will 518 succeed when performed by a legacy client which is not aware of 519 this CRL extension. 521 o All of the component algorithms are revoked within the scope if 522 its CRL. In this case, signature verification MUST fail when 523 performed by a compliant client, regardless of which verification 524 algorithm is used. 526 At the time of an algorithm revocation, a certificate authority MAY 527 revoke certificates meeting one ofd the above criteria (by placing 528 them in the traditional "revokedCertificates" list) with a revocation 529 reason of "keyCompromise". OCSP responders SHOULD designate a 530 certificate as revoked if it meets the above condition. 532 7. New Algorithm Identifiers 534 _EDNOTE: This subsection will define the OIDs for the initial 535 composite algorithm combinations we want to define. These are the 536 OID that Section 10 will ask for IANA to assign._ 538 8. In Practice 540 _EDNOTE: This section will talk about practical issue of how these 541 certificates will be used. For example it will talk about the size 542 of these certs and cert chains. It will explain that if a cert in 543 the chain is a Composite cert then the whole chain needs to be of 544 Composite Certs. It will also explain that the root CA cert does not 545 have to be of the same algorithms. The root cert SHOULD NOT be 546 transferred in the authentication exchange to save transport overhead 547 and thus it can be different than the intermediate and leaf certs. 548 It will talk about overhead (size and processing). It will also 549 discuss backwards compatibility. It could include a subsection about 550 implementation considerations._ 552 9. Implications for existing standards 554 9.1. RFC 2986 556 _EDNOTE: summarize the updates to RFC 2986 (CSR / PKCS#10)._ 558 9.2. RFC 5280 560 _EDNOTE: summarize the updates to RFC 5280 (X.509)._ 562 9.3. Cryptographic protocols 564 This section talks about how protocols like (D)TLS and IKEv2 are 565 affected by this specifications. It will not attempt to solve all 566 these problems, but it will explain the rationale, how things will 567 work and what open problems need to be solved. Obvious issues that 568 need to be discussed. 570 o How does the protocol declare support for composite signatures? 571 TLS has hooks for declaring support for specific signature 572 algorithms, however it would need to be extended, because the 573 client would need to declare support for both the composite 574 infrastructure, as well as for the various component signature 575 algorithms. 577 o How does the protocol use the multiple keys. The obvious way 578 would be to have the server sign using its composite public key; 579 is this sufficient. 581 o Overhead; including certificate size, signature processing time, 582 and size of the signature. 584 o How to deal with crypto protocols that use public key encryption 585 algorithms; this document only lists how to work with signature 586 algorithms. Encoding composite public keys is straightforward; 587 encoding composite ciphertexts is less so - we decided to put that 588 off to another draft. 590 10. IANA Considerations 592 _EDNOTE: This section will include content only if new OIDs or IANA 593 codepoints are assigned for it._ 595 11. Security Considerations 597 _EDNOTE: This section includes the Security Considerations._ 599 o CA implementations need to be careful when checking for 600 compromised key reuse, for example as required by WebTrust 601 regulations; unpack the CompositePublicKey structure and compare 602 individual keys. 604 o The corresponding multi-key encryption routine is considerably 605 more prone to implementation errors that will result in a 606 catestrophic loss of security, as compared with the signature 607 algorithms specified in this document. 609 12. Appendices 611 12.1. Intellection Property Considerations 613 The authors claim no IPR associated with any of the content of this 614 draft. 616 12.2. Comparison with draft-truskovsky-lamps-pq-hybrid-x509 618 _EDNOTE: This section will explain the differences from . IPR Claims 619 should be mentioned here if necessary. Other things to consider are 620 the things like simplicity and format, inadvertnt implementation 621 errors, algorithm agility._[I-D.truskovsky-lamps-pq-hybrid-x509] 623 13. Contributors 625 This document incorporates contributions and comments from a large 626 group of experts. The Editor would especially like to acknowledge 627 the tireless dedication of the following people, who attended many 628 long meetings and generated millions of bytes of electronic mail over 629 the past 3 years months in pursuit of this document: 631 We are grateful to all, including any contributors who may have been 632 inadvertently omitted from this list. 634 14. Acknowledgenents 636 _EDNOTE: this section include all those that need to be acknowledged 637 in the draft_ 639 15. References 641 15.1. Normative References 643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 644 Requirement Levels", BCP 14, RFC 2119, 645 DOI 10.17487/RFC2119, March 1997, 646 . 648 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 649 Request Syntax Specification Version 1.7", RFC 2986, 650 DOI 10.17487/RFC2986, November 2000, 651 . 653 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 654 Housley, R., and W. Polk, "Internet X.509 Public Key 655 Infrastructure Certificate and Certificate Revocation List 656 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 657 . 659 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 660 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 661 May 2017, . 663 15.2. Informative References 665 [I-D.pala-composite-crypto] 666 Pala, M., "Composite Public Keys and Signatures", draft- 667 pala-composite-crypto-00 (work in progress), February 668 2019. 670 [I-D.truskovsky-lamps-pq-hybrid-x509] 671 Truskovsky, A., Geest, D., Fluhrer, S., Kampanakis, P., 672 Ounsworth, M., and S. Mister, "Multiple Public-Key 673 Algorithm X.509 Certificates", draft-truskovsky-lamps-pq- 674 hybrid-x509-01 (work in progress), August 2018. 676 Authors' Addresses 678 Mike Ounsworth 679 Entrust Datacard Limited 680 1000 Innovation Drive 681 Ottawa, Ontario K2K 1E3 682 Canada 684 Email: mike.ounsworth@entrustdatacard.com 686 Serge Mister 687 Entrust Datacard Limited 689 Email: serge.mister@entrustdatacard.com 691 John Gray 692 Entrust Datacard Limited 694 Email: john.gray@entrustdatacard.com 696 Scott Fluhrer 697 Cisco Systems 699 Email: sfluhrer@cisco.com 701 Panos Kampanakis 702 Cisco Systems 704 Email: pkampana@cisco.com