idnits 2.17.00 (12 Aug 2021) /tmp/idnits28524/draft-ietf-lamps-hash-of-root-key-cert-extn-02.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 (December 27, 2018) is 1241 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 December 27, 2018 5 Expires: June 30, 2019 7 Hash Of Root Key Certificate Extension 8 draft-ietf-lamps-hash-of-root-key-cert-extn-02 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 by the trust anchor 17 at some point in the future. 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 June 30, 2019. 36 Copyright Notice 38 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . 4 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 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 allows a relying party to unambiguously 78 recognize the next generation public key when it becomes available, 79 install that public key in the trust anchor store, and remove the 80 previous public key from the trust anchor store. 82 A Root CA Certificate MAY include the Hashed Root Key certificate 83 extension to provide the hash value of the next public key that will 84 be used by the Root CA. 86 1.1. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 90 "OPTIONAL" in this document are to be interpreted as described in BCP 91 14 [RFC2119][RFC8174] when, and only when, they appear in all 92 capitals, as shown here. 94 1.2. ASN.1 96 Certificates [RFC5280] are generated using ASN.1 [X680]; certificates 97 are always encoded with the Distinguished Encoding Rules (DER) 98 [X690]. 100 2. Overview 102 Before the initial deployment of the Root CA, the following are 103 generated: 105 R1 = The initial Root key pair 106 C1 = Self-signed certificate for R1, which also contains H2 107 R2 = The second generation Root key pair 108 H2 = Thumbprint (hash) of the public key of R2 110 C1 is a self-signed certificate, and it contains H2 within the 111 HashOfRootKey extension. C1 is distributed as part of the initial 112 the system deployment. The HashOfRootKey certificate extension is 113 described in Section 3. 115 When the time comes to replace the initial Root CA certificate, R1, 116 the following are generated: 118 R3 = The third generation Root key pair 119 H3 = Thumbprint (hash) the public key of R3 120 C2 = Self-signed certificate for R2, which contains H3 122 This is an iterative process. That is, R4 and H4 are generated when 123 it is time for C3 to replace C2. And so on. 125 The successors to the Root CA self-signed certificate can be 126 delivered by any means. Whenever a new Root CA certificate is 127 received, the recipient is able to verify that the potential Root CA 128 certificate links back to a previously authenticated Root CA 129 certificate with the hashOfRootKey certificate extension. That is, 130 verify the signature on the self-signed certificate and verify that 131 the hash of the DER-encoded SubjectPublicKeyInfo from the potential 132 Root CA certificate matches the value from the HashOfRootKey 133 certificate extension of the current Root CA certificate. Checking 134 the self-signed certificate signature ensures that the certificate 135 contains the subject name that the key owner intends, which is 136 important for path validation. Checking the hash of the 137 SubjectPublicKeyInfo ensures that the certificate contains the 138 intended public key. If either check fails, then potential Root CA 139 certificate is not a valid replacement, and the recipient continues 140 to use the current Root CA certificate. 142 3. Hash Of Root Key Certificate Extension 144 The HashOfRootKey certificate extension MUST NOT be critical. 146 The following ASN.1 [X680][X690] syntax defines the HashOfRootKey 147 certificate extension: 149 ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates 150 SYNTAX HashedRootKey 151 IDENTIFIED BY id-ce-hashOfRootKey 152 CRITICALITY {FALSE} } 154 HashedRootKey ::= SEQUENCE { 155 hashAlg AlgorithmIdentifier, -- Hash algorithm used 156 hashValue OCTET STRING } -- Hash of DER-encoded 157 -- SubjectPublicKeyInfo 159 id-ce-hashOfRootKey ::= OBJECT IDENTIFIER { 1 3 6 1 4 1 51483 2 1 } 161 The definitions of EXTENSION and HashAlgorithm can be found in 162 [RFC5912]. 164 The hashAlg indicates the one-way hash algorithm that was used to 165 compute the hash value. 167 The hashValue contains the hash value computed from the next 168 generation public key. The public key is DER-encoded 169 SubjectPublicKeyInfo as defined in [RFC5280]. 171 4. IANA Considerations 173 This document makes no requests of the IANA. 175 5. Operational Considerations 177 Guidance on the transition from one trust anchor to another is 178 available in [RFC2510]. In particular, the oldWithNew and newWithOld 179 advice ensures that relying parties are able to validate certificates 180 issued under the current Root CA certificate and the next generation 181 Root CA certificate throughout the transition. Further, this 182 technique avoids the need for all relying parties to make the 183 transition at the same time. 185 6. Security Considerations 187 The security considerations from [RFC5280] apply, especially the 188 discussion of self-issued certificates. 190 The Hash Of Root Key certificate extension facilitates the orderly 191 transition from one Root CA public key to the next by publishing the 192 hash value of the next generation public key in the current 193 certificate. This allows a relying party to unambiguously recognize 194 the next generation public key when it becomes available; however, 195 the full public key is not disclosed until the Root CA releases the 196 next generation certificate. In this way, attackers cannot begin to 197 analyze the public key before the next generation Root CA certificate 198 is released. 200 The Root CA needs to ensure that the public key in the next 201 generation certificate is as strong or stronger than the key that it 202 is replacing. 204 The Root CA needs to employ a hash function that is resistant to 205 preimage attacks [RFC4270]. A first-preimage attack against the hash 206 function would allow an attacker to find another input that results 207 published hash value. For the attack to be successful, the input 208 would have to be a valid SubjectPublicKeyInfo that contains the 209 public key that corresponds to a private key known to the attacker. 210 A second-preimage attack becomes possible once the Root CA releases 211 the next generation public key, which makes the input to the hash 212 function becomes available to the attacker and everyone else. Again, 213 the attacker needs to find a valid SubjectPublicKeyInfo that contains 214 the public key that corresponds to a private key known to the 215 attacker. 217 If an early release of the next generation public key occurs and the 218 Root CA is concerned that attackers were given too much lead time to 219 analyze that public key, then the Root CA can transition to a freshly 220 generated key pair by rapidly performing two transitions. The first 221 transition takes the Root CA to the key pair that suffered the early 222 release, and it causes the Root CA to generate the subsequent Root 223 key pair. The second transition occurs when the Root CA is confident 224 that the population of relying parties have completed the first 225 transition, and it takes the Root CA to the freshly generated key 226 pair. Of course, the second transition also causes the Root CA to 227 generate the Root key pair for future use. 229 7. Acknowledgements 231 The Secure Electronic Transaction (SET) [SET] specification published 232 by MasterCard and VISA in 1997 includes a very similar certificate 233 extension. The SET certificate extension has essentially the same 234 semantics, but the syntax fairly different. 236 CTIA - The Wireless Association is developing a public key 237 infrastructure that will make use of the certificate extension 238 described in this document. 240 Many thanks to Jim Schaad and Stefan Santesson. Their review and 241 comments have greatly improved the document, especially the 242 Operational Considerations and Security Considerations sections. 244 8. References 246 8.1. Normative References 248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14, RFC 2119, 250 DOI 10.17487/RFC2119, March 1997, 251 . 253 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 254 Infrastructure Certificate Management Protocols", 255 RFC 2510, DOI 10.17487/RFC2510, March 1999, 256 . 258 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 259 Hashes in Internet Protocols", RFC 4270, 260 DOI 10.17487/RFC4270, November 2005, 261 . 263 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 264 Housley, R., and W. Polk, "Internet X.509 Public Key 265 Infrastructure Certificate and Certificate Revocation List 266 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 267 . 269 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 270 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 271 DOI 10.17487/RFC5912, June 2010, 272 . 274 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 275 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 276 May 2017, . 278 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 279 One (ASN.1): Specification of basic notation", 280 ITU-T Recommendation X.680, 2015. 282 [X690] ITU-T, "Information Technology -- ASN.1 encoding rules: 283 Specification of Basic Encoding Rules (BER), Canonical 284 Encoding Rules (CER) and Distinguished Encoding Rules 285 (DER)", ITU-T Recommendation X.690, 2015. 287 8.2. Informative References 289 [SET] MasterCard and VISA, "SET Secure Electronic Transaction 290 Specification -- Book 2: Programmer's Guide, Version 1.0", 291 May 1997. 293 Appendix A. ASN.1 Module 295 The following ASN.1 module provides the complete definition of the 296 HashOfRootKey certificate extension. 298 HashedRootKeyCertExtn { 1 3 6 1 4 1 51483 0 1 } 300 DEFINITIONS IMPLICIT TAGS ::= 301 BEGIN 303 -- EXPORTS All 305 IMPORTS 307 AlgorithmIdentifier{}, DIGEST-ALGORITHM 308 FROM AlgorithmInformation-2009 -- [RFC5912] 309 { iso(1) identified-organization(3) dod(6) internet(1) 310 security(5) mechanisms(5) pkix(7) id-mod(0) 311 id-mod-algorithmInformation-02(58) } 313 EXTENSION 314 FROM PKIX-CommonTypes-2009 315 { iso(1) identified-organization(3) dod(6) internet(1) 316 security(5) mechanisms(5) pkix(7) id-mod(0) 317 id-mod-pkixCommon-02(57) } ; 319 -- 320 -- Expand the certificate extensions list in [RFC5912] 321 -- 323 CertExtensions EXTENSION ::= { 324 ext-HashOfRootKey, ... } 326 -- 327 -- HashOfRootKey Certificate Extension 328 -- 330 ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates 331 SYNTAX HashedRootKey 332 IDENTIFIED BY id-ce-hashOfRootKey 333 CRITICALITY {FALSE} } 335 HashedRootKey ::= SEQUENCE { 336 hashAlg HashAlgorithmId, -- Hash algorithm used 337 hashValue OCTET STRING } -- Hash of DER-encoded 338 -- SubjectPublicKeyInfo 340 HashAlgorithmId ::= AlgorithmIdentifier {DIGEST-ALGORITHM,{ ... }} 342 id-ce-hashOfRootKey OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 51483 2 1 } 344 END 346 Author's Address 348 Russ Housley 349 Vigil Security 350 918 Spring Knoll Drive 351 Herndon, VA 20170 352 US 354 Email: housley@vigilsec.com