idnits 2.17.00 (12 Aug 2021) /tmp/idnits41676/draft-ietf-lamps-hash-of-root-key-cert-extn-07.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 (June 29, 2019) is 1050 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Housley 3 Internet-Draft Vigil Security 4 Intended status: Informational June 29, 2019 5 Expires: December 31, 2019 7 Hash Of Root Key Certificate Extension 8 draft-ietf-lamps-hash-of-root-key-cert-extn-07 10 Abstract 12 This document specifies the Hash Of Root Key certificate extension. 13 This certificate extension is carried in the self-signed certificate 14 for a trust anchor, which is often called a Root Certification 15 Authority (CA) certificate. This certificate extension unambiguously 16 identifies the next public key that will be used at some point in the 17 future as the next Root CA certificate, eventually replacing the 18 current one. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 31, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Hash Of Root Key Certificate Extension . . . . . . . . . . . 4 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 5. Operational Considerations . . . . . . . . . . . . . . . . . 4 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 8.2. Informative References . . . . . . . . . . . . . . . . . 9 66 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 9 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 69 1. Introduction 71 This document specifies the Hash Of Root Key X.509 version 3 72 certificate extension. The extension is an optional addition to the 73 Internet X.509 Public Key Infrastructure Certificate and Certificate 74 Revocation List (CRL) Profile [RFC5280]. The certificate extension 75 facilitates the orderly transition from one Root Certification 76 Authority (CA) public key to the next. It does so by publishing the 77 hash value of the next generation public key in the current self- 78 signed certificate. This hash value is a commitment to a particular 79 public key in the next generation self-signed certificate. This 80 commitment allows a relying party to unambiguously recognize the next 81 generation self-signed certificate when it becomes available, install 82 the new self-signed certificate in the trust anchor store, and 83 eventually remove the previous one from the trust anchor store. 85 A Root CA Certificate MAY include the Hashed Root Key certificate 86 extension to provide the hash value of the next public key that will 87 be used by the Root CA. 89 1.1. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in 94 BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 1.2. ASN.1 99 Certificates [RFC5280] use ASN.1 [X680]; Distinguished Encoding Rules 100 (DER) [X690] are REQUIRED for certificate signing and validation. 102 2. Overview 104 Before the initial deployment of the Root CA, the following are 105 generated: 107 R1 = The initial Root key pair 108 R2 = The second generation Root key pair 109 H2 = Thumbprint (hash) of the public key of R2 110 C1 = Self-signed certificate for R1, which also contains H2 112 C1 is a self-signed certificate, and it contains H2 within the 113 HashOfRootKey extension. C1 is distributed as part of the initial 114 the system deployment. The HashOfRootKey certificate extension is 115 described in Section 3. 117 When the time comes to replace the initial Root CA certificate, R1, 118 the following are generated: 120 R3 = The third generation Root key pair 121 H3 = Thumbprint (hash) the public key of R3 122 C2 = Self-signed certificate for R2, which contains H3 124 This is an iterative process. That is, R4 and H4 are generated when 125 it is time for C3 to replace C2. And so on. 127 The successor to the Root CA self-signed certificate can be delivered 128 by any means. Whenever a new Root CA self-signed certificate is 129 received, the recipient is able to verify that the potential Root CA 130 certificate links back to a previously authenticated Root CA 131 certificate with the hashOfRootKey certificate extension. That is, 132 the recipient verifies the signature on the self-signed certificate 133 and verifies that the hash of the DER-encoded SubjectPublicKeyInfo 134 from the potential Root CA certificate matches the value from the 135 HashOfRootKey certificate extension of the current Root CA 136 certificate. Checking the self-signed certificate signature ensures 137 that the certificate contains the subject name, public key algorithm 138 identifier, and public key algorithm parameters intended by the key 139 owner; these are important inputs to certification path validation as 140 defined in Section 6 of [RFC5280]. Checking the hash of the 141 SubjectPublicKeyInfo ensures that the certificate contains the 142 intended public key. If either check fails, then the potential Root 143 CA certificate is not a valid replacement, and the recipient 144 continues to use the current Root CA certificate. If both checks 145 succeed, then the recipient adds the potential Root CA certificate to 146 the trust anchor store. As discussed in Section 5, the recipient can 147 remove the current Root CA certificate immediately in some 148 situations. In other situations, the recipient waits an appropriate 149 amount of time to ensure that existing certification paths continue 150 to validate. 152 3. Hash Of Root Key Certificate Extension 154 The HashOfRootKey certificate extension MUST NOT be critical. 156 The following ASN.1 [X680][X690] syntax defines the HashOfRootKey 157 certificate extension: 159 ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates 160 SYNTAX HashedRootKey 161 IDENTIFIED BY id-ce-hashOfRootKey 162 CRITICALITY {FALSE} } 164 HashedRootKey ::= SEQUENCE { 165 hashAlg HashAlgorithm, -- Hash algorithm used 166 hashValue OCTET STRING } -- Hash of DER-encoded 167 -- SubjectPublicKeyInfo 169 id-ce-hashOfRootKey ::= OBJECT IDENTIFIER { 1 3 6 1 4 1 51483 2 1 } 171 The definitions of EXTENSION and HashAlgorithm can be found in 172 [RFC5912]. 174 The hashAlg indicates the one-way hash algorithm that was used to 175 compute the hash value. 177 The hashValue contains the hash value computed from the next 178 generation public key. The public key is DER-encoded 179 SubjectPublicKeyInfo as defined in [RFC5280]. 181 4. IANA Considerations 183 This document makes no requests of the IANA. 185 5. Operational Considerations 187 Guidance on the transition from one trust anchor to another is 188 available in Section 4.4 of [RFC4210]. In particular, the oldWithNew 189 and newWithOld advice ensures that relying parties are able to 190 validate certificates issued under the current Root CA certificate 191 and the next generation Root CA certificate throughout the 192 transition. The notAfter field in the oldWithNew certificate MUST 193 cover the validity period of all unexpired certificates issued under 194 the old Root CA private key. Further, this advice SHOULD be followed 195 by Root CAs to avoid the need for all relying parties to make the 196 transition at the same time. 198 After issuing the newWithOld certificate, the Root CA MUST stop using 199 the old private key to sign certificates. 201 Some enterprise and application-specific environments offer a 202 directory service or certificate repository to make certificate and 203 CRLs available to relying parties. Section 3 in [RFC5280] describes 204 a certificate repository. When a certificate repository is 205 available, the oldWithNew and newWithOld certificates SHOULD be 206 published before the successor to the current Root CA self-signed 207 certificate is released. Recipients that are able to obtain the 208 oldWithNew certificate SHOULD immediately remove the old Root CA 209 self-signed certificate from the trust anchor store. 211 In environments without such a directory service or repository, like 212 the Web PKI, recipients need a way to obtain the oldWithNew and 213 newWithOld certificates. The Root CA SHOULD include the subject 214 information access extension [RFC5280] with the accessMethod set to 215 id-ad-caRepository and the assessLocation set to the HTTP URL that 216 can be used to fetch a DER-encoded "certs-only" (simple PKI response) 217 message as specified in [RFC5272] in all of their self-signed 218 certificates. The Root CA SHOULD publish the "certs-only" message 219 with the oldWithNew certificate and the newWithOld certificate before 220 the subsequent Root CA self-signed certificate is released. The 221 "certs-only" message format allows certificates to be added and 222 removed from the bag of certificates over time, so the same HTTP URL 223 can be used throughout the lifetime of the Root CA. 225 In environments without such a directory service or repository, 226 recipients SHOULD keep both the old and replacement Root CA self- 227 signed certificates in the trust anchor store for some amount of time 228 to ensure that all end-entity certificates can be validated until 229 they expire. The recipient MAY keep the old Root CA self-signed 230 certificate until all of the certificates in the local cache that are 231 subordinate to it have expired. 233 Certification path construction is more complex when the trust anchor 234 store contains multiple self-signed certificates with the same 235 distinguished name. For this reason, the replacement Root CA self- 236 signed certificate SHOULD contain a different distinguished name than 237 the one it is replacing. One approach is to include a number as part 238 of the name that is incremented with each generation, such as 239 "Example CA", "Example CA G2", "Example CA G3", and so on. 241 Changing names from one generation to another can lead to confusion 242 when reviewing the history of a trust anchor store. To assist with 243 such review, a recipient MAY create an audit entry to capture the old 244 and replacement self-signed certificates. 246 The Root CA must securely back up the yet-to-be-deployed key pair. 247 If the Root CA stores the key pair in a hardware security module, and 248 that module fails, the Root CA remains committed to the key pair that 249 is no longer available. This leaves the Root CA with no alternative 250 but to deploy a new self-signed certificate that contains a newly- 251 generated key pair in the same manner as the initial self-signed 252 certificate, thus losing the benefits of the Hash Of Root Key 253 certificate extension altogether. 255 6. Security Considerations 257 The security considerations from [RFC5280] apply, especially the 258 discussion of self-issued certificates. 260 The Hash Of Root Key certificate extension facilitates the orderly 261 transition from one Root CA public key to the next by publishing the 262 hash value of the next generation public key in the current 263 certificate. This allows a relying party to unambiguously recognize 264 the next generation public key when it becomes available; however, 265 the full public key is not disclosed until the Root CA releases the 266 next generation certificate. In this way, attackers cannot begin to 267 analyze the public key before the next generation Root CA self-signed 268 certificate is released. 270 The Root CA needs to ensure that the public key in the next 271 generation certificate is as strong or stronger than the key that it 272 is replacing. Of course, a significant advance in cryptoanalytic 273 capability can break the yet-to-be-deployed key pair. Such advances 274 are rare and difficult to predict. If such an advance occurs, the 275 Root CA remains committed to the now broken key. This leaves the 276 Root CA with no alternative but to deploy a new self-signed 277 certificate that contains a newly-generated key pair, most likely 278 using a different signature algorithm, in the same manner as the 279 initial self-signed certificate, thus losing the benefits of the Hash 280 Of Root Key certificate extension altogether. 282 The Root CA needs to employ a hash function that is resistant to 283 preimage attacks [RFC4270]. A first-preimage attack against the hash 284 function would allow an attacker to find another input that results 285 published hash value. For the attack to be successful, the input 286 would have to be a valid SubjectPublicKeyInfo that contains a public 287 key that corresponds to a private key known to the attacker. A 288 second-preimage attack becomes possible once the Root CA releases the 289 next generation public key, which makes the input to the hash 290 function available to the attacker and everyone else. Again, the 291 attacker needs to find a valid SubjectPublicKeyInfo that contains the 292 public key that corresponds to a private key known to the attacker. 293 If the employed hash function is broken after the Root CA publishes 294 the self-signed certificate with the HashOfRootKey certificate 295 extension, an attacker would be able to trick the recipient into 296 installing the incorrect next generation certificate in the trust 297 anchor store. 299 If an early release of the next generation public key occurs and the 300 Root CA is concerned that attackers were given too much lead time to 301 analyze that public key, then the Root CA can transition to a freshly 302 generated key pair by rapidly performing two transitions. The first 303 transition takes the Root CA to the key pair that suffered the early 304 release, and it causes the Root CA to generate the subsequent Root 305 key pair. The second transition occurs when the Root CA is confident 306 that the population of relying parties have completed the first 307 transition, and it takes the Root CA to the freshly generated key 308 pair. Of course, the second transition also causes the Root CA to 309 generate another key pair that is reserved for future use. Queries 310 for the CRLs associated with certificates that are subordinate to the 311 self-signed certificate can give some indication for the number of 312 relying parties that are still actively using the self-signed 313 certificates. 315 7. Acknowledgements 317 The Secure Electronic Transaction (SET) [SET] specification published 318 by MasterCard and VISA in 1997 includes a very similar certificate 319 extension. The SET certificate extension has essentially the same 320 semantics, but the syntax fairly different. 322 CTIA - The Wireless Association - is developing a public key 323 infrastructure that will make use of the certificate extension 324 described in this document, and the object identifiers used in the 325 ASN.1 module were assigned by CTIA. 327 Many thanks to Stefan Santesson, Jim Schaad, Daniel Kahn Gillmor, 328 Joel Halpern, Paul Hoffman, Rich Salz, and Ben Kaduk. Their review 329 and comments have greatly improved the document, especially the 330 Operational Considerations and Security Considerations sections. 332 8. References 333 8.1. Normative References 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, 337 DOI 10.17487/RFC2119, March 1997, 338 . 340 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 341 "Internet X.509 Public Key Infrastructure Certificate 342 Management Protocol (CMP)", RFC 4210, 343 DOI 10.17487/RFC4210, September 2005, 344 . 346 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 347 Hashes in Internet Protocols", RFC 4270, 348 DOI 10.17487/RFC4270, November 2005, 349 . 351 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 352 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 353 . 355 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 356 Housley, R., and W. Polk, "Internet X.509 Public Key 357 Infrastructure Certificate and Certificate Revocation List 358 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 359 . 361 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 362 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 363 DOI 10.17487/RFC5912, June 2010, 364 . 366 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 367 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 368 May 2017, . 370 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 371 One (ASN.1): Specification of basic notation", 372 ITU-T Recommendation X.680, 2015. 374 [X690] ITU-T, "Information Technology -- ASN.1 encoding rules: 375 Specification of Basic Encoding Rules (BER), Canonical 376 Encoding Rules (CER) and Distinguished Encoding Rules 377 (DER)", ITU-T Recommendation X.690, 2015. 379 8.2. Informative References 381 [SET] MasterCard and VISA, "SET Secure Electronic Transaction 382 Specification -- Book 2: Programmer's Guide, Version 1.0", 383 May 1997. 385 Appendix A. ASN.1 Module 387 The following ASN.1 module provides the complete definition of the 388 HashOfRootKey certificate extension. 390 HashedRootKeyCertExtn { 1 3 6 1 4 1 51483 0 1 } 392 DEFINITIONS IMPLICIT TAGS ::= 393 BEGIN 395 -- EXPORTS All 397 IMPORTS 399 HashAlgorithm 400 FROM PKIX1-PSS-OAEP-Algorithms-2009 -- [RFC5912] 401 { iso(1) identified-organization(3) dod(6) internet(1) 402 security(5) mechanisms(5) pkix(7) id-mod(0) 403 id-mod-pkix1-rsa-pkalgs-02(54) } 405 EXTENSION 406 FROM PKIX-CommonTypes-2009 407 { iso(1) identified-organization(3) dod(6) internet(1) 408 security(5) mechanisms(5) pkix(7) id-mod(0) 409 id-mod-pkixCommon-02(57) } ; 411 -- 412 -- Expand the certificate extensions list in [RFC5912] 413 -- 415 CertExtensions EXTENSION ::= { 416 ext-HashOfRootKey, ... } 418 -- 419 -- HashOfRootKey Certificate Extension 420 -- 422 ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates 423 SYNTAX HashedRootKey 424 IDENTIFIED BY id-ce-hashOfRootKey 425 CRITICALITY {FALSE} } 427 HashedRootKey ::= SEQUENCE { 428 hashAlg HashAlgorithm, -- Hash algorithm used 429 hashValue OCTET STRING } -- Hash of DER-encoded 430 -- SubjectPublicKeyInfo 432 id-ce-hashOfRootKey OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 51483 2 1 } 434 END 436 Author's Address 438 Russ Housley 439 Vigil Security 440 516 Dranesville Road 441 Herndon, VA 20170 442 US 444 Email: housley@vigilsec.com