idnits 2.17.00 (12 Aug 2021) /tmp/idnits27966/draft-ietf-lamps-hash-of-root-key-cert-extn-04.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 (January 15, 2019) is 1222 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 January 15, 2019 5 Expires: July 19, 2019 7 Hash Of Root Key Certificate Extension 8 draft-ietf-lamps-hash-of-root-key-cert-extn-04 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 July 19, 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 . . . . . . . . . . . . . . . . . . . 5 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 8.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 8 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 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] are generated using ASN.1 [X680]; certificates 100 are always encoded with the Distinguished Encoding Rules (DER) 101 [X690]. 103 2. Overview 105 Before the initial deployment of the Root CA, the following are 106 generated: 108 R1 = The initial Root key pair 109 R2 = The second generation Root key pair 110 H2 = Thumbprint (hash) of the public key of R2 111 C1 = Self-signed certificate for R1, which also contains H2 113 C1 is a self-signed certificate, and it contains H2 within the 114 HashOfRootKey extension. C1 is distributed as part of the initial 115 the system deployment. The HashOfRootKey certificate extension is 116 described in Section 3. 118 When the time comes to replace the initial Root CA certificate, R1, 119 the following are generated: 121 R3 = The third generation Root key pair 122 H3 = Thumbprint (hash) the public key of R3 123 C2 = Self-signed certificate for R2, which contains H3 125 This is an iterative process. That is, R4 and H4 are generated when 126 it is time for C3 to replace C2. And so on. 128 The successor to the Root CA self-signed certificate can be delivered 129 by any means. Whenever a new Root CA self-signed certificate is 130 received, the recipient is able to verify that the potential Root CA 131 certificate links back to a previously authenticated Root CA 132 certificate with the hashOfRootKey certificate extension. That is, 133 the recipient verifies the signature on the self-signed certificate 134 and verifies that the hash of the DER-encoded SubjectPublicKeyInfo 135 from the potential Root CA certificate matches the value from the 136 HashOfRootKey certificate extension of the current Root CA 137 certificate. Checking the self-signed certificate signature ensures 138 that the certificate contains the subject name, public key algorithm 139 identifier, and public key algorithm parameters intended by the key 140 owner; these are important inputs to certification path validation as 141 defined in Section 6 of [RFC5280]. Checking the hash of the 142 SubjectPublicKeyInfo ensures that the certificate contains the 143 intended public key. If either check fails, then the potential Root 144 CA certificate is not a valid replacement, and the recipient 145 continues to use the current Root CA certificate. If both checks 146 succeed, then the recipient adds the potential Root CA certificate to 147 the trust anchor store. As discussed in Section 5, the recipient can 148 remove the current Root CA certificate immediately in some 149 situations. In other situations, the recipient waits an appropriate 150 amount of time to ensure that existing certification paths continue 151 to validate. 153 3. Hash Of Root Key Certificate Extension 155 The HashOfRootKey certificate extension MUST NOT be critical. 157 The following ASN.1 [X680][X690] syntax defines the HashOfRootKey 158 certificate extension: 160 ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates 161 SYNTAX HashedRootKey 162 IDENTIFIED BY id-ce-hashOfRootKey 163 CRITICALITY {FALSE} } 165 HashedRootKey ::= SEQUENCE { 166 hashAlg AlgorithmIdentifier, -- Hash algorithm used 167 hashValue OCTET STRING } -- Hash of DER-encoded 168 -- SubjectPublicKeyInfo 170 id-ce-hashOfRootKey ::= OBJECT IDENTIFIER { 1 3 6 1 4 1 51483 2 1 } 172 The definitions of EXTENSION and HashAlgorithm can be found in 173 [RFC5912]. 175 The hashAlg indicates the one-way hash algorithm that was used to 176 compute the hash value. 178 The hashValue contains the hash value computed from the next 179 generation public key. The public key is DER-encoded 180 SubjectPublicKeyInfo as defined in [RFC5280]. 182 4. IANA Considerations 184 This document makes no requests of the IANA. 186 5. Operational Considerations 188 Guidance on the transition from one trust anchor to another is 189 available in Section 4.4 of [RFC4210]. In particular, the oldWithNew 190 and newWithOld advice ensures that relying parties are able to 191 validate certificates issued under the current Root CA certificate 192 and the next generation Root CA certificate throughout the 193 transition. The notAfter field in the oldWithNew certificate MUST 194 cover the validity period of all unexpired certificates issued under 195 the old Root CA private key. Further, this advice SHOULD be followed 196 by Root CAs to avoid the need for all relying parties to make the 197 transition at the same time. 199 After issuing the oldWithNew and newWithOld certificates, the Root CA 200 MUST stop using the old private key to sign certificates. 202 In enterprise and application-specific environments where a directory 203 service or certificate repository is available, the oldWithNew and 204 newWithOld certificates SHOULD be published before the successor to 205 the current Root CA self-signed certificate is released. In 206 environments without such a directory service or repository, 207 recipients SHOULD keep both the old and replacement Root CA self- 208 signed certificate in the trust anchor store for some amount of time 209 to ensure that all end-entity certificates can be validated until 210 they expire. The recipient MAY keep the old Root CA self-signed 211 certificate until all of the certificates in the local cache that are 212 subordinate to it have expired. 214 Certification path construction is more complex when multiple self- 215 signed certificates in the trust anchor store have the same 216 distinguished name. For this reason, the replacement Root CA self- 217 signed certificate SHOULD contain a different distinguished name than 218 the one it is replacing. One approach is to include a number as part 219 of the name that is incremented with each generation, such as 220 "Example CA", "Example CA G2", "Example CA G3", and so on. 222 Changing names from one generation to another can lead to confusion 223 when reviewing the history of a trust anchor store. To assist with 224 such review, a recipient MAY create an audit entry to capture the old 225 and replacement self-signed certificates. 227 The Root CA must securely back up the yet-to-be-deployed key pair. 228 If the Root CA stores the key pair in a hardware security module, and 229 that module fails, the Root CA remains committed to the key pair that 230 is no longer available. This leaves the Root CA with no alternative 231 but to deploy a new self-signed certificate that contains a newly- 232 generated key pair in the same manner as the initial self-signed 233 certificate, thus losing the benefits of the Hash Of Root Key 234 certificate extension altogether. 236 6. Security Considerations 238 The security considerations from [RFC5280] apply, especially the 239 discussion of self-issued certificates. 241 The Hash Of Root Key certificate extension facilitates the orderly 242 transition from one Root CA public key to the next by publishing the 243 hash value of the next generation public key in the current 244 certificate. This allows a relying party to unambiguously recognize 245 the next generation public key when it becomes available; however, 246 the full public key is not disclosed until the Root CA releases the 247 next generation certificate. In this way, attackers cannot begin to 248 analyze the public key before the next generation Root CA self-signed 249 certificate is released. 251 The Root CA needs to ensure that the public key in the next 252 generation certificate is as strong or stronger than the key that it 253 is replacing. Of course, a significant advance in cryptoanalytic 254 capability can break the yet-to-be-deployed key pair. Such advances 255 are rare and difficult to predict. If such an advance occurs, the 256 Root CA remains committed to the now broken key. This leaves the 257 Root CA with no alternative but to deploy a new self-signed 258 certificate that contains a newly-generated key pair, most likely 259 using a different signature algorithm, in the same manner as the 260 initial self-signed certificate, thus losing the benefits of the Hash 261 Of Root Key certificate extension altogether. 263 The Root CA needs to employ a hash function that is resistant to 264 preimage attacks [RFC4270]. A first-preimage attack against the hash 265 function would allow an attacker to find another input that results 266 published hash value. For the attack to be successful, the input 267 would have to be a valid SubjectPublicKeyInfo that contains a public 268 key that corresponds to a private key known to the attacker. A 269 second-preimage attack becomes possible once the Root CA releases the 270 next generation public key, which makes the input to the hash 271 function available to the attacker and everyone else. Again, the 272 attacker needs to find a valid SubjectPublicKeyInfo that contains the 273 public key that corresponds to a private key known to the attacker. 275 If an early release of the next generation public key occurs and the 276 Root CA is concerned that attackers were given too much lead time to 277 analyze that public key, then the Root CA can transition to a freshly 278 generated key pair by rapidly performing two transitions. The first 279 transition takes the Root CA to the key pair that suffered the early 280 release, and it causes the Root CA to generate the subsequent Root 281 key pair. The second transition occurs when the Root CA is confident 282 that the population of relying parties have completed the first 283 transition, and it takes the Root CA to the freshly generated key 284 pair. Of course, the second transition also causes the Root CA to 285 generate another key pair that is reserved for future use. 287 7. Acknowledgements 289 The Secure Electronic Transaction (SET) [SET] specification published 290 by MasterCard and VISA in 1997 includes a very similar certificate 291 extension. The SET certificate extension has essentially the same 292 semantics, but the syntax fairly different. 294 CTIA - The Wireless Association is developing a public key 295 infrastructure that will make use of the certificate extension 296 described in this document. 298 Many thanks to Stefan Santesson, Jim Schaad, Daniel Kahn Gillmor, 299 Joel Halpern, Paul Hoffman, and Rich Salz. Their review and comments 300 have greatly improved the document, especially the Operational 301 Considerations and Security Considerations sections. 303 8. References 305 8.1. Normative References 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, 309 DOI 10.17487/RFC2119, March 1997, 310 . 312 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 313 "Internet X.509 Public Key Infrastructure Certificate 314 Management Protocol (CMP)", RFC 4210, 315 DOI 10.17487/RFC4210, September 2005, 316 . 318 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 319 Hashes in Internet Protocols", RFC 4270, 320 DOI 10.17487/RFC4270, November 2005, 321 . 323 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 324 Housley, R., and W. Polk, "Internet X.509 Public Key 325 Infrastructure Certificate and Certificate Revocation List 326 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 327 . 329 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 330 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 331 DOI 10.17487/RFC5912, June 2010, 332 . 334 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 335 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 336 May 2017, . 338 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 339 One (ASN.1): Specification of basic notation", 340 ITU-T Recommendation X.680, 2015. 342 [X690] ITU-T, "Information Technology -- ASN.1 encoding rules: 343 Specification of Basic Encoding Rules (BER), Canonical 344 Encoding Rules (CER) and Distinguished Encoding Rules 345 (DER)", ITU-T Recommendation X.690, 2015. 347 8.2. Informative References 349 [SET] MasterCard and VISA, "SET Secure Electronic Transaction 350 Specification -- Book 2: Programmer's Guide, Version 1.0", 351 May 1997. 353 Appendix A. ASN.1 Module 355 The following ASN.1 module provides the complete definition of the 356 HashOfRootKey certificate extension. 358 HashedRootKeyCertExtn { 1 3 6 1 4 1 51483 0 1 } 360 DEFINITIONS IMPLICIT TAGS ::= 361 BEGIN 363 -- EXPORTS All 365 IMPORTS 367 AlgorithmIdentifier{}, DIGEST-ALGORITHM 368 FROM AlgorithmInformation-2009 -- [RFC5912] 369 { iso(1) identified-organization(3) dod(6) internet(1) 370 security(5) mechanisms(5) pkix(7) id-mod(0) 371 id-mod-algorithmInformation-02(58) } 373 EXTENSION 374 FROM PKIX-CommonTypes-2009 375 { iso(1) identified-organization(3) dod(6) internet(1) 376 security(5) mechanisms(5) pkix(7) id-mod(0) 377 id-mod-pkixCommon-02(57) } ; 379 -- 380 -- Expand the certificate extensions list in [RFC5912] 381 -- 383 CertExtensions EXTENSION ::= { 384 ext-HashOfRootKey, ... } 386 -- 387 -- HashOfRootKey Certificate Extension 388 -- 390 ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates 391 SYNTAX HashedRootKey 392 IDENTIFIED BY id-ce-hashOfRootKey 393 CRITICALITY {FALSE} } 395 HashedRootKey ::= SEQUENCE { 396 hashAlg HashAlgorithmId, -- Hash algorithm used 397 hashValue OCTET STRING } -- Hash of DER-encoded 398 -- SubjectPublicKeyInfo 400 HashAlgorithmId ::= AlgorithmIdentifier {DIGEST-ALGORITHM,{ ... }} 402 id-ce-hashOfRootKey OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 51483 2 1 } 404 END 406 Author's Address 408 Russ Housley 409 Vigil Security 410 516 Dranesville Road 411 Herndon, VA 20170 412 US 414 Email: housley@vigilsec.com