idnits 2.17.1 draft-truskovsky-lamps-pq-hybrid-x509-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 (February 28, 2018) is 2248 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) -- Looks like a reference, but probably isn't: '0' on line 707 -- Looks like a reference, but probably isn't: '1' on line 477 -- Looks like a reference, but probably isn't: '2' on line 479 -- Looks like a reference, but probably isn't: '3' on line 481 ** Downref: Normative reference to an Informational RFC: RFC 2986 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS A. Truskovsky 3 Internet-Draft P. Lafrance 4 Intended status: Standards Track D. Van Geest 5 Expires: September 1, 2018 ISARA Corporation 6 S. Fluhrer 7 P. Kampanakis 8 Cisco Systems 9 M. Ounsworth 10 S. Mister 11 Entrust Datacard, Ltd 12 February 28, 2018 14 Multiple Public-Key Algorithm X.509 Certificates 15 draft-truskovsky-lamps-pq-hybrid-x509-00 17 Abstract 19 This document describes a method of embedding alternative sets of 20 cryptographic materials into X.509v3 digital certificates, X.509v2 21 Certificate Revocation Lists (CRLs), and PKCS #10 Certificate Signing 22 Requests (CSRs). The embedded alternative cryptographic materials 23 allow a Public Key Infrastructure (PKI) to use multiple cryptographic 24 algorithms in a single object, and allow it to transition to the new 25 cryptographic algorithms while maintaining backwards compatibility 26 with systems using the existing algorithms. Three X.509 extensions 27 and three PKCS #10 attributes are defined, and the signing and 28 verification procedures for the alternative cryptographic material 29 contained in the extensions and attributes are detailed. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 1, 2018. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 67 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Alternative Public-Key Algorithm Objects . . . . . . . . . . 5 69 2.1. OIDs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.2. CSR Attributes . . . . . . . . . . . . . . . . . . . . . 5 71 2.2.1. Subject Alt Public Key Info Attribute . . . . . . . . 5 72 2.2.2. Alt Signature Algorithm Attribute . . . . . . . . . . 5 73 2.2.3. Alt Signature Value Attribute . . . . . . . . . . . . 6 74 2.3. X.509v3 Extensions . . . . . . . . . . . . . . . . . . . 6 75 2.3.1. Subject Alt Public Key Info Extension . . . . . . . . 6 76 2.3.2. Alt Signature Algorithm Extension . . . . . . . . . . 7 77 2.3.3. Alt Signature Value Extension . . . . . . . . . . . . 7 78 3. Multiple Public-Key Algorithm Certificate Signing Requests . 7 79 3.1. Creating Multiple Public-Key Algorithm CSRs . . . . . . . 8 80 3.2. Verifying Multiple Public-Key Algorithm CSRs . . . . . . 9 81 4. Multiple Public-Key Algorithm Certificates . . . . . . . . . 10 82 4.1. Creating Multiple Public-Key Algorithm Certificates . . . 11 83 4.2. Verifying Multiple Public-Key Algorithm Certificates . . 13 84 5. Multiple Public-Key Algorithm Certificate Revocation Lists . 15 85 5.1. Creating Multiple Public-Key Algorithm Certificate 86 Revocation Lists . . . . . . . . . . . . . . . . . . . . 16 87 5.2. Verifying Multiple Public-Key Algorithm Certificate 88 Revocation Lists . . . . . . . . . . . . . . . . . . . . 18 89 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 92 8.1. Post-Quantum Security Considerations . . . . . . . . . . 20 93 9. Normative References . . . . . . . . . . . . . . . . . . . . 21 94 Appendix A. ASN.1 Structures and OIDs . . . . . . . . . . . . . 21 95 Appendix B. Upgrading PKI and Dependent Systems . . . . . . . . 22 96 Appendix C. Options for Alternative Algorithms . . . . . . . . . 22 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 99 1. Introduction 101 Modern Public Key Infrastructure (PKI) extensively relies on 102 classical signature algorithms such as RSA or ECDSA to achieve secure 103 authentication. The security of these algorithms is based on the 104 time-tested difficulty of certain number-theoretic problems. 105 However, it is well known that such schemes offer insufficient 106 security against an adversary in possession of a universal quantum 107 computer. Such an adversary can efficiently recover the private key 108 from the public key and impersonate any entity in the system -- even 109 a root Certification Authority (CA). Hence, it is necessary to 110 upgrade these PKIs to utilize algorithms that are secure against such 111 adversaries. 113 An obvious solution is for relying parties to require multiple 114 certificated to establish trust in an entity. One could 115 theoretically continue to use certificates as they currently are and 116 introduce separate certificates that utilize the new algorithms. 117 However, managing different cryptographic algorithms within a single 118 PKI in this way requires multiple certificate chains. This would 119 greatly increase the complexity of the already complex system. 120 Furthermore, some systems rely on physical solutions for credential 121 storage. These physical solutions may be limited in terms of 122 capacity as well as in terms of how such systems are interacted with. 123 Instead, it is far simpler to keep only a single identity and employ 124 a single certificate chain for each user. 126 The goal of this document is to profile new X.509v3 certificate 127 extensions, X.509v2 CRL extensions and PKCS #10 CSR attributes that 128 facilitate the use of a simple and efficient approach for executing 129 this upgrade. A key design requirement for this approach is to not 130 affect the behavior of non-upgraded systems and ensure they can 131 process any new attributes or extensions without breaking. 133 By placing an alternative public key and alternative signature into 134 custom extensions, one effectively embeds multiple certificate chains 135 within a single chain. By utilizing these multiple public-key 136 algorithm certificates, legacy applications can continue using their 137 current choices of cryptographic algorithms and upgraded applications 138 can use new algorithms while remaining interoperable with the legacy 139 systems. 141 It is useful to observe that even though the motivation for this 142 document is to upgrade PKIs to use quantum-safe cryptography, the 143 same methodology can be used to upgrade such systems to any new 144 algorithm. For this reason, this document does not specify that 145 quantum-safe algorithms are the new technology the PKI is being 146 upgraded to use. 148 The remainder of this document is organized as follows. 150 Section 2 profiles the three new PKCS #10 attributes and three new 151 X.509 extensions. Sections 3, 4 and 5 profile methods for signing 152 and verifying CSRs, certificates and CRLs respectively using the new 153 extensions. 155 1.1. Requirements Language 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 1.2. Terminology 163 The following terms are defined: 165 o alternative algorithm: The algorithm, whose usage is profiled in 166 this document, which can be used to sign and verify a certificate 167 instead of, or in addition to, the conventional algorithm. 169 o alternative [public, private] key: The keys, whose usage is 170 profiled in this document, which can be used to create or verify a 171 signature instead of, or in addition to, the conventional keys. 173 o alternative signature: The signature, whose usage is profiled in 174 this document, which can be used to validate a certificate instead 175 of, or in addition to, the conventional signature. 177 o conventional algorithm: The algorithm specified in the 178 signatureAlgorithm field of an X.509v3 certificate. 180 o conventional [public, private] key: The key used to create or 181 verify a conventional signature in an X.509v3 certificate. 183 o conventional signature: The value specified in the signature field 184 of an X.509v3 certificate. 186 o multiple public-key algorithm certificate: A certificate which is 187 equipped with the extensions introduced in this document. Thus, 188 the certificate is signed and can be verified using two different 189 public-key algorithms. One public-key algorithm (the 190 "conventional" one) uses the keys, signatures and algorithms 191 specified in the standard X.509v3 fields. The other 192 ("alternative") public-key algorithm uses the keys, signatures and 193 algorithms in the extensions defined in this document. 195 o upgraded [application, system]: An application or system which is 196 capable of understanding and using the extensions introduced in 197 this document. 199 2. Alternative Public-Key Algorithm Objects 201 2.1. OIDs 203 The following OIDs are used to identify the CSR attributes and 204 X.509v3 extensions defined in the following sections. 206 id-subjectAltPublicKeyInfo OBJECT IDENTIFIER ::= { TBD } 208 id-altSignatureAlgorithm OBJECT IDENTIFIER ::= { TBD } 210 id-altSignatureValue OBJECT IDENTIFIER ::= { TBD } 212 2.2. CSR Attributes 214 Three new CSR attributes are used to submit an alternative public key 215 for certification. Each of these attributes mirror existing fields 216 within a CSR and serve the same purpose as those fields, but with the 217 alternative algorithms. An entity creating a CSR MUST include either 218 all three of these attributes or none. 220 2.2.1. Subject Alt Public Key Info Attribute 222 The Subject Alt Public Key Info Attribute corresponds to the 223 SubjectPublicKeyInfo type defined in Section 4.1 of [RFC2986]. This 224 attribute carries information about the alternative public key being 225 certified. The information also identifies the entity's alternative 226 public-key algorithm (and any associated parameters). 228 This attribute is identified using the id-subjectAltPublicKeyInfo 229 OID. 231 SubjectAltPublicKeyInfoAttr ATTRIBUTE ::= { 232 WITH SYNTAX SubjectPublicKeyInfo 233 ID id-subjectAltPublicKeyInfo } 235 2.2.2. Alt Signature Algorithm Attribute 237 The Alt Signature Algorithm attribute corresponds to the 238 signatureAlgorithm field of the CertificationRequest type described 239 in Section 4.2 of [RFC2986]. This attribute contains the identifier 240 for the alternative cryptographic algorithm used by the requesting 241 entity to sign the CertificationRequestInfo. 243 This attribute is identified using the id-altSignatureAlgorithm OID. 245 AltSignatureAlgorithmAttr ATTRIBUTE ::= { 246 WITH SYNTAX AlgorithmIdentifier 247 ID id-altSignatureAlgorithm } 249 2.2.3. Alt Signature Value Attribute 251 The Alt Signature Value attribute corresponds to the signature field 252 of the CertificationRequest type described in Section 4.2 of 253 [RFC2986]. This attribute contains a digital signature computed upon 254 the ASN.1 DER encoded PreCertificationRequestInfo as described in 255 Section 3 of this document. 257 By generating this alternative signature, a certification request 258 subject proves possession of the alternative private key. 260 This attribute is identified using the id-altSignatureValue OID. 262 AltSignatureValueAttr ATTRIBUTE ::= { 263 WITH SYNTAX BIT STRING 264 EQUALITY MATCHING RULE bitStringMatch 265 ID id-altSignatureValue } 267 2.3. X.509v3 Extensions 269 Three new X.509v3 extensions are used to authenticate a certificate 270 using alternative algorithms. Each of these extensions mirror 271 existing fields within an X.509v3 certificate and serve the same 272 purpose as those fields, but with the alternative algorithms. 274 2.3.1. Subject Alt Public Key Info Extension 276 The Subject Alt Public Key Info extension corresponds to the Subject 277 Public Key Info field described in Section 4.1.2.7 of [RFC5280]. 278 This extension carries the alternative public key, and identifies the 279 algorithm with which the key is used. 281 This extension is identified using the id-subjectAltPublicKeyInfo 282 OID. 284 SubjectAltPublicKeyInfoExt ::= SEQUENCE { 285 algorithm AlgorithmIdentifier, 286 subjectAltPublicKey BIT STRING } 288 2.3.2. Alt Signature Algorithm Extension 290 The Alt Signature Algorithm extension corresponds to the signature 291 field described in Section 4.1.2.3 of [RFC5280]. It also corresponds 292 to the signatureAlgorithm field described in Section 4.1.1.2 of 293 [RFC5280] since both those fields have the same values. This 294 extension contains the identifier for the alternative digital 295 signature algorithm used by the CA to sign the preTBSCertificate. 297 This extension is identified using the id-altSignatureAlgorithm OID. 299 AltSignatureAlgorithmExt ::= AlgorithmIdentifier 301 2.3.3. Alt Signature Value Extension 303 The Alt Signature Value extension corresponds to the signatureValue 304 field described in Section 4.1.1.3 of [RFC5280]. This extension 305 contains a digital signature computed upon the ASN.1 DER encoded 306 preTBSCertificate as described in Section 4. 308 By generating this alternative signature, a CA certifies the validity 309 of the preTBSCertificate data. In particular, the CA certifies the 310 binding between the alternative public key material and the subject 311 of the certificate. 313 This extension is identified using the id-altSignatureValue OID. 315 AltSignatureValueExt ::= BIT STRING 317 3. Multiple Public-Key Algorithm Certificate Signing Requests 319 A Certificate Signing Request (CSR) is a sequence of three required 320 fields as defined in Section 4.2 of [RFC2986]. 322 CertificationRequest ::= SEQUENCE { 323 certificationRequestInfo CertificationRequestInfo, 324 signatureAlgorithm AlgorithmIdentifier, 325 signature BIT STRING } 327 A CSR's signature is calculated on the ASN.1 DER encoding of the 328 CertificationRequestInfo object as defined in Section 4.2 of 329 [RFC2986]. 331 CertificationRequestInfo ::= SEQUENCE { 332 version INTEGER { v1(0) } (v1,...), 333 subject Name, 334 subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }}, 335 attributes [0] Attributes{{ CRIAttributes }} } 337 The alternative signature is calculated on the ASN.1 DER encoding of 338 the identical PreCertificationRequestInfo object. 340 PreCertificationRequestInfo ::= SEQUENCE { 341 version INTEGER { v1(0) } (v1,...), 342 subject Name, 343 subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }}, 344 attributes [0] Attributes{{ CRIAttributes }} } 346 The PreCertificationRequestInfo type is the same as the 347 CertificationRequestInfo type, however the 348 PreCertificationRequestInfo object will have different attributes 349 than the CertificationRequestInfo. Specifically, the 350 CertificationRequestInfo will include the AltSignatureValueAttr 351 attribute, while the PreCertificationRequestInfo will not. 353 3.1. Creating Multiple Public-Key Algorithm CSRs 355 A multiple public-key algorithm CSR requires the applicant to 356 generate two key pairs: one for the old algorithm (the conventional 357 key pair), and another for the new algorithm (the alternative key 358 pair). All actions taken by the applicant with regards to the 359 conventional algorithm and key pair are unchanged during this 360 process. Additional attributes are populated to prove that the 361 applicant is in possession of the alternative private key. 363 The PreCertificationRequestInfo object MUST contain the 364 SubjectAltPublicKeyInfoAttr attribute carrying the alternative public 365 key and algorithm for the CSR being created. 367 The PreCertificationRequestInfo object MUST contain the 368 AltSignatureAlgorithmAttr attribute, which specifies the algorithm 369 identifier for the algorithm used to sign the 370 PreCertificationRequestInfo object. 372 The alternative signature of the PreCertificationRequestInfo MUST be 373 calculated using the alternative private key of the certificate 374 request subject, which is the private key associated with the public 375 key found in the subject's SubjectAltPublicKeyInfoAttr attribute. 377 After the alternative signature is calculated, the alternative 378 signature MUST be added as an AltSignatureValueAttr attribute to 379 create the CertificationRequestInfo object. 381 The process of signing a multiple public-key algorithm CSR as 382 described above can be summarized as follows: 384 a. Create a PreCertificationRequestInfo object, which is populated 385 with all the data to be signed by the alternative private key, 386 including the SubjectAltPublicKeyInfoAttr and 387 AltSignatureAlgorithmAttr attributes. 389 b. Calculate the alternative signature on the DER encoding of the 390 PreCertificationRequestInfo, using the certificate request 391 subject's alternative private key with the algorithm specified in 392 the AltSignatureAlgorithmAttr attribute. 394 c. Convert the PreCertificationRequestInfo to a 395 CertificationRequestInfo by adding the calculated alternative 396 signature to the PreCertificationRequestInfo object using the 397 AltSignatureValueAttr attribute. 399 d. As per [RFC2986], calculate the conventional signature using the 400 certificate request subject's conventional private key and create 401 the CertificationRequest from the certificationRequestInfo, 402 signatureAlgorithm and signature. 404 An upgraded system MAY issue both multiple public-key algorithm and 405 single public-key algorithm CSRs depending on their policies. If the 406 system issues a single public-key algorithm CSR, then that CSR MUST 407 NOT contain any of the three attributes profiled in this section. 409 3.2. Verifying Multiple Public-Key Algorithm CSRs 411 The certificate issuer verifies the alternative signature of the 412 multiple public-key algorithm CSR by reconstructing the 413 PreCertificationRequestInfo object and using its ASN.1 DER encoding, 414 alternative public key and alternative signature algorithm to verify 415 the signature. 417 To verify the alternative signature of a multiple public-key 418 algorithm CSR, the following steps are taken: 420 a. ASN.1 DER decode the certificationRequestInfo field of the 421 CertificationRequest to get a CertificationRequestInfo object. 423 b. Remove the AltSignatureValueAttr attribute from the 424 CertificationRequestInfo object and set aside the alternative 425 signature. The object is now the same as the 426 PreCertificationRequestInfo which the signature was generated on. 428 c. ASN.1 DER encode the PreCertificationRequestInfo object. 430 d. Using the algorithm specified in the AltSignatureAlgorithmAttr 431 attribute of the PreCertificationRequestInfo, the alternative 432 public key from the CSR's SubjectAltPublicKeyInfoAttr attribute 433 and the ASN.1 DER encoded PreCertificationRequestInfo, verify the 434 alternative signature from (b). 436 During the process of ASN.1 DER decoding the 437 CertificationRequestInfo, removing the AltSignatureValueAttr 438 attribute from the PreCertificationRequestInfo, and ASN.1 DER 439 encoding the PreCertificationRequestInfo, the relative ordering of 440 the remaining attributes is not modified. This is due to the DER 441 encoding rules applied during signature generation as specified in 442 RFC2986. Thus, the resulting ASN.1 DER encoded 443 PreCertificationRequestInfo is identical to the one the issuer used 444 to generate the alternative signature. 446 4. Multiple Public-Key Algorithm Certificates 448 An X.509 digital certificate is a sequence of three fields as defined 449 in [RFC5280]. 451 Certificate ::= SEQUENCE { 452 tbsCertificate TBSCertificate, 453 signatureAlgorithm AlgorithmIdentifier, 454 signatureValue BIT STRING } 456 An X.509v3 certificate's signature is calculated on the ASN.1 DER 457 encoding of the TBSCertificate object as defined in Section 4.1 of 458 [RFC5280]. In this way, a CA certifies the validity of the 459 information in the tbsCertificate field, in particular the binding 460 between the conventional public key material and the subject of the 461 certificate. 463 The alternative signature is calculated on the ASN.1 DER encoding of 464 the similar, but not identical, PreTBSCertificate defined below. 465 This signature also certifies the validity of the information in the 466 tbsCertificate field. In particular, the binding between the 467 alternative public key material and the subject of the certificate is 468 validated. 470 PreTBSCertificate ::= SEQUENCE { 471 version [0] EXPLICIT Version DEFAULT v1, 472 serialNumber CertificateSerialNumber, 473 issuer Name, 474 validity Validity, 475 subject Name, 476 subjectPublicKeyInfo SubjectPublicKeyInfo, 477 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 478 -- If present, version MUST be v2 or v3 479 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 480 -- If present, version MUST be v2 or v3 481 extensions [3] EXPLICIT Extensions OPTIONAL 482 -- If present, version MUST be v3 483 } 485 The PreTBSCertificate type is similar to the TBSCertificate type, 486 except that the PreTBSCertificate does not include the signature 487 field (the third element in the TBSCertificate sequence). In a 488 TBSCertificate the signature field contains the AlgorithmIdentifier 489 of the algorithm which will be used to sign the final certificate, 490 and this value might not be known at the time that the alternative 491 signature is calculated. Additionally, since the AlgorithmIdentifier 492 of the signature field is associated with the final signatureValue 493 field in the certificate, it is outside the scope of the alternative 494 public-key algorithm and does not need to be protected by the 495 alternative signature. 497 The PreTBSCertificate object also does not contain the 498 AltSignatureValueExt extension in its extension list, while the 499 TBSCertificate will. Since the alternative signature is calculated 500 on the encoding of the PreTBSCertificate it cannot be included in the 501 PreTBSCertificate. 503 4.1. Creating Multiple Public-Key Algorithm Certificates 505 If a CA is issuing a subject certificate and the issuer certificate 506 or root of trust contains an alternative public key, then the CA 507 SHOULD add an alternative signature to the subject certificate. 508 Failure to do so could result in a verifier rejecting the certificate 509 as being malformed, especially if the verifier is concerned about 510 quantum-enabled adversaries. This is discussed further in 511 Section 8.1. 513 A multiple public-key algorithm certificate MAY contain the 514 SubjectAltPublicKeyInfoExt extension. If the certificate's subject 515 has an alternative public key which they wish to bind to their 516 identity, then the public key and algorithm MUST be placed in the 517 SubjectAltPublicKeyInfoExt extension. However, if the certificate's 518 subject has no such alternative public key (e.g. the subject's 519 application has not been upgraded to support multiple public-key 520 algorithms) then the SubjectAltPublicKeyInfoExt extension will not be 521 added to the certificate. 523 If a CA is issuing a certificate with an alternative signature, the 524 extensions field of the PreTBSCertificate MUST contain the 525 AltSignatureAlgorithmExt extension, which specifies the algorithm 526 identifier for the algorithm used to sign the PreTBSCertificate. 528 The alternative signature of the PreTBSCertificate MUST be calculated 529 using the alternative private key of the Issuer, which is the private 530 key associated with the public key found in the Issuer's 531 SubjectAltPublicKeyInfoExt extension. 533 After the alternative signature is calculated, the alternative 534 signature MUST be added as an AltSignatureValueExt extension to the 535 extensions list of the PreTBSCertificate, resulting in the 536 TBSCertificate. 538 The process of signing an X.509v3 multiple public-key algorithm 539 certificate as described above can be summarized as follows: 541 a. Create a PreTBSCertificate object, which is populated with all 542 the data to be signed by the alternative private key, including 543 the SubjectAltPublicKeyInfoExt and AltSignatureAlgorithmExt 544 extensions. 546 b. Calculate the alternative signature on the DER encoding of the 547 PreTBSCertificate, using the Issuer's alternative private key 548 with the algorithm specified in the AltSignatureAlgorithmExt 549 extension. 551 c. Add the calculated alternative signature to the PreTBSCertificate 552 object using the AltSignatureValueExt extension. 554 d. Convert the PreTBSCertificate to a TBSCertificate by adding the 555 signature field and populating it with the algorithm identifier 556 of the conventional algorithm to be used to sign the certificate. 558 e. As per [RFC5280], calculate the conventional signature using the 559 conventional private key associated with the Issuer's certificate 560 and create the certificate from the tbsCertificate, 561 signatureAlgorithm and signature. 563 If the upgraded CA's policy allows it to process single public-key 564 algorithm CSRs and issue single public-key algorithm certificates, 565 and the issuer's certificate has an alternative public key, and the 566 CA receives a single-algorithm CSR, the CA SHOULD still include 567 properly calculated AltSignatureValueExt and AltSignatureAlgorithmExt 568 extensions in the certificate. This ensures that when an upgraded 569 system verifies the subject's certificate and sees that the issuer 570 certificate contains the SubjectAltPublicKeyInfoExt extension that it 571 will verify the subject's alternative signature. Otherwise it might 572 treat the subject's certificate as invalid. This is discussed 573 further in the Security Considerations section. 575 Note - A certificate issuer would typically mark the 576 SubjectAltPublicKeyInfoExt, AltSignatureAlgorithmExt and 577 AltSignatureValueExt extensions as non-critical, allowing the 578 multiple public-key algorithm certificate to be treated like a 579 regular certificate by non-upgraded entities. However, the issuer 580 MAY mark the extensions as critical, for example if it is part of a 581 PKI which requires entities to understand both the conventional and 582 alternative signatures. 584 4.2. Verifying Multiple Public-Key Algorithm Certificates 586 Users wishing to verify a multiple public-key algorithm certificate 587 using the alternative public-key algorithm will need to convert the 588 tbsCertificate field in the certificate to a PreTBSCertificate object 589 identical to the PreTBSCertificate object which the issuer used to 590 create the alternative signature. Then the user can use the issuer's 591 alternative public key with the alternative signature algorithm to 592 verify the alternative signature of the PreTBSCertificate. 594 To verify the alternative signature of the multiple public-key 595 algorithm certificate, the following steps are taken: 597 a. ASN.1 DER decode the tbsCertificate field of the certificate to 598 get a TBSCertificate object. 600 b. Remove the AltSignatureValueExt extension from the TBSCertificate 601 object and set aside the alternative signature. 603 c. Remove the signature field from the TBSCertificate object, 604 converting it to a PreTBSCertificate object. 606 d. ASN.1 DER encode the PreTBSCertificate object. 608 e. Using the algorithm specified in the AltSignatureAlgorithmExt 609 extension of the PreTBSCertificate, the alternative public key 610 from the Issuer's SubjectAltPublicKeyInfoExt extension and the 611 ASN.1 DER encoded PreTBSCertificate, verify the alternative 612 signature from (b). 614 The issuer's alternative public key comes from the issuing 615 certificate's SubjectAltPublicKeyInfoExt extension, unless the issuer 616 is a trust anchor. In that case, the trust anchor's alternative 617 public key may come from a self-signed certificate's 618 SubjectAltPublicKeyInfoExt extension, or it may come from elsewhere. 619 [RFC5280] section 6.1.1 (d) lists the trust anchor information as 620 including: 622 a. the trusted issuer name, 624 b. the trusted public key algorithm, 626 c. the trusted public key, and 628 d. optionally, the trusted public key parameters associated with the 629 public key. 631 When validating a multiple public-key algorithm certificate, the 632 trust anchor information also includes: 634 a. the trusted alternative public key algorithm, 636 b. the trusted alternative public key, and 638 c. optionally, the trusted alternative public key parameters 639 associated with the alternative public key. 641 During the process of ASN.1 DER decoding the TBSCertificate, removing 642 the AltSignatureValueExt extension from the PreTBSCertificate and 643 ASN.1 DER encoding the PreTBSCertificate, the relative ordering of 644 the remaining extensions is not modified. Thus, the resulting ASN.1 645 DER encoded PreTBSCertificate is identical to the one the issuer used 646 to generate the alternative signature. 648 A certificate that contains an AltSignatureValueExt extension but 649 does not contain an AltSignatureAlgorithmExt extension cannot be 650 verified under the alternative public-key algorithm and so SHOULD be 651 rejected as being malformed. Similarly, a certificate that contains 652 an AltSignatureAlgorithmExt extension but does not contain an 653 AltSignatureValueExt extension SHOULD be rejected. 655 A certificate MAY have AltSignatureValueExt and 656 AltSignatureAlgorithmExt extensions without having a 657 SubjectAltPublicKeyInfoExt extension. This case could arise if a 658 non-upgraded subject requests a certificate from an upgraded CA who 659 has a multiple public-key algorithm CA certificate. 661 If an issuer certificate or root of trust has an alternative public 662 key, but a subject certificate issued by the issuer certificate or 663 root of trust doesn't contain an alternative signature then the 664 verifier SHOULD reject the subject certificate. This is especially 665 important if the verifier is concerned about quantum-enabled 666 adversaries. This is discussed further in the Section 8.1. 667 Accepting such a subject certificate SHOULD be limited to cases where 668 the verifier has been explicitly configured to ignore missing 669 alternative signatures for a given issuing CA, for subject 670 certificates matching a given wildcard, or similar whitelisting 671 mechanisms. 673 5. Multiple Public-Key Algorithm Certificate Revocation Lists 675 In certain situations, certificates must be revoked and no longer 676 used. This can happen for a variety of reasons including, but not 677 limited to: key compromise, CA compromise, or due to a change in 678 affiliation. Roughly speaking, Certificate Revocation Lists (CRLs) 679 are authenticated lists of revoked certificates. 681 An X.509v2 Certificate Revocation List (CRL) is a sequence of three 682 fields as defined in [RFC5280]. 684 CertificateList ::= SEQUENCE { 685 tbsCertList TBSCertList, 686 signatureAlgorithm AlgorithmIdentifier, 687 signatureValue BIT STRING } 689 An X.509v2 CRL's signature is calculated on the ASN.1 DER encoding of 690 the TBSCertList object as defined in Section 5.1 of [RFC5280]. 692 The alternative signature is calculated on the ASN.1 DER encoding of 693 the similar, but not identical, PreTBSCertList object defined here. 695 PreTBSCertList ::= SEQUENCE { 696 version Version OPTIONAL, 697 -- if present, MUST be v2 698 issuer Name, 699 thisUpdate Time, 700 nextUpdate Time OPTIONAL, 701 revokedCertificates SEQUENCE OF SEQUENCE { 702 userCertificate CertificateSerialNumber, 703 revocationDate Time, 704 crlEntryExtensions Extensions OPTIONAL 705 -- if present, version MUST be v2 706 } OPTIONAL, 707 crlExtensions [0] EXPLICIT Extensions OPTIONAL 708 -- if present, version MUST be v2 709 } 711 The PreTBSCertList object is similar to the TBSCertList object, 712 except that the PreTBSCertList does not include the signature field 713 (the second element in the TBSCertList sequence). In a TBSCertList 714 the signature field contains the AlgorithmIdentifier of the algorithm 715 which will sign the final certificate revocation list, and this value 716 might not be known at the time that the alternative signature is 717 calculated. Additionally, since the AlgorithmIdentifier of the 718 signature field is associated with the final signatureValue field in 719 the CRL, it is outside the scope of the alternative public-key 720 algorithm and does not need to be protected by the alternative 721 signature. 723 The PreTBSCertList object also does not contain the 724 AltSignatureValueExt extension in its extension list, while the 725 TBSCertList will. Since the alternative signature is calculated on 726 the encoding of the PreTBSCertList, it cannot be included in the 727 TBSCertList. 729 If a multiple public-key algorithm certificate is revoked, whether 730 because the classical key is compromised, the alternative key is 731 compromised or or other reason, both the classical and alternative 732 keys SHOULD be considered revoked. This avoids any unneeded 733 complexity in dealing with a certificate where one key is compromised 734 but the other isn't. 736 5.1. Creating Multiple Public-Key Algorithm Certificate Revocation 737 Lists 739 To create a multiple public-key algorithm CRL, one creates a CRL as 740 specified in Section 5 of [RFC5280] and includes the additional 741 extensions as specified in this section. 743 If the CRL issuer's certificate has a SubjectAltPublicKeyInfoExt 744 extension, the CRL SHOULD be created with an alternative signature. 745 Otherwise, some upgraded systems may fail to validate the CRL because 746 it is not trusted under the alternative public-key algorithm. 748 The extensions field of the PreTBSCertList MUST contain the 749 AltSignatureAlgorithmExt extension, which specifies the algorithm 750 identifier for the algorithm used to sign the PreTBSCertList. 752 The alternative signature of the PreTBSCertList MUST be calculated 753 using the alternative private key of the CRL issuer, which is the 754 private key associated with the public key found in the CRL issuer 755 X.509v3 certificate's SubjectAltPublicKeyInfoExt extension. 757 After the alternative signature is calculated, the alternative 758 signature MUST be added as an AltSignatureValueExt extension to the 759 extensions list of the PreTBSCertList, resulting in the TBSCertList. 761 The process of signing an X.509v2 multiple public-key algorithm CRL 762 as described above can be summarized as follows: 764 a. Create a TBSCertList object, which is populated with all the data 765 to be signed by the alternative private key, including the 766 AltSignatureAlgorithmExt extension. 768 b. Calculate the alternative signature on the DER encoding of the 769 PreTBSCertList, using the CRL issuer's alternative private key 770 with the algorithm specified in the AltSignatureAlgorithmExt 771 extension. 773 c. Add the calculated alternative signature to the PreTBSCertList 774 object using the AltSignatureValueExt extension. 776 d. Convert the PreTBSCertList to a TBSCertList by adding the 777 signature field and populating it with the algorithm identifier 778 of the conventional algorithm to be used to sign the certificate. 780 e. As per [RFC5280], calculate the conventional signature using the 781 conventional private key associated with the CRL issuer's 782 certificate and create the CRL from the tbsCertList, 783 signatureAlgorithm and signature. 785 Note - A CRL issuer would typically mark the AltSignatureAlgorithmExt 786 and AltSignatureValueExt extensions as non-critical, allowing the 787 multiple public-key algorithm CRL to be treated like a regular CRL by 788 non-upgraded entities. However, the issuer may be part of a PKI 789 which requires entities to understand both the conventional and 790 alternative signatures, in which case it would mark the extensions as 791 critical. 793 5.2. Verifying Multiple Public-Key Algorithm Certificate Revocation 794 Lists 796 Users wishing to verify the alternative signature of a multiple 797 public-key algorithm CRL will need to convert the tbsCertList field 798 in the CRL to a PreTBSCertList identical to the PreTBSCertList which 799 the issuer used to create the alternative signature. Then the user 800 can use the CRL issuer certificate's alternative public key with the 801 alternative signature algorithm to verify the alternative signature 802 of the PreTBSCertList. 804 To verify the alternative signature of the multiple public-key 805 algorithm CRL, the following steps are taken: 807 a. ASN.1 DER decode the tbsCertList field of the certificate to get 808 a TBSCertList object. 810 b. Remove the AltSignatureValueExt extension from the TBSCertList 811 object and set aside the alternative signature. 813 c. Remove the signature field from the TBSCertList object, 814 converting it to a PreTBSCertList object. 816 d. ASN.1 DER encode the PreTBSCertList object. 818 e. Using the algorithm specified in the AltSignatureAlgorithmExt 819 extension of the PreTBSCertList, the alternative public key from 820 the CRL issuer certificate's SubjectAltPublicKeyInfoExt extension 821 and the ASN.1 DER encoded PreTBSCertList, verify the alternative 822 signature from (b). 824 During the process of ASN.1 DER decoding the TBSCertList, removing 825 the AltSignatureValueExt extension from the PreTBSCertList and ASN.1 826 DER encoding the PreTBSCertList, the relative ordering of the 827 remaining extensions will not be modified. Thus, the resulting ASN.1 828 DER encoded PreTBSCertList is identical to the one the issuer used to 829 generate the alternative signature. 831 In addition to verifying the alternative signature of a CRL, an 832 implementation also needs to validate the CRL issuer's certificate 833 and the certificate chain it is a part of. Implementations SHOULD 834 use the same method as profiled in Section 6 of [RFC5280] with the 835 following modifications to the CRL processing algorithm of that 836 document's Section 6.3.3. Step (f) of the CRL processing algorithm 837 requires certificate path validation for the issuer of the complete 838 CRL. To validate multiple public-key algorithm CRLs, upgraded 839 entities SHOULD additionally verify the alternative signatures along 840 the path as described in Section 4.2 of this document. Step (g) of 841 the CRL Processing algorithm requires the verification of a single 842 signature on the complete CRL. To verify multiple public-key 843 algorithm CRLs, this step MUST be modified to instead verify dual 844 signatures on the complete CRL. Similarly, in step (h) of the same 845 algorithm, if use-deltas is set and if the delta CRL is a multiple 846 public-key algorithm CRL, then the verifying peer should validate the 847 signature on the delta CRL via the method described above, and use 848 standard practice otherwise - using the public key(s) validated in 849 step (f). 851 6. Acknowledgements 853 7. IANA Considerations 855 Extensions in certificates and CRLs are identified using object 856 Identifiers (OIDs). The creation and delegation of these arcs is to 857 be determined. 859 8. Security Considerations 861 Many of the security considerations for this document closely follow 862 those of [RFC5280]. However, the use of the extensions introduced in 863 this document does bring rise to additional considerations. 865 The motivation behind this document is to provide a method of 866 upgrading PKIs and dependent systems to achieve quantum-safe state. 867 However, state-of-the-art quantum-safe signature schemes tend to have 868 large signature or key sizes. As such, their inclusion on CSRs, 869 certificates, or CRLs means that the sizes of these data structures 870 will significantly increase. This could potentially cause problems 871 in protocols or implementations expecting more reasonable sizes. 872 Even if enterprises choose instead to upgrade their PKI to new, but 873 still classically secure signature algorithms, these algorithms can 874 also be expected to have large signature or key sizes; often a by- 875 product of an increased level of security is larger signatures or key 876 sizes. 878 There is a great deal of flexibility inherent to the use of the 879 extensions introduced in this document. Their design is such that a 880 clean separation is made between the old and new signatures. The new 881 signatures have no dependency on the old signatures and no 882 understanding of the new signatures is required to compute or verify 883 the old signature. As such, one could rely on the conventional 884 signature only, the alternative signature only, or both, depending on 885 the policies of the entity. 887 It is paramount that all private keying material be kept secret; a 888 subject covered in the Security Considerations section of [RFC5280]. 889 If the PKI is upgraded to use quantum-safe technologies, then it is 890 of key importance to ensure that all private materials are protected 891 against quantum-enabled adversaries as well. How such a feat is 892 accomplished is outside the scope of this document. Additionally, 893 issues such as re-keying or key management are outside the scope of 894 this document. 896 Typically, the SubjectAltPublicKeyInfoExt, AltSignatureAlgorithmExt 897 and AltSignatureValueExt extensions will be marked as non-critical so 898 that a non-upgraded system could treat a multiple public-key 899 algorithm certificate or CSR as a conventional certificate. However, 900 a PKI could choose to enforce the usage of both conventional and 901 alternative public-key algorithms, in which case it MAY mark these 902 extensions as critical. The reasons why a PKI may want to do this 903 are outside the scope of this document. 905 8.1. Post-Quantum Security Considerations 907 While this document is intended to facilitate transitioning a PKI 908 from a classical public-key algorithm to a quantum-safe public-key 909 algorithm, with the transition completing before the development of 910 quantum computers capable of breaking classical public-key 911 algorithms, it is worth discussing security considerations if 912 multiple public-key algorithm certificates are used in the presence 913 of a quantum-enabled adversary. 915 A quantum-enabled adversary is expected to be able to forge 916 signatures for certificates and CRLs using classically secure 917 signature algorithms. Thus, a CA SHOULD add an alternative signature 918 to any certificate it issues if the issuing certificate contains a 919 SubjectAltPublicKeyInfoExt extension. If the trust anchor is not a 920 certificate, the alternative signature SHOULD be added if the trust 921 anchor has an associated alternative public key which could be used 922 for verification. Similarly, when verifying certificates or CRLs an 923 application SHOULD reject certificates or CRLs if they don't contain 924 an alternative signature but the issuer certificate does contain a 925 SubjectAltPublicKeyInfoExt or the trust anchor has an alternative 926 public key. If the CA does not add the alternative signature in 927 these cases, and an upgraded application does not take this 928 precaution when verifying, then a quantum-enabled adversary could 929 create a certificate or CRL without an alternative signature, and 930 forge the conventional signature of any issuer, causing upgraded 931 applications to accept forged credentials. 933 If an upgraded relying party processing a non-multiple public-key 934 algorithm CRL encounters a multiple public-key algorithm certificate 935 (containing an AltSignatureValueExt extension) in the list of revoked 936 certificates, it SHOULD NOT treat that certificate as revoked. If 937 the conventional signature of the CRL uses a non-quantum-safe 938 signature algorithm (e.g. RSA or ECDSA), a quantum-enabled attacker 939 may have forged the CRL, thereby revoking certificates that the CA 940 didn't intend to revoke. If one of those certificates has the 941 multiple public-key algorithm extension then it was intended to be 942 processed using the alternative public-key algorithm and should not 943 be revoked based on only the results of the conventional public-key 944 algorithm. 946 9. Normative References 948 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 949 Requirement Levels", BCP 14, RFC 2119, 950 DOI 10.17487/RFC2119, March 1997, 951 . 953 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 954 Request Syntax Specification Version 1.7", RFC 2986, 955 DOI 10.17487/RFC2986, November 2000, 956 . 958 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 959 Housley, R., and W. Polk, "Internet X.509 Public Key 960 Infrastructure Certificate and Certificate Revocation List 961 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 962 . 964 Appendix A. ASN.1 Structures and OIDs 966 This appendix includes all of the ASN.1 type and value definitions 967 introduced in this document. 969 DEFINITIONS IMPLICIT TAGS ::= BEGIN 971 -- EXPORTS All -- 972 -- IMPORTS NONE -- 974 -- Object Identifiers for the certificate extensions introduced in 975 -- Section 4. 977 id-subjectAltPublicKeyInfo OBJECT IDENTIFIER ::= { TBD } 979 id-altSignatureAlgorithm OBJECT IDENTIFIER ::= { TBD } 981 id-altSignatureValue OBJECT IDENTIFIER ::= { TBD } 982 -- X.509 Certificate extensions 984 SubjectAltPublicKeyInfoExt ::= SEQUENCE { 985 algorithm AlgorithmIdentifier, 986 subjectAltPublicKey BIT STRING } 988 AltSignatureAlgorithmExt ::= AlgorithmIdentifier 990 AltSignatureValueExt ::= BIT STRING 992 -- attribute data types 994 subjectAltPublicKeyInfoAttr ATTRIBUTE ::= { 995 WITH SYNTAX SubjectPublicKeyInfo 996 ID id-subjectAltPublicKeyInfo } 998 altSignatureAlgorithmAttr ATTRIBUTE ::= { 999 WITH SYNTAX AlgorithmIdentifier 1000 ID id-altSignatureAlgorithm } 1002 altSignatureValueAttr ATTRIBUTE ::= { 1003 WITH SYNTAX BIT STRING 1004 EQUALITY MATCHING RULE bitStringMatch 1005 ID id-altSignatureValue } 1007 END 1009 Appendix B. Upgrading PKI and Dependent Systems 1011 One way to upgrade these systems is to employ a "top down" approach: 1012 First the root CA is upgraded, then the same is done for any 1013 subordinate CAs, and finally for end entities. The dependent 1014 applications can then be upgraded in phases, where the upgraded 1015 applications can switch to using the new public-key algorithms while 1016 non-upgraded systems can continue using the old public-key 1017 algorithms. 1019 Appendix C. Options for Alternative Algorithms 1021 Out of all branches of mathematics thought to be suitable for 1022 quantum-safe cryptographic algorithm development, the theory of hash 1023 functions, specifically hash-based signatures are currently the most 1024 trusted in regard to their quantum security assurances. While the 1025 private key state management makes using them challenging in some 1026 high-frequency use cases, they are very well suited for roots of 1027 trust and code signing; hash-based algorithms can already be used to 1028 upgrade CA certificates. Furthermore, the option will be available 1029 to use stateless digital signatures in end-entity certificates when 1030 they become available. 1032 Authors' Addresses 1034 Alexander Truskovsky 1035 ISARA Corporation 1036 560 Westmount Rd N 1037 Waterloo, Ontario N2L 2Y6 1038 Canada 1040 Email: alexander.truskovsky@isara.com 1042 Philip Lafrance 1043 ISARA Corporation 1044 560 Westmount Rd N 1045 Waterloo, Ontario N2L 0A9 1046 Canada 1048 Email: philip.lafrance@isara.com 1050 Daniel Van Geest 1051 ISARA Corporation 1052 560 Westmount Rd N 1053 Waterloo, Ontario N2L 0A9 1054 Canada 1056 Email: daniel.vangeest@isara.com 1058 Scott Fluhrer 1059 Cisco Systems 1060 170 West Tasman Drive 1061 San Jose, CA 95134 1062 USA 1064 Email: sfluhrer@cisco.com 1066 Panos Kampanakis 1067 Cisco Systems 1068 170 West Tasman Drive 1069 San Jose, CA 95134 1070 USA 1072 Email: pkampana@cisco.com 1073 Mike Ounsworth 1074 Entrust Datacard, Ltd 1075 1000 Innovation Drive 1076 Kanata, Ontario K2K 3E7 1077 Canada 1079 Email: mike.ounsworth@entrustdatacard.com 1081 Serge Mister 1082 Entrust Datacard, Ltd 1083 1000 Innovation Drive 1084 Kanata, Ontario K2K 3E7 1085 Canada 1087 Email: serge.mister@entrustdatacard.com