idnits 2.17.1 draft-ietf-lamps-hash-of-root-key-cert-extn-05.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 31, 2019) is 1912 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 31, 2019 5 Expires: August 4, 2019 7 Hash Of Root Key Certificate Extension 8 draft-ietf-lamps-hash-of-root-key-cert-extn-05 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 August 4, 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 . . . . . . . . . . . . . . . . . . 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 Some enterprise and application-specific environments offer a 203 directory service or certificate repository to make certificate and 204 CRLs available to relying parties. Section 3 in [RFC5280] describes 205 a certificate repository. When a certificate repository is 206 available, the oldWithNew and newWithOld certificates SHOULD be 207 published before the successor to the current Root CA self-signed 208 certificate is released. Recipients that are able to obtain the 209 oldWithNew certificate SHOULD immediately remove the old Root CA 210 self-signed certificate from the trust anchor store. 212 In environments without such a directory service or repository, 213 recipients SHOULD keep both the old and replacement Root CA self- 214 signed certificate in the trust anchor store for some amount of time 215 to ensure that all end-entity certificates can be validated until 216 they expire. The recipient MAY keep the old Root CA self-signed 217 certificate until all of the certificates in the local cache that are 218 subordinate to it have expired. 220 Certification path construction is more complex when multiple self- 221 signed certificates in the trust anchor store have the same 222 distinguished name. For this reason, the replacement Root CA self- 223 signed certificate SHOULD contain a different distinguished name than 224 the one it is replacing. One approach is to include a number as part 225 of the name that is incremented with each generation, such as 226 "Example CA", "Example CA G2", "Example CA G3", and so on. 228 Changing names from one generation to another can lead to confusion 229 when reviewing the history of a trust anchor store. To assist with 230 such review, a recipient MAY create an audit entry to capture the old 231 and replacement self-signed certificates. 233 The Root CA must securely back up the yet-to-be-deployed key pair. 234 If the Root CA stores the key pair in a hardware security module, and 235 that module fails, the Root CA remains committed to the key pair that 236 is no longer available. This leaves the Root CA with no alternative 237 but to deploy a new self-signed certificate that contains a newly- 238 generated key pair in the same manner as the initial self-signed 239 certificate, thus losing the benefits of the Hash Of Root Key 240 certificate extension altogether. 242 6. Security Considerations 244 The security considerations from [RFC5280] apply, especially the 245 discussion of self-issued certificates. 247 The Hash Of Root Key certificate extension facilitates the orderly 248 transition from one Root CA public key to the next by publishing the 249 hash value of the next generation public key in the current 250 certificate. This allows a relying party to unambiguously recognize 251 the next generation public key when it becomes available; however, 252 the full public key is not disclosed until the Root CA releases the 253 next generation certificate. In this way, attackers cannot begin to 254 analyze the public key before the next generation Root CA self-signed 255 certificate is released. 257 The Root CA needs to ensure that the public key in the next 258 generation certificate is as strong or stronger than the key that it 259 is replacing. Of course, a significant advance in cryptoanalytic 260 capability can break the yet-to-be-deployed key pair. Such advances 261 are rare and difficult to predict. If such an advance occurs, the 262 Root CA remains committed to the now broken key. This leaves the 263 Root CA with no alternative but to deploy a new self-signed 264 certificate that contains a newly-generated key pair, most likely 265 using a different signature algorithm, in the same manner as the 266 initial self-signed certificate, thus losing the benefits of the Hash 267 Of Root Key certificate extension altogether. 269 The Root CA needs to employ a hash function that is resistant to 270 preimage attacks [RFC4270]. A first-preimage attack against the hash 271 function would allow an attacker to find another input that results 272 published hash value. For the attack to be successful, the input 273 would have to be a valid SubjectPublicKeyInfo that contains a public 274 key that corresponds to a private key known to the attacker. A 275 second-preimage attack becomes possible once the Root CA releases the 276 next generation public key, which makes the input to the hash 277 function available to the attacker and everyone else. Again, the 278 attacker needs to find a valid SubjectPublicKeyInfo that contains the 279 public key that corresponds to a private key known to the attacker. 281 If an early release of the next generation public key occurs and the 282 Root CA is concerned that attackers were given too much lead time to 283 analyze that public key, then the Root CA can transition to a freshly 284 generated key pair by rapidly performing two transitions. The first 285 transition takes the Root CA to the key pair that suffered the early 286 release, and it causes the Root CA to generate the subsequent Root 287 key pair. The second transition occurs when the Root CA is confident 288 that the population of relying parties have completed the first 289 transition, and it takes the Root CA to the freshly generated key 290 pair. Of course, the second transition also causes the Root CA to 291 generate another key pair that is reserved for future use. 293 7. Acknowledgements 295 The Secure Electronic Transaction (SET) [SET] specification published 296 by MasterCard and VISA in 1997 includes a very similar certificate 297 extension. The SET certificate extension has essentially the same 298 semantics, but the syntax fairly different. 300 CTIA - The Wireless Association is developing a public key 301 infrastructure that will make use of the certificate extension 302 described in this document. 304 Many thanks to Stefan Santesson, Jim Schaad, Daniel Kahn Gillmor, 305 Joel Halpern, Paul Hoffman, and Rich Salz. Their review and comments 306 have greatly improved the document, especially the Operational 307 Considerations and Security Considerations sections. 309 8. References 311 8.1. Normative References 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, 315 DOI 10.17487/RFC2119, March 1997, 316 . 318 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 319 "Internet X.509 Public Key Infrastructure Certificate 320 Management Protocol (CMP)", RFC 4210, 321 DOI 10.17487/RFC4210, September 2005, 322 . 324 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 325 Hashes in Internet Protocols", RFC 4270, 326 DOI 10.17487/RFC4270, November 2005, 327 . 329 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 330 Housley, R., and W. Polk, "Internet X.509 Public Key 331 Infrastructure Certificate and Certificate Revocation List 332 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 333 . 335 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 336 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 337 DOI 10.17487/RFC5912, June 2010, 338 . 340 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 341 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 342 May 2017, . 344 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 345 One (ASN.1): Specification of basic notation", 346 ITU-T Recommendation X.680, 2015. 348 [X690] ITU-T, "Information Technology -- ASN.1 encoding rules: 349 Specification of Basic Encoding Rules (BER), Canonical 350 Encoding Rules (CER) and Distinguished Encoding Rules 351 (DER)", ITU-T Recommendation X.690, 2015. 353 8.2. Informative References 355 [SET] MasterCard and VISA, "SET Secure Electronic Transaction 356 Specification -- Book 2: Programmer's Guide, Version 1.0", 357 May 1997. 359 Appendix A. ASN.1 Module 361 The following ASN.1 module provides the complete definition of the 362 HashOfRootKey certificate extension. 364 HashedRootKeyCertExtn { 1 3 6 1 4 1 51483 0 1 } 366 DEFINITIONS IMPLICIT TAGS ::= 367 BEGIN 369 -- EXPORTS All 371 IMPORTS 373 AlgorithmIdentifier{}, DIGEST-ALGORITHM 374 FROM AlgorithmInformation-2009 -- [RFC5912] 375 { iso(1) identified-organization(3) dod(6) internet(1) 376 security(5) mechanisms(5) pkix(7) id-mod(0) 377 id-mod-algorithmInformation-02(58) } 379 EXTENSION 380 FROM PKIX-CommonTypes-2009 381 { iso(1) identified-organization(3) dod(6) internet(1) 382 security(5) mechanisms(5) pkix(7) id-mod(0) 383 id-mod-pkixCommon-02(57) } ; 385 -- 386 -- Expand the certificate extensions list in [RFC5912] 387 -- 389 CertExtensions EXTENSION ::= { 390 ext-HashOfRootKey, ... } 392 -- 393 -- HashOfRootKey Certificate Extension 394 -- 396 ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates 397 SYNTAX HashedRootKey 398 IDENTIFIED BY id-ce-hashOfRootKey 399 CRITICALITY {FALSE} } 401 HashedRootKey ::= SEQUENCE { 402 hashAlg HashAlgorithmId, -- Hash algorithm used 403 hashValue OCTET STRING } -- Hash of DER-encoded 404 -- SubjectPublicKeyInfo 406 HashAlgorithmId ::= AlgorithmIdentifier {DIGEST-ALGORITHM,{ ... }} 408 id-ce-hashOfRootKey OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 51483 2 1 } 410 END 412 Author's Address 414 Russ Housley 415 Vigil Security 416 516 Dranesville Road 417 Herndon, VA 20170 418 US 420 Email: housley@vigilsec.com