idnits 2.17.1 draft-ietf-lamps-hash-of-root-key-cert-extn-01.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 (November 07, 2018) is 1991 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 November 07, 2018 5 Expires: May 11, 2019 7 Hash Of Root Key Certificate Extension 8 draft-ietf-lamps-hash-of-root-key-cert-extn-01 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 May 11, 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 validate the self-signed signature and verify that the hash of the 131 DER-encoded SubjectPublicKeyInfo from the potential Root CA 132 certificate matches the value from the HashOfRootKey certificate 133 extension of the current Root CA certificate. If the signature does 134 not validate or the hash values do not match, then potential Root CA 135 certificate is not a valid replacement, and the recipient continues 136 to use the current Root CA certificate. 138 3. Hash Of Root Key Certificate Extension 140 The HashOfRootKey certificate extension MUST NOT be critical. 142 The following ASN.1 [X680][X690] syntax defines the HashOfRootKey 143 certificate extension: 145 ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates 146 SYNTAX HashedRootKey 147 IDENTIFIED BY id-ce-hashOfRootKey 148 CRITICALITY {FALSE} } 150 HashedRootKey ::= SEQUENCE { 151 hashAlg AlgorithmIdentifier, -- Hash algorithm used 152 hashValue OCTET STRING } -- Hash of DER-encoded 153 -- SubjectPublicKeyInfo 155 id-ce-hashOfRootKey ::= OBJECT IDENTIFIER { 1 3 6 1 4 1 51483 2 1 } 157 The definitions of EXTENSION and HashAlgorithm can be found in 158 [RFC5912]. 160 The hashAlg indicates the one-way hash algorithm that was used to 161 compute the hash value. 163 The hashValue contains the hash value computed from the next 164 generation public key. The public key is DER-encoded 165 SubjectPublicKeyInfo as defined in [RFC5280]. 167 4. IANA Considerations 169 This document makes no requests of the IANA. 171 5. Operational Considerations 173 Guidance on the transition from one trust anchor to another is 174 available in [RFC2510]. In particular, the oldWithNew and newWithOld 175 advice ensures that relying parties are able to validate certificates 176 issued under the current Root CA certificate and the next generation 177 Root CA certificate throughout the transition. Further, this 178 technique ovoids the need for all relying parties to make the 179 transition at the same time. 181 6. Security Considerations 183 The security considerations from [RFC5280] apply, especially the 184 discussion of self-issued certificates. 186 The Hash Of Root Key certificate extension facilitates the orderly 187 transition from one Root CA public key to the next by publishing the 188 hash value of the next generation public key in the current 189 certificate. This allows a relying party to unambiguously recognize 190 the next generation public key when it becomes available; however, 191 the full public key is not disclosed until the Root CA releases the 192 next generation certificate. In this way, attackers cannot begin to 193 analyze the public key before the next generation Root CA certificate 194 is released. 196 The Root CA needs to ensure that the public key in the next 197 generation certificate is as strong or stronger than the key that it 198 is replacing. 200 The Root CA needs to employ a hash function that is resistant to 201 preimage attacks [RFC4270]. A first-preimage attack against the hash 202 function would allow an attacker to find another input that results 203 published hash value. For the attack to be successful, the input 204 would have to be a valid SubjectPublicKeyInfo that contains the 205 public key that corresponds to a private key known to the attacker. 206 A second-preimage attack becomes possible once the Root CA releases 207 the next generation public key, which makes the input to the hash 208 function becomes available to the attacker and everyone else. Again, 209 the attacker needs to find a valid SubjectPublicKeyInfo that contains 210 the public key that corresponds to a private key known to the 211 attacker. 213 If an early release of the next generation public key occurs and the 214 Root CA is concerned that attackers were given too much lead time to 215 analyze that public key, then the Root CA can transition to a freshly 216 generated key pair by rapidly performing two transitions. The first 217 transition takes the Root CA to the key pair that suffered the early 218 release, and it causes the Root CA to generate the subsequent Root 219 key pair. The second transition occurs when the Root CA is confident 220 that the population of relying parties have completed the first 221 transition, and it takes the Root CA to the freshly generated key 222 pair. Of course, the second transition also causes the Root CA to 223 generate the Root key pair for future use. 225 7. Acknowledgements 227 The Secure Electronic Transaction (SET) [SET] specification published 228 by MasterCard and VISA in 1997 includes a very similar certificate 229 extension. The SET certificate extension has essentially the same 230 semantics, but the syntax fairly different. 232 CTIA - The Wireless Association is developing a public key 233 infrastructure that will make use of the certificate extension 234 described in this document. 236 Many thanks to Jim Schaad and Stefan Santesson. Their review and 237 comments have greatly improved the document, especially the 238 Operational Considerations and Security Considerations sections. 240 8. References 242 8.1. Normative References 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, 246 DOI 10.17487/RFC2119, March 1997, 247 . 249 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 250 Infrastructure Certificate Management Protocols", 251 RFC 2510, DOI 10.17487/RFC2510, March 1999, 252 . 254 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 255 Hashes in Internet Protocols", RFC 4270, 256 DOI 10.17487/RFC4270, November 2005, 257 . 259 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 260 Housley, R., and W. Polk, "Internet X.509 Public Key 261 Infrastructure Certificate and Certificate Revocation List 262 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 263 . 265 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 266 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 267 DOI 10.17487/RFC5912, June 2010, 268 . 270 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 271 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 272 May 2017, . 274 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 275 One (ASN.1): Specification of basic notation", 276 ITU-T Recommendation X.680, 2015. 278 [X690] ITU-T, "Information Technology -- ASN.1 encoding rules: 279 Specification of Basic Encoding Rules (BER), Canonical 280 Encoding Rules (CER) and Distinguished Encoding Rules 281 (DER)", ITU-T Recommendation X.690, 2015. 283 8.2. Informative References 285 [SET] MasterCard and VISA, "SET Secure Electronic Transaction 286 Specification -- Book 2: Programmer's Guide, Version 1.0", 287 May 1997. 289 Appendix A. ASN.1 Module 291 The following ASN.1 module provides the complete definition of the 292 HashOfRootKey certificate extension. 294 HashedRootKeyCertExtn { 1 3 6 1 4 1 51483 0 1 } 296 DEFINITIONS IMPLICIT TAGS ::= 297 BEGIN 299 -- EXPORTS All 301 IMPORTS 303 AlgorithmIdentifier{}, DIGEST-ALGORITHM 304 FROM AlgorithmInformation-2009 -- [RFC5912] 305 { iso(1) identified-organization(3) dod(6) internet(1) 306 security(5) mechanisms(5) pkix(7) id-mod(0) 307 id-mod-algorithmInformation-02(58) } 309 EXTENSION 310 FROM PKIX-CommonTypes-2009 311 { iso(1) identified-organization(3) dod(6) internet(1) 312 security(5) mechanisms(5) pkix(7) id-mod(0) 313 id-mod-pkixCommon-02(57) } ; 315 -- 316 -- Expand the certificate extensions list in [RFC5912] 317 -- 319 CertExtensions EXTENSION ::= { 320 ext-HashOfRootKey, ... } 322 -- 323 -- HashOfRootKey Certificate Extension 324 -- 326 ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates 327 SYNTAX HashedRootKey 328 IDENTIFIED BY id-ce-hashOfRootKey 329 CRITICALITY {FALSE} } 331 HashedRootKey ::= SEQUENCE { 332 hashAlg HashAlgorithmId, -- Hash algorithm used 333 hashValue OCTET STRING } -- Hash of DER-encoded 334 -- SubjectPublicKeyInfo 336 HashAlgorithmId ::= AlgorithmIdentifier {DIGEST-ALGORITHM,{ ... }} 338 id-ce-hashOfRootKey OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 51483 2 1 } 340 END 342 Author's Address 344 Russ Housley 345 Vigil Security 346 918 Spring Knoll Drive 347 Herndon, VA 20170 348 US 350 Email: housley@vigilsec.com