idnits 2.17.00 (12 Aug 2021) /tmp/idnits29924/draft-ietf-lamps-hash-of-root-key-cert-extn-00.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 (August 31, 2018) is 1359 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 August 31, 2018 5 Expires: March 4, 2019 7 Hash Of Root Key Certificate Extension 8 draft-ietf-lamps-hash-of-root-key-cert-extn-00 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. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 4, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Hash Of Root Key Certificate Extension . . . . . . . . . . . 3 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 7.2. Informative References . . . . . . . . . . . . . . . . . 6 63 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 This document specifies the Hash Of Root Key X.509 version 3 69 certificate extension. The extension is an optional addition to the 70 Internet X.509 Public Key Infrastructure Certificate and Certificate 71 Revocation List (CRL) Profile [RFC5280]. The certificate extension 72 facilitates the orderly transition from one Root Certification 73 Authority (CA) public key to the next. It does so by publishing the 74 hash value of the next generation public key in the current self- 75 signed certificate. This allows a relying party to unambiguously 76 recognize the next generation public key when it becomes available. 78 A Root CA Certificate MAY include the Hashed Root Key certificate 79 extension to provide the hash value of the next public key that will 80 be used by the Root CA. 82 1.1. Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 86 "OPTIONAL" in this document are to be interpreted as described in BCP 87 14 [RFC2119][RFC8174] when, and only when, they appear in all 88 capitals, as shown here. 90 1.2. ASN.1 92 Certificates [RFC5280] are generated using ASN.1 [X680], which uses 93 the Basic Encoding Rules (BER) and the Distinguished Encoding Rules 94 (DER) [X690]. 96 2. Overview 98 Before the initial deployment of the Root CA, the following are 99 generated: 101 R1 = The initial Root key pair 102 C1 = Self-signed certificate for R1, which also contains H2 103 R2 = The second generation Root key pair 104 H2 = Thumbprint (hash) of the public key of R2 106 C1 is a self-signed certificate, and it contains H2 within the 107 HashOfRootKey extension. C1 is distributed as part of the initial 108 the system deployment. The HashOfRootKey certificate extension is 109 described in Section 3. 111 When the time comes to replace the initial Root CA certificate, R1, 112 the following are generated: 114 R3 = The third generation Root key pair 115 H3 = Thumbprint (hash) the public key of R3 116 C2 = Self-signed certificate for R2, which contains H3 118 This is an iterative process. That is, R4 and H4 are generated when 119 it is time for C3 to replace C2. And so on. 121 The successors to the Root CA self-signed certificate can be 122 delivered by any means. Whenever a new Root CA certificate is 123 received, the recipient is able to verify that the potential Root CA 124 certificate chains back to a previously authenticated Root CA 125 certificate with the hashOfRootKey certificate extension. That is, 126 validate the self-signed signature and verify that the hash of the 127 DER-encoded SubjectPublicKeyInfo from the potential Root CA 128 certificate matches the value from the HashOfRootKey certificate 129 extension of the current Root CA certificate. If the signature does 130 not validate or the hash values do not match, then potential Root CA 131 certificate is not a valid replacement, and the recipient continues 132 to use the current Root CA certificate. 134 3. Hash Of Root Key Certificate Extension 136 The HashOfRootKey certificate extension MUST NOT be critical. 138 The following ASN.1 [X680][X690] syntax defines the HashOfRootKey 139 certificate extension: 141 ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates 142 SYNTAX HashedRootKey 143 IDENTIFIED BY id-ce-hashOfRootKey 144 CRITICALITY {FALSE} } 146 HashedRootKey ::= SEQUENCE { 147 hashAlg AlgorithmIdentifier, -- Hash algorithm used 148 hashValue OCTET STRING } -- Hash of DER-encoded 149 -- SubjectPublicKeyInfo 151 id-ce-hashOfRootKey ::= OBJECT IDENTIFIER { 1 3 6 1 4 1 TBD 2 1 } 153 The definitions of EXTENSION and HashAlgorithm can be found in 154 [RFC5912]. 156 The hashAlg indicates the one-way hash algorithm that was used to 157 compute the hash value. 159 The hashValue contains the hash value computed from the next 160 generation public key. The public key is DER-encoded 161 SubjectPublicKeyInfo as defined in [RFC5280]. 163 4. IANA Considerations 165 This document makes no requests of the IANA. 167 5. Security Considerations 169 The security considerations from [RFC5280] apply, especially the 170 discussion of self-issued certificates. 172 The Hash Of Root Key certificate extension facilitates the orderly 173 transition from one Root CA public key to the next by publishing the 174 hash value of the next generation public key in the current 175 certificate. This allows a relying party to unambiguously recognize 176 the next generation public key when it becomes available; however, 177 the full public key is not disclosed until the Root CA releases the 178 next generation certificate. In this way, attackers cannot begin to 179 analyze the public key before the next generation Root CA certificate 180 is released. 182 If an early release of the next generation public key occurs and the 183 Root CA is concerned that attackers were given too much lead time to 184 analyze that public key, then the Root CA can transition to a freshly 185 generated key pair by rapidly performing two transitions. The first 186 transition takes the Root CA to the key pair that suffered the early 187 release, and it causes the Root CA to generate the subsequent Root 188 key pair. The second transition occurs when the Root CA is confident 189 that the population of relying parties have completed the first 190 transition, and it takes the Root CA to the freshly generated key 191 pair. Of course, the second transition also causes the Root CA to 192 generate the Root key pair for future use. 194 6. Acknowledgements 196 The Secure Electronic Transaction (SET) [SET] specification published 197 by MasterCard and VISA in 1997 includes a very similar certificate 198 extension. The SET certificate extension has essentially the same 199 semantics, but the syntax fairly different. 201 CTIA - The Wireless Association is developing a public key 202 infrastructure that will make use of the certificate extension 203 described in this document. 205 7. References 207 7.1. Normative References 209 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 210 Requirement Levels", BCP 14, RFC 2119, 211 DOI 10.17487/RFC2119, March 1997, 212 . 214 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 215 Housley, R., and W. Polk, "Internet X.509 Public Key 216 Infrastructure Certificate and Certificate Revocation List 217 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 218 . 220 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 221 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 222 DOI 10.17487/RFC5912, June 2010, 223 . 225 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 226 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 227 May 2017, . 229 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 230 One (ASN.1): Specification of basic notation", 231 ITU-T Recommendation X.680, 2015. 233 [X690] ITU-T, "Information Technology -- ASN.1 encoding rules: 234 Specification of Basic Encoding Rules (BER), Canonical 235 Encoding Rules (CER) and Distinguished Encoding Rules 236 (DER)", ITU-T Recommendation X.690, 2015. 238 7.2. Informative References 240 [SET] MasterCard and VISA, "SET Secure Electronic Transaction 241 Specification -- Book 2: Programmer's Guide, Version 1.0", 242 May 1997. 244 Appendix A. ASN.1 Module 246 The following ASN.1 module provides the complete definition of the 247 HashOfRootKey certificate extension. 249 HashedRootKeyCertExtn { 1 3 6 1 4 1 51483 0 1 } 251 DEFINITIONS IMPLICIT TAGS ::= 252 BEGIN 254 -- EXPORTS All 256 IMPORTS 258 AlgorithmIdentifier{}, DIGEST-ALGORITHM 259 FROM AlgorithmInformation-2009 -- [RFC5912] 260 { iso(1) identified-organization(3) dod(6) internet(1) 261 security(5) mechanisms(5) pkix(7) id-mod(0) 262 id-mod-algorithmInformation-02(58) } 264 EXTENSION 265 FROM PKIX-CommonTypes-2009 266 { iso(1) identified-organization(3) dod(6) internet(1) 267 security(5) mechanisms(5) pkix(7) id-mod(0) 268 id-mod-pkixCommon-02(57) } ; 270 -- 271 -- Expand the certificate extensions list in [RFC5912] 272 -- 274 CertExtensions EXTENSION ::= { 275 ext-HashOfRootKey, ... } 277 -- 278 -- HashOfRootKey Certificate Extension 279 -- 281 ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates 282 SYNTAX HashedRootKey 283 IDENTIFIED BY id-ce-hashOfRootKey 284 CRITICALITY {FALSE} } 286 HashedRootKey ::= SEQUENCE { 287 hashAlg HashAlgorithmId, -- Hash algorithm used 288 hashValue OCTET STRING } -- Hash of DER-encoded 289 -- SubjectPublicKeyInfo 291 HashAlgorithmId ::= AlgorithmIdentifier {DIGEST-ALGORITHM,{ ... }} 293 id-ce-hashOfRootKey OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 51483 2 1 } 295 END 297 Author's Address 299 Russ Housley 300 Vigil Security 301 918 Spring Knoll Drive 302 Herndon, VA 20170 303 US 305 Email: housley@vigilsec.com