idnits 2.17.1 draft-ietf-lamps-hash-of-root-key-cert-extn-03.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 03, 2019) is 1938 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2510 (Obsoleted by RFC 4210) Summary: 1 error (**), 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 03, 2019 5 Expires: July 7, 2019 7 Hash Of Root Key Certificate Extension 8 draft-ietf-lamps-hash-of-root-key-cert-extn-03 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, replacing the current one. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 7, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Hash Of Root Key Certificate Extension . . . . . . . . . . . 4 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 5. Operational Considerations . . . . . . . . . . . . . . . . . 4 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 8.2. Informative References . . . . . . . . . . . . . . . . . 7 65 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 7 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 This document specifies the Hash Of Root Key X.509 version 3 71 certificate extension. The extension is an optional addition to the 72 Internet X.509 Public Key Infrastructure Certificate and Certificate 73 Revocation List (CRL) Profile [RFC5280]. The certificate extension 74 facilitates the orderly transition from one Root Certification 75 Authority (CA) public key to the next. It does so by publishing the 76 hash value of the next generation public key in the current self- 77 signed certificate. This hash value is a commitment to a particular 78 public key in the next generation self-signed certificate. This 79 commitment allows a relying party to unambiguously recognize the next 80 generation self-signed certificate when it becomes available, install 81 the new self-signed certificate in the trust anchor store, and remove 82 the previous one from the trust anchor store. 84 A Root CA Certificate MAY include the Hashed Root Key certificate 85 extension to provide the hash value of the next public key that will 86 be used by the Root CA. 88 1.1. Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 92 "OPTIONAL" in this document are to be interpreted as described in 93 BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all 94 capitals, as shown here. 96 1.2. ASN.1 98 Certificates [RFC5280] are generated using ASN.1 [X680]; certificates 99 are always encoded with the Distinguished Encoding Rules (DER) 100 [X690]. 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 certificate is received, the 129 recipient is able to verify that the potential Root CA certificate 130 links back to a previously authenticated Root CA certificate with the 131 hashOfRootKey certificate extension. That is, the recipient verifies 132 the signature on the self-signed certificate and verifies that the 133 hash of the DER-encoded SubjectPublicKeyInfo from the potential Root 134 CA certificate matches the value from the HashOfRootKey certificate 135 extension of the current Root CA certificate. Checking the self- 136 signed certificate signature ensures that the certificate contains 137 the subject name, public key algorithm identifier, and public key 138 algorithm parameters intended by the key owner intends; these are 139 important inputs to certification path validation as defined in 140 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 potential Root CA 143 certificate is not a valid replacement, and the recipient continues 144 to use the current Root CA certificate. 146 3. Hash Of Root Key Certificate Extension 148 The HashOfRootKey certificate extension MUST NOT be critical. 150 The following ASN.1 [X680][X690] syntax defines the HashOfRootKey 151 certificate extension: 153 ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates 154 SYNTAX HashedRootKey 155 IDENTIFIED BY id-ce-hashOfRootKey 156 CRITICALITY {FALSE} } 158 HashedRootKey ::= SEQUENCE { 159 hashAlg AlgorithmIdentifier, -- Hash algorithm used 160 hashValue OCTET STRING } -- Hash of DER-encoded 161 -- SubjectPublicKeyInfo 163 id-ce-hashOfRootKey ::= OBJECT IDENTIFIER { 1 3 6 1 4 1 51483 2 1 } 165 The definitions of EXTENSION and HashAlgorithm can be found in 166 [RFC5912]. 168 The hashAlg indicates the one-way hash algorithm that was used to 169 compute the hash value. 171 The hashValue contains the hash value computed from the next 172 generation public key. The public key is DER-encoded 173 SubjectPublicKeyInfo as defined in [RFC5280]. 175 4. IANA Considerations 177 This document makes no requests of the IANA. 179 5. Operational Considerations 181 Guidance on the transition from one trust anchor to another is 182 available in [RFC2510]. In particular, the oldWithNew and newWithOld 183 advice ensures that relying parties are able to validate certificates 184 issued under the current Root CA certificate and the next generation 185 Root CA certificate throughout the transition. Further, this 186 technique avoids the need for all relying parties to make the 187 transition at the same time. 189 The Root CA must securely back up the yet-to-be-deployed key pair. 190 If the Root CA stores the key pair in a hardware security module, and 191 that module fails, the Root CA remains committed to the now 192 unavailable key pair. The remedy is to deploy a new self-signed 193 certificate that contains a newly-generated key pair in the same 194 manner as the initial self-signed certificate, thus loosing the 195 benefits of the Hash Of Root Key certificate extension altogether. 197 6. Security Considerations 199 The security considerations from [RFC5280] apply, especially the 200 discussion of self-issued certificates. 202 The Hash Of Root Key certificate extension facilitates the orderly 203 transition from one Root CA public key to the next by publishing the 204 hash value of the next generation public key in the current 205 certificate. This allows a relying party to unambiguously recognize 206 the next generation public key when it becomes available; however, 207 the full public key is not disclosed until the Root CA releases the 208 next generation certificate. In this way, attackers cannot begin to 209 analyze the public key before the next generation Root CA self-signed 210 certificate is released. 212 The Root CA needs to ensure that the public key in the next 213 generation certificate is as strong or stronger than the key that it 214 is replacing. Of course, a significant advance in cryptoanalytic 215 capability can break the yet-to-be-deployed key pair. Such advances 216 are rare and difficult to predict. If such an advance occurs, the 217 Root CA remains committed to the now broken key. The remedy is to 218 deploy a new public key and algorithm in the same manner as the 219 initial Root CA self-signed certificate, thus loosing the benefits of 220 the Hash Of Root Key certificate extension altogether. 222 The Root CA needs to employ a hash function that is resistant to 223 preimage attacks [RFC4270]. A first-preimage attack against the hash 224 function would allow an attacker to find another input that results 225 published hash value. For the attack to be successful, the input 226 would have to be a valid SubjectPublicKeyInfo that contains the 227 public key that corresponds to a private key known to the attacker. 228 A second-preimage attack becomes possible once the Root CA releases 229 the next generation public key, which makes the input to the hash 230 function becomes available to the attacker and everyone else. Again, 231 the attacker needs to find a valid SubjectPublicKeyInfo that contains 232 the public key that corresponds to a private key known to the 233 attacker. 235 If an early release of the next generation public key occurs and the 236 Root CA is concerned that attackers were given too much lead time to 237 analyze that public key, then the Root CA can transition to a freshly 238 generated key pair by rapidly performing two transitions. The first 239 transition takes the Root CA to the key pair that suffered the early 240 release, and it causes the Root CA to generate the subsequent Root 241 key pair. The second transition occurs when the Root CA is confident 242 that the population of relying parties have completed the first 243 transition, and it takes the Root CA to the freshly generated key 244 pair. Of course, the second transition also causes the Root CA to 245 generate the Root key pair for future use. 247 7. Acknowledgements 249 The Secure Electronic Transaction (SET) [SET] specification published 250 by MasterCard and VISA in 1997 includes a very similar certificate 251 extension. The SET certificate extension has essentially the same 252 semantics, but the syntax fairly different. 254 CTIA - The Wireless Association is developing a public key 255 infrastructure that will make use of the certificate extension 256 described in this document. 258 Many thanks to Jim Schaad, Stefan Santesson, and Paul Hoffman. Their 259 review and comments have greatly improved the document, especially 260 the Operational Considerations and Security Considerations sections. 262 8. References 264 8.1. Normative References 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, 268 DOI 10.17487/RFC2119, March 1997, 269 . 271 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 272 Infrastructure Certificate Management Protocols", 273 RFC 2510, DOI 10.17487/RFC2510, March 1999, 274 . 276 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 277 Hashes in Internet Protocols", RFC 4270, 278 DOI 10.17487/RFC4270, November 2005, 279 . 281 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 282 Housley, R., and W. Polk, "Internet X.509 Public Key 283 Infrastructure Certificate and Certificate Revocation List 284 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 285 . 287 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 288 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 289 DOI 10.17487/RFC5912, June 2010, 290 . 292 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 293 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 294 May 2017, . 296 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 297 One (ASN.1): Specification of basic notation", 298 ITU-T Recommendation X.680, 2015. 300 [X690] ITU-T, "Information Technology -- ASN.1 encoding rules: 301 Specification of Basic Encoding Rules (BER), Canonical 302 Encoding Rules (CER) and Distinguished Encoding Rules 303 (DER)", ITU-T Recommendation X.690, 2015. 305 8.2. Informative References 307 [SET] MasterCard and VISA, "SET Secure Electronic Transaction 308 Specification -- Book 2: Programmer's Guide, Version 1.0", 309 May 1997. 311 Appendix A. ASN.1 Module 313 The following ASN.1 module provides the complete definition of the 314 HashOfRootKey certificate extension. 316 HashedRootKeyCertExtn { 1 3 6 1 4 1 51483 0 1 } 318 DEFINITIONS IMPLICIT TAGS ::= 319 BEGIN 321 -- EXPORTS All 323 IMPORTS 325 AlgorithmIdentifier{}, DIGEST-ALGORITHM 326 FROM AlgorithmInformation-2009 -- [RFC5912] 327 { iso(1) identified-organization(3) dod(6) internet(1) 328 security(5) mechanisms(5) pkix(7) id-mod(0) 329 id-mod-algorithmInformation-02(58) } 331 EXTENSION 332 FROM PKIX-CommonTypes-2009 333 { iso(1) identified-organization(3) dod(6) internet(1) 334 security(5) mechanisms(5) pkix(7) id-mod(0) 335 id-mod-pkixCommon-02(57) } ; 337 -- 338 -- Expand the certificate extensions list in [RFC5912] 339 -- 341 CertExtensions EXTENSION ::= { 342 ext-HashOfRootKey, ... } 344 -- 345 -- HashOfRootKey Certificate Extension 346 -- 348 ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates 349 SYNTAX HashedRootKey 350 IDENTIFIED BY id-ce-hashOfRootKey 351 CRITICALITY {FALSE} } 353 HashedRootKey ::= SEQUENCE { 354 hashAlg HashAlgorithmId, -- Hash algorithm used 355 hashValue OCTET STRING } -- Hash of DER-encoded 356 -- SubjectPublicKeyInfo 358 HashAlgorithmId ::= AlgorithmIdentifier {DIGEST-ALGORITHM,{ ... }} 360 id-ce-hashOfRootKey OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 51483 2 1 } 362 END 364 Author's Address 366 Russ Housley 367 Vigil Security 368 516 Dranesville Road 369 Herndon, VA 20170 370 US 372 Email: housley@vigilsec.com