idnits 2.17.1 draft-truskovsky-lamps-pq-hybrid-x509-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 29, 2018) is 2067 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 706 -- Looks like a reference, but probably isn't: '1' on line 476 -- Looks like a reference, but probably isn't: '2' on line 478 -- Looks like a reference, but probably isn't: '3' on line 480 ** 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 D. Van Geest 4 Intended status: Standards Track ISARA Corporation 5 Expires: March 2, 2019 S. Fluhrer 6 P. Kampanakis 7 Cisco Systems 8 M. Ounsworth 9 S. Mister 10 Entrust Datacard, Ltd 11 August 29, 2018 13 Multiple Public-Key Algorithm X.509 Certificates 14 draft-truskovsky-lamps-pq-hybrid-x509-01 16 Abstract 18 This document describes a method of embedding alternative sets of 19 cryptographic materials into X.509v3 digital certificates, X.509v2 20 Certificate Revocation Lists (CRLs), and PKCS #10 Certificate Signing 21 Requests (CSRs). The embedded alternative cryptographic materials 22 allow a Public Key Infrastructure (PKI) to use multiple cryptographic 23 algorithms in a single object, and allow it to transition to the new 24 cryptographic algorithms while maintaining backwards compatibility 25 with systems using the existing algorithms. Three X.509 extensions 26 and three PKCS #10 attributes are defined, and the signing and 27 verification procedures for the alternative cryptographic material 28 contained in the extensions and attributes are detailed. 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 March 2, 2019. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Alternative Public-Key Algorithm Objects . . . . . . . . . . 5 68 2.1. OIDs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.2. CSR Attributes . . . . . . . . . . . . . . . . . . . . . 5 70 2.2.1. Subject Alt Public Key Info Attribute . . . . . . . . 5 71 2.2.2. Alt Signature Algorithm Attribute . . . . . . . . . . 5 72 2.2.3. Alt Signature Value Attribute . . . . . . . . . . . . 6 73 2.3. X.509v3 Extensions . . . . . . . . . . . . . . . . . . . 6 74 2.3.1. Subject Alt Public Key Info Extension . . . . . . . . 6 75 2.3.2. Alt Signature Algorithm Extension . . . . . . . . . . 7 76 2.3.3. Alt Signature Value Extension . . . . . . . . . . . . 7 77 3. Multiple Public-Key Algorithm Certificate Signing Requests . 7 78 3.1. Creating Multiple Public-Key Algorithm CSRs . . . . . . . 8 79 3.2. Verifying Multiple Public-Key Algorithm CSRs . . . . . . 9 80 4. Multiple Public-Key Algorithm Certificates . . . . . . . . . 10 81 4.1. Creating Multiple Public-Key Algorithm Certificates . . . 11 82 4.2. Verifying Multiple Public-Key Algorithm Certificates . . 13 83 5. Multiple Public-Key Algorithm Certificate Revocation Lists . 15 84 5.1. Creating Multiple Public-Key Algorithm Certificate 85 Revocation Lists . . . . . . . . . . . . . . . . . . . . 16 86 5.2. Verifying Multiple Public-Key Algorithm Certificate 87 Revocation Lists . . . . . . . . . . . . . . . . . . . . 18 88 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 91 8.1. Post-Quantum Security Considerations . . . . . . . . . . 20 92 9. Normative References . . . . . . . . . . . . . . . . . . . . 21 93 Appendix A. ASN.1 Structures and OIDs . . . . . . . . . . . . . 21 94 Appendix B. Upgrading PKI and Dependent Systems . . . . . . . . 22 95 Appendix C. Options for Alternative Algorithms . . . . . . . . . 23 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 98 1. Introduction 100 Modern Public Key Infrastructure (PKI) extensively relies on 101 classical signature algorithms such as RSA or ECDSA to achieve secure 102 authentication. The security of these algorithms is based on the 103 time-tested difficulty of certain number-theoretic problems. 104 However, it is well known that such schemes offer insufficient 105 security against an adversary in possession of a universal quantum 106 computer. Such an adversary can efficiently recover the private key 107 from the public key and impersonate any entity in the system -- even 108 a root Certification Authority (CA). Hence, it is necessary to 109 upgrade these PKIs to utilize algorithms that are secure against such 110 adversaries. 112 An obvious solution is for relying parties to require multiple 113 certificates to establish trust in an entity. One could 114 theoretically continue to use certificates as they currently are and 115 introduce separate certificates that utilize the new algorithms. 116 However, managing different cryptographic algorithms within a single 117 PKI in this way requires multiple certificate chains. This would 118 greatly increase the complexity of the already complex system. 119 Furthermore, some systems rely on physical solutions for credential 120 storage. These physical solutions may be limited in terms of 121 capacity as well as in terms of how such systems are interacted with. 122 Instead, it is far simpler to keep only a single identity and employ 123 a single certificate chain for each user. 125 The goal of this document is to profile new X.509v3 certificate 126 extensions, X.509v2 CRL extensions and PKCS #10 CSR attributes that 127 facilitate the use of a simple and efficient approach for executing 128 this upgrade. A key design requirement for this approach is to not 129 affect the behavior of non-upgraded systems and ensure they can 130 process any new attributes or extensions without breaking. 132 By placing an alternative public key and alternative signature into 133 custom extensions, one effectively embeds multiple certificate chains 134 within a single chain. By utilizing these multiple public-key 135 algorithm certificates, legacy applications can continue using their 136 current choices of cryptographic algorithms and upgraded applications 137 can use new algorithms while remaining interoperable with the legacy 138 systems. 140 It is useful to observe that even though the motivation for this 141 document is to upgrade PKIs to use quantum-safe cryptography, the 142 same methodology can be used to upgrade such systems to any new 143 algorithm. For this reason, this document does not specify that 144 quantum-safe algorithms are the new technology the PKI is being 145 upgraded to use. 147 The remainder of this document is organized as follows. 149 Section 2 profiles the three new PKCS #10 attributes and three new 150 X.509 extensions. Sections 3, 4 and 5 profile methods for signing 151 and verifying CSRs, certificates and CRLs respectively using the new 152 extensions. 154 1.1. Requirements Language 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 1.2. Terminology 162 The following terms are defined: 164 o alternative algorithm: The algorithm, whose usage is profiled in 165 this document, which can be used to sign and verify a certificate 166 instead of, or in addition to, the conventional algorithm. 168 o alternative [public, private] key: The keys, whose usage is 169 profiled in this document, which can be used to create or verify a 170 signature instead of, or in addition to, the conventional keys. 172 o alternative signature: The signature, whose usage is profiled in 173 this document, which can be used to validate a certificate instead 174 of, or in addition to, the conventional signature. 176 o conventional algorithm: The algorithm specified in the 177 signatureAlgorithm field of an X.509v3 certificate. 179 o conventional [public, private] key: The key used to create or 180 verify a conventional signature in an X.509v3 certificate. 182 o conventional signature: The value specified in the signature field 183 of an X.509v3 certificate. 185 o multiple public-key algorithm certificate: A certificate which is 186 equipped with the extensions introduced in this document. Thus, 187 the certificate is signed and can be verified using two different 188 public-key algorithms. One public-key algorithm (the 189 "conventional" one) uses the keys, signatures and algorithms 190 specified in the standard X.509v3 fields. The other 191 ("alternative") public-key algorithm uses the keys, signatures and 192 algorithms in the extensions defined in this document. 194 o upgraded [application, system]: An application or system which is 195 capable of understanding and using the extensions introduced in 196 this document. 198 2. Alternative Public-Key Algorithm Objects 200 2.1. OIDs 202 The following OIDs are used to identify the CSR attributes and 203 X.509v3 extensions defined in the following sections. 205 id-subjectAltPublicKeyInfo OBJECT IDENTIFIER ::= { TBD } 207 id-altSignatureAlgorithm OBJECT IDENTIFIER ::= { TBD } 209 id-altSignatureValue OBJECT IDENTIFIER ::= { TBD } 211 2.2. CSR Attributes 213 Three new CSR attributes are used to submit an alternative public key 214 for certification. Each of these attributes mirror existing fields 215 within a CSR and serve the same purpose as those fields, but with the 216 alternative algorithms. An entity creating a CSR MUST include either 217 all three of these attributes or none. 219 2.2.1. Subject Alt Public Key Info Attribute 221 The Subject Alt Public Key Info Attribute corresponds to the 222 SubjectPublicKeyInfo type defined in Section 4.1 of [RFC2986]. This 223 attribute carries information about the alternative public key being 224 certified. The information also identifies the entity's alternative 225 public-key algorithm (and any associated parameters). 227 This attribute is identified using the id-subjectAltPublicKeyInfo 228 OID. 230 SubjectAltPublicKeyInfoAttr ATTRIBUTE ::= { 231 WITH SYNTAX SubjectPublicKeyInfo 232 ID id-subjectAltPublicKeyInfo } 234 2.2.2. Alt Signature Algorithm Attribute 236 The Alt Signature Algorithm attribute corresponds to the 237 signatureAlgorithm field of the CertificationRequest type described 238 in Section 4.2 of [RFC2986]. This attribute contains the identifier 239 for the alternative cryptographic algorithm used by the requesting 240 entity to sign the CertificationRequestInfo. 242 This attribute is identified using the id-altSignatureAlgorithm OID. 244 AltSignatureAlgorithmAttr ATTRIBUTE ::= { 245 WITH SYNTAX AlgorithmIdentifier 246 ID id-altSignatureAlgorithm } 248 2.2.3. Alt Signature Value Attribute 250 The Alt Signature Value attribute corresponds to the signature field 251 of the CertificationRequest type described in Section 4.2 of 252 [RFC2986]. This attribute contains a digital signature computed upon 253 the ASN.1 DER encoded PreCertificationRequestInfo as described in 254 Section 3 of this document. 256 By generating this alternative signature, a certification request 257 subject proves possession of the alternative private key. 259 This attribute is identified using the id-altSignatureValue OID. 261 AltSignatureValueAttr ATTRIBUTE ::= { 262 WITH SYNTAX BIT STRING 263 EQUALITY MATCHING RULE bitStringMatch 264 ID id-altSignatureValue } 266 2.3. X.509v3 Extensions 268 Three new X.509v3 extensions are used to authenticate a certificate 269 using alternative algorithms. Each of these extensions mirror 270 existing fields within an X.509v3 certificate and serve the same 271 purpose as those fields, but with the alternative algorithms. 273 2.3.1. Subject Alt Public Key Info Extension 275 The Subject Alt Public Key Info extension corresponds to the Subject 276 Public Key Info field described in Section 4.1.2.7 of [RFC5280]. 277 This extension carries the alternative public key, and identifies the 278 algorithm with which the key is used. 280 This extension is identified using the id-subjectAltPublicKeyInfo 281 OID. 283 SubjectAltPublicKeyInfoExt ::= SEQUENCE { 284 algorithm AlgorithmIdentifier, 285 subjectAltPublicKey BIT STRING } 287 2.3.2. Alt Signature Algorithm Extension 289 The Alt Signature Algorithm extension corresponds to the signature 290 field described in Section 4.1.2.3 of [RFC5280]. It also corresponds 291 to the signatureAlgorithm field described in Section 4.1.1.2 of 292 [RFC5280] since both those fields have the same values. This 293 extension contains the identifier for the alternative digital 294 signature algorithm used by the CA to sign the preTBSCertificate. 296 This extension is identified using the id-altSignatureAlgorithm OID. 298 AltSignatureAlgorithmExt ::= AlgorithmIdentifier 300 2.3.3. Alt Signature Value Extension 302 The Alt Signature Value extension corresponds to the signatureValue 303 field described in Section 4.1.1.3 of [RFC5280]. This extension 304 contains a digital signature computed upon the ASN.1 DER encoded 305 preTBSCertificate as described in Section 4. 307 By generating this alternative signature, a CA certifies the validity 308 of the preTBSCertificate data. In particular, the CA certifies the 309 binding between the alternative public key material and the subject 310 of the certificate. 312 This extension is identified using the id-altSignatureValue OID. 314 AltSignatureValueExt ::= BIT STRING 316 3. Multiple Public-Key Algorithm Certificate Signing Requests 318 A Certificate Signing Request (CSR) is a sequence of three required 319 fields as defined in Section 4.2 of [RFC2986]. 321 CertificationRequest ::= SEQUENCE { 322 certificationRequestInfo CertificationRequestInfo, 323 signatureAlgorithm AlgorithmIdentifier, 324 signature BIT STRING } 326 A CSR's signature is calculated on the ASN.1 DER encoding of the 327 CertificationRequestInfo object as defined in Section 4.2 of 328 [RFC2986]. 330 CertificationRequestInfo ::= SEQUENCE { 331 version INTEGER { v1(0) } (v1,...), 332 subject Name, 333 subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }}, 334 attributes [0] Attributes{{ CRIAttributes }} } 336 The alternative signature is calculated on the ASN.1 DER encoding of 337 the identical PreCertificationRequestInfo object. 339 PreCertificationRequestInfo ::= SEQUENCE { 340 version INTEGER { v1(0) } (v1,...), 341 subject Name, 342 subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }}, 343 attributes [0] Attributes{{ CRIAttributes }} } 345 The PreCertificationRequestInfo type is the same as the 346 CertificationRequestInfo type, however the 347 PreCertificationRequestInfo object will have different attributes 348 than the CertificationRequestInfo. Specifically, the 349 CertificationRequestInfo will include the AltSignatureValueAttr 350 attribute, while the PreCertificationRequestInfo will not. 352 3.1. Creating Multiple Public-Key Algorithm CSRs 354 A multiple public-key algorithm CSR requires the applicant to 355 generate two key pairs: one for the old algorithm (the conventional 356 key pair), and another for the new algorithm (the alternative key 357 pair). All actions taken by the applicant with regards to the 358 conventional algorithm and key pair are unchanged during this 359 process. Additional attributes are populated to prove that the 360 applicant is in possession of the alternative private key. 362 The PreCertificationRequestInfo object MUST contain the 363 SubjectAltPublicKeyInfoAttr attribute carrying the alternative public 364 key and algorithm for the CSR being created. 366 The PreCertificationRequestInfo object MUST contain the 367 AltSignatureAlgorithmAttr attribute, which specifies the algorithm 368 identifier for the algorithm used to sign the 369 PreCertificationRequestInfo object. 371 The alternative signature of the PreCertificationRequestInfo MUST be 372 calculated using the alternative private key of the certificate 373 request subject, which is the private key associated with the public 374 key found in the subject's SubjectAltPublicKeyInfoAttr attribute. 376 After the alternative signature is calculated, the alternative 377 signature MUST be added as an AltSignatureValueAttr attribute to 378 create the CertificationRequestInfo object. 380 The process of signing a multiple public-key algorithm CSR as 381 described above can be summarized as follows: 383 a. Create a PreCertificationRequestInfo object, which is populated 384 with all the data to be signed by the alternative private key, 385 including the SubjectAltPublicKeyInfoAttr and 386 AltSignatureAlgorithmAttr attributes. 388 b. Calculate the alternative signature on the DER encoding of the 389 PreCertificationRequestInfo, using the certificate request 390 subject's alternative private key with the algorithm specified in 391 the AltSignatureAlgorithmAttr attribute. 393 c. Convert the PreCertificationRequestInfo to a 394 CertificationRequestInfo by adding the calculated alternative 395 signature to the PreCertificationRequestInfo object using the 396 AltSignatureValueAttr attribute. 398 d. As per [RFC2986], calculate the conventional signature using the 399 certificate request subject's conventional private key and create 400 the CertificationRequest from the certificationRequestInfo, 401 signatureAlgorithm and signature. 403 An upgraded system MAY issue both multiple public-key algorithm and 404 single public-key algorithm CSRs depending on their policies. If the 405 system issues a single public-key algorithm CSR, then that CSR MUST 406 NOT contain any of the three attributes profiled in this section. 408 3.2. Verifying Multiple Public-Key Algorithm CSRs 410 The certificate issuer verifies the alternative signature of the 411 multiple public-key algorithm CSR by reconstructing the 412 PreCertificationRequestInfo object and using its ASN.1 DER encoding, 413 alternative public key and alternative signature algorithm to verify 414 the signature. 416 To verify the alternative signature of a multiple public-key 417 algorithm CSR, the following steps are taken: 419 a. ASN.1 DER decode the certificationRequestInfo field of the 420 CertificationRequest to get a CertificationRequestInfo object. 422 b. Remove the AltSignatureValueAttr attribute from the 423 CertificationRequestInfo object and set aside the alternative 424 signature. The object is now the same as the 425 PreCertificationRequestInfo which the signature was generated on. 427 c. ASN.1 DER encode the PreCertificationRequestInfo object. 429 d. Using the algorithm specified in the AltSignatureAlgorithmAttr 430 attribute of the PreCertificationRequestInfo, the alternative 431 public key from the CSR's SubjectAltPublicKeyInfoAttr attribute 432 and the ASN.1 DER encoded PreCertificationRequestInfo, verify the 433 alternative signature from (b). 435 During the process of ASN.1 DER decoding the 436 CertificationRequestInfo, removing the AltSignatureValueAttr 437 attribute from the PreCertificationRequestInfo, and ASN.1 DER 438 encoding the PreCertificationRequestInfo, the relative ordering of 439 the remaining attributes is not modified. This is due to the DER 440 encoding rules applied during signature generation as specified in 441 RFC2986. Thus, the resulting ASN.1 DER encoded 442 PreCertificationRequestInfo is identical to the one the issuer used 443 to generate the alternative signature. 445 4. Multiple Public-Key Algorithm Certificates 447 An X.509 digital certificate is a sequence of three fields as defined 448 in [RFC5280]. 450 Certificate ::= SEQUENCE { 451 tbsCertificate TBSCertificate, 452 signatureAlgorithm AlgorithmIdentifier, 453 signatureValue BIT STRING } 455 An X.509v3 certificate's signature is calculated on the ASN.1 DER 456 encoding of the TBSCertificate object as defined in Section 4.1 of 457 [RFC5280]. In this way, a CA certifies the validity of the 458 information in the tbsCertificate field, in particular the binding 459 between the conventional public key material and the subject of the 460 certificate. 462 The alternative signature is calculated on the ASN.1 DER encoding of 463 the similar, but not identical, PreTBSCertificate defined below. 464 This signature also certifies the validity of the information in the 465 tbsCertificate field. In particular, the binding between the 466 alternative public key material and the subject of the certificate is 467 validated. 469 PreTBSCertificate ::= SEQUENCE { 470 version [0] EXPLICIT Version DEFAULT v1, 471 serialNumber CertificateSerialNumber, 472 issuer Name, 473 validity Validity, 474 subject Name, 475 subjectPublicKeyInfo SubjectPublicKeyInfo, 476 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 477 -- If present, version MUST be v2 or v3 478 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 479 -- If present, version MUST be v2 or v3 480 extensions [3] EXPLICIT Extensions OPTIONAL 481 -- If present, version MUST be v3 482 } 484 The PreTBSCertificate type is similar to the TBSCertificate type, 485 except that the PreTBSCertificate does not include the signature 486 field (the third element in the TBSCertificate sequence). In a 487 TBSCertificate the signature field contains the AlgorithmIdentifier 488 of the algorithm which will be used to sign the final certificate, 489 and this value might not be known at the time that the alternative 490 signature is calculated. Additionally, since the AlgorithmIdentifier 491 of the signature field is associated with the final signatureValue 492 field in the certificate, it is outside the scope of the alternative 493 public-key algorithm and does not need to be protected by the 494 alternative signature. 496 The PreTBSCertificate object also does not contain the 497 AltSignatureValueExt extension in its extension list, while the 498 TBSCertificate will. Since the alternative signature is calculated 499 on the encoding of the PreTBSCertificate it cannot be included in the 500 PreTBSCertificate. 502 4.1. Creating Multiple Public-Key Algorithm Certificates 504 If a CA is issuing a subject certificate and the issuer certificate 505 or root of trust contains an alternative public key, then the CA 506 SHOULD add an alternative signature to the subject certificate. 507 Failure to do so could result in a verifier rejecting the certificate 508 as being malformed, especially if the verifier is concerned about 509 quantum-enabled adversaries. This is discussed further in 510 Section 8.1. 512 A multiple public-key algorithm certificate MAY contain the 513 SubjectAltPublicKeyInfoExt extension. If the certificate's subject 514 has an alternative public key which they wish to bind to their 515 identity, then the public key and algorithm MUST be placed in the 516 SubjectAltPublicKeyInfoExt extension. However, if the certificate's 517 subject has no such alternative public key (e.g. the subject's 518 application has not been upgraded to support multiple public-key 519 algorithms) then the SubjectAltPublicKeyInfoExt extension will not be 520 added to the certificate. 522 If a CA is issuing a certificate with an alternative signature, the 523 extensions field of the PreTBSCertificate MUST contain the 524 AltSignatureAlgorithmExt extension, which specifies the algorithm 525 identifier for the algorithm used to sign the PreTBSCertificate. 527 The alternative signature of the PreTBSCertificate MUST be calculated 528 using the alternative private key of the Issuer, which is the private 529 key associated with the public key found in the Issuer's 530 SubjectAltPublicKeyInfoExt extension. 532 After the alternative signature is calculated, the alternative 533 signature MUST be added as an AltSignatureValueExt extension to the 534 extensions list of the PreTBSCertificate, resulting in the 535 TBSCertificate. 537 The process of signing an X.509v3 multiple public-key algorithm 538 certificate as described above can be summarized as follows: 540 a. Create a PreTBSCertificate object, which is populated with all 541 the data to be signed by the alternative private key, including 542 the SubjectAltPublicKeyInfoExt and AltSignatureAlgorithmExt 543 extensions. 545 b. Calculate the alternative signature on the DER encoding of the 546 PreTBSCertificate, using the Issuer's alternative private key 547 with the algorithm specified in the AltSignatureAlgorithmExt 548 extension. 550 c. Add the calculated alternative signature to the PreTBSCertificate 551 object using the AltSignatureValueExt extension. 553 d. Convert the PreTBSCertificate to a TBSCertificate by adding the 554 signature field and populating it with the algorithm identifier 555 of the conventional algorithm to be used to sign the certificate. 557 e. As per [RFC5280], calculate the conventional signature using the 558 conventional private key associated with the Issuer's certificate 559 and create the certificate from the tbsCertificate, 560 signatureAlgorithm and signature. 562 If the upgraded CA's policy allows it to process single public-key 563 algorithm CSRs and issue single public-key algorithm certificates, 564 and the issuer's certificate has an alternative public key, and the 565 CA receives a single-algorithm CSR, the CA SHOULD still include 566 properly calculated AltSignatureValueExt and AltSignatureAlgorithmExt 567 extensions in the certificate. This ensures that when an upgraded 568 system verifies the subject's certificate and sees that the issuer 569 certificate contains the SubjectAltPublicKeyInfoExt extension that it 570 will verify the subject's alternative signature. Otherwise it might 571 treat the subject's certificate as invalid. This is discussed 572 further in the Security Considerations section. 574 Note - A certificate issuer would typically mark the 575 SubjectAltPublicKeyInfoExt, AltSignatureAlgorithmExt and 576 AltSignatureValueExt extensions as non-critical, allowing the 577 multiple public-key algorithm certificate to be treated like a 578 regular certificate by non-upgraded entities. However, the issuer 579 MAY mark the extensions as critical, for example if it is part of a 580 PKI which requires entities to understand both the conventional and 581 alternative signatures. 583 4.2. Verifying Multiple Public-Key Algorithm Certificates 585 Users wishing to verify a multiple public-key algorithm certificate 586 using the alternative public-key algorithm will need to convert the 587 tbsCertificate field in the certificate to a PreTBSCertificate object 588 identical to the PreTBSCertificate object which the issuer used to 589 create the alternative signature. Then the user can use the issuer's 590 alternative public key with the alternative signature algorithm to 591 verify the alternative signature of the PreTBSCertificate. 593 To verify the alternative signature of the multiple public-key 594 algorithm certificate, the following steps are taken: 596 a. ASN.1 DER decode the tbsCertificate field of the certificate to 597 get a TBSCertificate object. 599 b. Remove the AltSignatureValueExt extension from the TBSCertificate 600 object and set aside the alternative signature. 602 c. Remove the signature field from the TBSCertificate object, 603 converting it to a PreTBSCertificate object. 605 d. ASN.1 DER encode the PreTBSCertificate object. 607 e. Using the algorithm specified in the AltSignatureAlgorithmExt 608 extension of the PreTBSCertificate, the alternative public key 609 from the Issuer's SubjectAltPublicKeyInfoExt extension and the 610 ASN.1 DER encoded PreTBSCertificate, verify the alternative 611 signature from (b). 613 The issuer's alternative public key comes from the issuing 614 certificate's SubjectAltPublicKeyInfoExt extension, unless the issuer 615 is a trust anchor. In that case, the trust anchor's alternative 616 public key may come from a self-signed certificate's 617 SubjectAltPublicKeyInfoExt extension, or it may come from elsewhere. 618 [RFC5280] section 6.1.1 (d) lists the trust anchor information as 619 including: 621 a. the trusted issuer name, 623 b. the trusted public key algorithm, 625 c. the trusted public key, and 627 d. optionally, the trusted public key parameters associated with the 628 public key. 630 When validating a multiple public-key algorithm certificate, the 631 trust anchor information also includes: 633 a. the trusted alternative public key algorithm, 635 b. the trusted alternative public key, and 637 c. optionally, the trusted alternative public key parameters 638 associated with the alternative public key. 640 During the process of ASN.1 DER decoding the TBSCertificate, removing 641 the AltSignatureValueExt extension from the PreTBSCertificate and 642 ASN.1 DER encoding the PreTBSCertificate, the relative ordering of 643 the remaining extensions is not modified. Thus, the resulting ASN.1 644 DER encoded PreTBSCertificate is identical to the one the issuer used 645 to generate the alternative signature. 647 A certificate that contains an AltSignatureValueExt extension but 648 does not contain an AltSignatureAlgorithmExt extension cannot be 649 verified under the alternative public-key algorithm and so SHOULD be 650 rejected as being malformed. Similarly, a certificate that contains 651 an AltSignatureAlgorithmExt extension but does not contain an 652 AltSignatureValueExt extension SHOULD be rejected. 654 A certificate MAY have AltSignatureValueExt and 655 AltSignatureAlgorithmExt extensions without having a 656 SubjectAltPublicKeyInfoExt extension. This case could arise if a 657 non-upgraded subject requests a certificate from an upgraded CA who 658 has a multiple public-key algorithm CA certificate. 660 If an issuer certificate or root of trust has an alternative public 661 key, but a subject certificate issued by the issuer certificate or 662 root of trust doesn't contain an alternative signature then the 663 verifier SHOULD reject the subject certificate. This is especially 664 important if the verifier is concerned about quantum-enabled 665 adversaries. This is discussed further in the Section 8.1. 666 Accepting such a subject certificate SHOULD be limited to cases where 667 the verifier has been explicitly configured to ignore missing 668 alternative signatures for a given issuing CA, for subject 669 certificates matching a given wildcard, or similar whitelisting 670 mechanisms. 672 5. Multiple Public-Key Algorithm Certificate Revocation Lists 674 In certain situations, certificates must be revoked and no longer 675 used. This can happen for a variety of reasons including, but not 676 limited to: key compromise, CA compromise, or due to a change in 677 affiliation. Roughly speaking, Certificate Revocation Lists (CRLs) 678 are authenticated lists of revoked certificates. 680 An X.509v2 Certificate Revocation List (CRL) is a sequence of three 681 fields as defined in [RFC5280]. 683 CertificateList ::= SEQUENCE { 684 tbsCertList TBSCertList, 685 signatureAlgorithm AlgorithmIdentifier, 686 signatureValue BIT STRING } 688 An X.509v2 CRL's signature is calculated on the ASN.1 DER encoding of 689 the TBSCertList object as defined in Section 5.1 of [RFC5280]. 691 The alternative signature is calculated on the ASN.1 DER encoding of 692 the similar, but not identical, PreTBSCertList object defined here. 694 PreTBSCertList ::= SEQUENCE { 695 version Version OPTIONAL, 696 -- if present, MUST be v2 697 issuer Name, 698 thisUpdate Time, 699 nextUpdate Time OPTIONAL, 700 revokedCertificates SEQUENCE OF SEQUENCE { 701 userCertificate CertificateSerialNumber, 702 revocationDate Time, 703 crlEntryExtensions Extensions OPTIONAL 704 -- if present, version MUST be v2 705 } OPTIONAL, 706 crlExtensions [0] EXPLICIT Extensions OPTIONAL 707 -- if present, version MUST be v2 708 } 710 The PreTBSCertList object is similar to the TBSCertList object, 711 except that the PreTBSCertList does not include the signature field 712 (the second element in the TBSCertList sequence). In a TBSCertList 713 the signature field contains the AlgorithmIdentifier of the algorithm 714 which will sign the final certificate revocation list, and this value 715 might not be known at the time that the alternative signature is 716 calculated. Additionally, since the AlgorithmIdentifier of the 717 signature field is associated with the final signatureValue field in 718 the CRL, it is outside the scope of the alternative public-key 719 algorithm and does not need to be protected by the alternative 720 signature. 722 The PreTBSCertList object also does not contain the 723 AltSignatureValueExt extension in its extension list, while the 724 TBSCertList will. Since the alternative signature is calculated on 725 the encoding of the PreTBSCertList, it cannot be included in the 726 TBSCertList. 728 If a multiple public-key algorithm certificate is revoked, whether 729 because the classical key is compromised, the alternative key is 730 compromised or or other reason, both the classical and alternative 731 keys SHOULD be considered revoked. This avoids any unneeded 732 complexity in dealing with a certificate where one key is compromised 733 but the other isn't. 735 5.1. Creating Multiple Public-Key Algorithm Certificate Revocation 736 Lists 738 To create a multiple public-key algorithm CRL, one creates a CRL as 739 specified in Section 5 of [RFC5280] and includes the additional 740 extensions as specified in this section. 742 If the CRL issuer's certificate has a SubjectAltPublicKeyInfoExt 743 extension, the CRL SHOULD be created with an alternative signature. 744 Otherwise, some upgraded systems may fail to validate the CRL because 745 it is not trusted under the alternative public-key algorithm. 747 The extensions field of the PreTBSCertList MUST contain the 748 AltSignatureAlgorithmExt extension, which specifies the algorithm 749 identifier for the algorithm used to sign the PreTBSCertList. 751 The alternative signature of the PreTBSCertList MUST be calculated 752 using the alternative private key of the CRL issuer, which is the 753 private key associated with the public key found in the CRL issuer 754 X.509v3 certificate's SubjectAltPublicKeyInfoExt extension. 756 After the alternative signature is calculated, the alternative 757 signature MUST be added as an AltSignatureValueExt extension to the 758 extensions list of the PreTBSCertList, resulting in the TBSCertList. 760 The process of signing an X.509v2 multiple public-key algorithm CRL 761 as described above can be summarized as follows: 763 a. Create a TBSCertList object, which is populated with all the data 764 to be signed by the alternative private key, including the 765 AltSignatureAlgorithmExt extension. 767 b. Calculate the alternative signature on the DER encoding of the 768 PreTBSCertList, using the CRL issuer's alternative private key 769 with the algorithm specified in the AltSignatureAlgorithmExt 770 extension. 772 c. Add the calculated alternative signature to the PreTBSCertList 773 object using the AltSignatureValueExt extension. 775 d. Convert the PreTBSCertList to a TBSCertList by adding the 776 signature field and populating it with the algorithm identifier 777 of the conventional algorithm to be used to sign the certificate. 779 e. As per [RFC5280], calculate the conventional signature using the 780 conventional private key associated with the CRL issuer's 781 certificate and create the CRL from the tbsCertList, 782 signatureAlgorithm and signature. 784 Note - A CRL issuer would typically mark the AltSignatureAlgorithmExt 785 and AltSignatureValueExt extensions as non-critical, allowing the 786 multiple public-key algorithm CRL to be treated like a regular CRL by 787 non-upgraded entities. However, the issuer may be part of a PKI 788 which requires entities to understand both the conventional and 789 alternative signatures, in which case it would mark the extensions as 790 critical. 792 5.2. Verifying Multiple Public-Key Algorithm Certificate Revocation 793 Lists 795 Users wishing to verify the alternative signature of a multiple 796 public-key algorithm CRL will need to convert the tbsCertList field 797 in the CRL to a PreTBSCertList identical to the PreTBSCertList which 798 the issuer used to create the alternative signature. Then the user 799 can use the CRL issuer certificate's alternative public key with the 800 alternative signature algorithm to verify the alternative signature 801 of the PreTBSCertList. 803 To verify the alternative signature of the multiple public-key 804 algorithm CRL, the following steps are taken: 806 a. ASN.1 DER decode the tbsCertList field of the certificate to get 807 a TBSCertList object. 809 b. Remove the AltSignatureValueExt extension from the TBSCertList 810 object and set aside the alternative signature. 812 c. Remove the signature field from the TBSCertList object, 813 converting it to a PreTBSCertList object. 815 d. ASN.1 DER encode the PreTBSCertList object. 817 e. Using the algorithm specified in the AltSignatureAlgorithmExt 818 extension of the PreTBSCertList, the alternative public key from 819 the CRL issuer certificate's SubjectAltPublicKeyInfoExt extension 820 and the ASN.1 DER encoded PreTBSCertList, verify the alternative 821 signature from (b). 823 During the process of ASN.1 DER decoding the TBSCertList, removing 824 the AltSignatureValueExt extension from the PreTBSCertList and ASN.1 825 DER encoding the PreTBSCertList, the relative ordering of the 826 remaining extensions will not be modified. Thus, the resulting ASN.1 827 DER encoded PreTBSCertList is identical to the one the issuer used to 828 generate the alternative signature. 830 In addition to verifying the alternative signature of a CRL, an 831 implementation also needs to validate the CRL issuer's certificate 832 and the certificate chain it is a part of. Implementations SHOULD 833 use the same method as profiled in Section 6 of [RFC5280] with the 834 following modifications to the CRL processing algorithm of that 835 document's Section 6.3.3. Step (f) of the CRL processing algorithm 836 requires certificate path validation for the issuer of the complete 837 CRL. To validate multiple public-key algorithm CRLs, upgraded 838 entities SHOULD additionally verify the alternative signatures along 839 the path as described in Section 4.2 of this document. Step (g) of 840 the CRL Processing algorithm requires the verification of a single 841 signature on the complete CRL. To verify multiple public-key 842 algorithm CRLs, this step MUST be modified to instead verify dual 843 signatures on the complete CRL. Similarly, in step (h) of the same 844 algorithm, if use-deltas is set and if the delta CRL is a multiple 845 public-key algorithm CRL, then the verifying peer should validate the 846 signature on the delta CRL via the method described above, and use 847 standard practice otherwise - using the public key(s) validated in 848 step (f). 850 6. Acknowledgements 852 The authors would like to thank Philip Lafrance and John Gray for 853 their valuable contributions. 855 7. IANA Considerations 857 Extensions in certificates and CRLs are identified using object 858 Identifiers (OIDs). The creation and delegation of these arcs is to 859 be determined. 861 8. Security Considerations 863 Many of the security considerations for this document closely follow 864 those of [RFC5280]. However, the use of the extensions introduced in 865 this document does bring rise to additional considerations. 867 The motivation behind this document is to provide a method of 868 upgrading PKIs and dependent systems to achieve quantum-safe state. 869 However, state-of-the-art quantum-safe signature schemes tend to have 870 large signature or key sizes. As such, their inclusion on CSRs, 871 certificates, or CRLs means that the sizes of these data structures 872 will significantly increase. This could potentially cause problems 873 in protocols or implementations expecting more reasonable sizes. 874 Even if enterprises choose instead to upgrade their PKI to new, but 875 still classically secure signature algorithms, these algorithms can 876 also be expected to have large signature or key sizes; often a by- 877 product of an increased level of security is larger signatures or key 878 sizes. 880 There is a great deal of flexibility inherent to the use of the 881 extensions introduced in this document. Their design is such that a 882 clean separation is made between the old and new signatures. The new 883 signatures have no dependency on the old signatures and no 884 understanding of the new signatures is required to compute or verify 885 the old signature. As such, one could rely on the conventional 886 signature only, the alternative signature only, or both, depending on 887 the policies of the entity. 889 It is paramount that all private keying material be kept secret; a 890 subject covered in the Security Considerations section of [RFC5280]. 891 If the PKI is upgraded to use quantum-safe technologies, then it is 892 of key importance to ensure that all private materials are protected 893 against quantum-enabled adversaries as well. How such a feat is 894 accomplished is outside the scope of this document. Additionally, 895 issues such as re-keying or key management are outside the scope of 896 this document. 898 Typically, the SubjectAltPublicKeyInfoExt, AltSignatureAlgorithmExt 899 and AltSignatureValueExt extensions will be marked as non-critical so 900 that a non-upgraded system could treat a multiple public-key 901 algorithm certificate or CSR as a conventional certificate. However, 902 a PKI could choose to enforce the usage of both conventional and 903 alternative public-key algorithms, in which case it MAY mark these 904 extensions as critical. The reasons why a PKI may want to do this 905 are outside the scope of this document. 907 8.1. Post-Quantum Security Considerations 909 While this document is intended to facilitate transitioning a PKI 910 from a classical public-key algorithm to a quantum-safe public-key 911 algorithm, with the transition completing before the development of 912 quantum computers capable of breaking classical public-key 913 algorithms, it is worth discussing security considerations if 914 multiple public-key algorithm certificates are used in the presence 915 of a quantum-enabled adversary. 917 A quantum-enabled adversary is expected to be able to forge 918 signatures for certificates and CRLs using classically secure 919 signature algorithms. Thus, a CA SHOULD add an alternative signature 920 to any certificate it issues if the issuing certificate contains a 921 SubjectAltPublicKeyInfoExt extension. If the trust anchor is not a 922 certificate, the alternative signature SHOULD be added if the trust 923 anchor has an associated alternative public key which could be used 924 for verification. Similarly, when verifying certificates or CRLs an 925 application SHOULD reject certificates or CRLs if they don't contain 926 an alternative signature but the issuer certificate does contain a 927 SubjectAltPublicKeyInfoExt or the trust anchor has an alternative 928 public key. If the CA does not add the alternative signature in 929 these cases, and an upgraded application does not take this 930 precaution when verifying, then a quantum-enabled adversary could 931 create a certificate or CRL without an alternative signature, and 932 forge the conventional signature of any issuer, causing upgraded 933 applications to accept forged credentials. 935 If an upgraded relying party processing a non-multiple public-key 936 algorithm CRL encounters a multiple public-key algorithm certificate 937 (containing an AltSignatureValueExt extension) in the list of revoked 938 certificates, it SHOULD NOT treat that certificate as revoked. If 939 the conventional signature of the CRL uses a non-quantum-safe 940 signature algorithm (e.g. RSA or ECDSA), a quantum-enabled attacker 941 may have forged the CRL, thereby revoking certificates that the CA 942 didn't intend to revoke. If one of those certificates has the 943 multiple public-key algorithm extension then it was intended to be 944 processed using the alternative public-key algorithm and should not 945 be revoked based on only the results of the conventional public-key 946 algorithm. 948 9. Normative References 950 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 951 Requirement Levels", BCP 14, RFC 2119, 952 DOI 10.17487/RFC2119, March 1997, 953 . 955 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 956 Request Syntax Specification Version 1.7", RFC 2986, 957 DOI 10.17487/RFC2986, November 2000, 958 . 960 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 961 Housley, R., and W. Polk, "Internet X.509 Public Key 962 Infrastructure Certificate and Certificate Revocation List 963 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 964 . 966 Appendix A. ASN.1 Structures and OIDs 968 This appendix includes all of the ASN.1 type and value definitions 969 introduced in this document. 971 DEFINITIONS IMPLICIT TAGS ::= BEGIN 973 -- EXPORTS All -- 974 -- IMPORTS NONE -- 976 -- Object Identifiers for the certificate extensions introduced in 977 -- Section 4. 979 id-subjectAltPublicKeyInfo OBJECT IDENTIFIER ::= { TBD } 981 id-altSignatureAlgorithm OBJECT IDENTIFIER ::= { TBD } 983 id-altSignatureValue OBJECT IDENTIFIER ::= { TBD } 985 -- X.509 Certificate extensions 987 SubjectAltPublicKeyInfoExt ::= SEQUENCE { 988 algorithm AlgorithmIdentifier, 989 subjectAltPublicKey BIT STRING } 991 AltSignatureAlgorithmExt ::= AlgorithmIdentifier 993 AltSignatureValueExt ::= BIT STRING 995 -- attribute data types 997 subjectAltPublicKeyInfoAttr ATTRIBUTE ::= { 998 WITH SYNTAX SubjectPublicKeyInfo 999 ID id-subjectAltPublicKeyInfo } 1001 altSignatureAlgorithmAttr ATTRIBUTE ::= { 1002 WITH SYNTAX AlgorithmIdentifier 1003 ID id-altSignatureAlgorithm } 1005 altSignatureValueAttr ATTRIBUTE ::= { 1006 WITH SYNTAX BIT STRING 1007 EQUALITY MATCHING RULE bitStringMatch 1008 ID id-altSignatureValue } 1010 END 1012 Appendix B. Upgrading PKI and Dependent Systems 1014 One way to upgrade these systems is to employ a "top down" approach: 1015 First the root CA is upgraded, then the same is done for any 1016 subordinate CAs, and finally for end entities. The dependent 1017 applications can then be upgraded in phases, where the upgraded 1018 applications can switch to using the new public-key algorithms while 1019 non-upgraded systems can continue using the old public-key 1020 algorithms. 1022 Appendix C. Options for Alternative Algorithms 1024 Out of all branches of mathematics thought to be suitable for 1025 quantum-safe cryptographic algorithm development, the theory of hash 1026 functions, specifically hash-based signatures are currently the most 1027 trusted in regard to their quantum security assurances. While the 1028 private key state management makes using them challenging in some 1029 high-frequency use cases, they are very well suited for roots of 1030 trust and code signing; hash-based algorithms can already be used to 1031 upgrade CA certificates. Furthermore, the option will be available 1032 to use stateless digital signatures in end-entity certificates when 1033 they become available. 1035 Authors' Addresses 1037 Alexander Truskovsky 1038 ISARA Corporation 1039 560 Westmount Rd N 1040 Waterloo, Ontario N2L 0A9 1041 Canada 1043 Email: alexander.truskovsky@isara.com 1045 Daniel Van Geest 1046 ISARA Corporation 1047 560 Westmount Rd N 1048 Waterloo, Ontario N2L 0A9 1049 Canada 1051 Email: daniel.vangeest@isara.com 1053 Scott Fluhrer 1054 Cisco Systems 1055 170 West Tasman Drive 1056 San Jose, CA 95134 1057 USA 1059 Email: sfluhrer@cisco.com 1060 Panos Kampanakis 1061 Cisco Systems 1062 170 West Tasman Drive 1063 San Jose, CA 95134 1064 USA 1066 Email: pkampana@cisco.com 1068 Mike Ounsworth 1069 Entrust Datacard, Ltd 1070 1000 Innovation Drive 1071 Kanata, Ontario K2K 3E7 1072 Canada 1074 Email: mike.ounsworth@entrustdatacard.com 1076 Serge Mister 1077 Entrust Datacard, Ltd 1078 1000 Innovation Drive 1079 Kanata, Ontario K2K 3E7 1080 Canada 1082 Email: serge.mister@entrustdatacard.com