idnits 2.17.1 draft-ietf-sidrops-signed-tal-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7730], [RFC6488]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 13, 2017) is 2355 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5781 ** Obsolete normative reference: RFC 7730 (Obsoleted by RFC 8630) Summary: 3 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 T. Bruijnzeels 3 Internet-Draft RIPE NCC 4 Intended status: Standards Track C. Martinez 5 Expires: May 17, 2018 LACNIC 6 November 13, 2017 8 RPKI signed object for TAL 9 draft-ietf-sidrops-signed-tal-00 11 Abstract 13 Trust Anchor Locators (TALs) [RFC7730] are used by Relying Parties in 14 the RPKI to locate and validate Trust Anchor certificates used in 15 RPKI validation. This document defines an RPKI signed object 16 [RFC6488] for a Trust Anchor Locator (TAL) that can be published by 17 Trust Anchor to communicate a new TAL to already deployed Relying 18 Parties. The two primary use cases for this are that 1) a Trust 19 Anchor may wish to change the locations where its TA certificate may 20 be found, and 2) a Trust Anchor may wish to perform a planned 21 migration to a new key. Note that unplanned key rolls are considered 22 out of scope for this document. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 17, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Signed TAL definition . . . . . . . . . . . . . . . . . . . . 3 61 3.1. The Signed TAL Content Type . . . . . . . . . . . . . . . 4 62 3.2. The Signed TAL eContent . . . . . . . . . . . . . . . . . 4 63 3.3. Signed TAL Validation . . . . . . . . . . . . . . . . . . 4 64 4. Signed TAL Generation . . . . . . . . . . . . . . . . . . . . 4 65 5. Signed TAL Publication . . . . . . . . . . . . . . . . . . . 5 66 6. Supporting a TA Key Roll . . . . . . . . . . . . . . . . . . 5 67 6.1. Preparing a new TA key . . . . . . . . . . . . . . . . . 6 68 6.2. Staging period - Using both the old and the new TA key . 6 69 6.3. Preserving the Signed TAL . . . . . . . . . . . . . . . . 6 70 6.4. Retiring the old key . . . . . . . . . . . . . . . . . . 7 71 6.5. Relying Party Use . . . . . . . . . . . . . . . . . . . . 7 72 7. Supporting changing TA certificate publication point(s) . . . 7 73 7.1. Adding a publication point . . . . . . . . . . . . . . . 7 74 7.2. Withdrawing a publication point . . . . . . . . . . . . . 7 75 7.3. Publishing the Signed TAL . . . . . . . . . . . . . . . . 7 76 7.4. Relying Party Use . . . . . . . . . . . . . . . . . . . . 7 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 78 8.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 8.2. File Extension . . . . . . . . . . . . . . . . . . . . . 8 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 84 11.2. Informative References . . . . . . . . . . . . . . . . . 9 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 87 1. Requirements notation 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 2. Introduction 95 Trust Anchor Locator (TAL) files [RFC7730] are used in the Resource 96 Public Key Infrastructure (RPKI) to help Relying Parties locate and 97 verify a trust anchor certificate. A TAL file consists of: 99 o One or more rsync URIs [RFC5781] 101 o A subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded in 102 Base64 104 The TAL can be distributed out-of-band to Relying Parties (RP), and 105 it allows the RP to retrieve the most recent version of the Trust 106 Anchor (TA) certificate from the cited location, and verify that 107 public key of this certificate matches the TAL. This is useful as it 108 allows selected data in the trust anchor to change, without needing 109 to effect redistribution of the trust anchor per se. In particular 110 the Internet Number Resources (INRs) extension [RFC3779] and the 111 publication points defined in the Subject Information Access 112 [RFC6487] may be updated this way. 114 The assumption is that both the URIs and key of the TA certificate 115 remain stable. However, an organisation operating a TA may wish to 116 change either of these properties, because of a need to: 118 o change one or more URIs 120 o perform a planned key roll 122 In this document we describe a method for TA operators to publish a 123 an updated TAL in a secure a well-defined fashion, so that RPs can be 124 alerted about these changes. 126 Note that [RFC5011] describes Automated Updates of DNS Security 127 (DNSSEC) Trust Anchors and can provide some useful insight here as 128 well. However, concepts like a set of Trust Anchors, standby Trust 129 Anchors, and TTLs are not applicable to the RPKI. Therefore we 130 believe that an alternative approach based on already existing 131 concept of the Trust Anchor Locator [RFC7730] is appropriate. 133 3. Signed TAL definition 135 A signed TAL is an RPKI signed object, as specified in [RFC6488]. 136 The RPKI signed object template requires specification of the 137 following data elements in the context of the manifest structure. 139 3.1. The Signed TAL Content Type 141 This document requests an OID for signed-Tal as follows: 143 signed-Tal OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 144 rsadsi(113549) pkcs(1) pkcs9(9) 16 id-smime (1) TBD } 146 This OID MUST appear both within the eContentType in the 147 encapContentInfo object as well as the content-type signed attribute 148 in the signerInfo object (see [RFC6488]). 150 3.2. The Signed TAL eContent 152 The content of a Signed TAL is ASN.1 encoded using the Distinguished 153 Encoding Rules (DER) [X.690], and is defined as follows: 155 SignedTalContent ::= IA5String 157 The "SignedTalContent" contains the content of the new TAL encoded in 158 Base64 [RFC4648]. 160 3.3. Signed TAL Validation 162 Before a Relying Party can use a Signed TAL, the relying party MUST 163 first validate the Signed TAL. To validate a Signed TAL, the relying 164 party MUST perform all the validation checks specified in [RFC6488] 165 as well as the following additional specific validation step. 167 o The eContentType in the EncapsulatedContentInfo has OID 168 1.2.840.113549.1.9.16.1.TBD. 170 o The EE certificate of this Signed TAL is signed by a known Trust 171 Anchor 173 o The decoded TAL content conforms to the format defined in 174 [RFC7730] 176 If the above procedure indicates that the manifest is invalid, then 177 the Signed TAL MUST be discarded and treated as though no Signed TAL 178 were present. 180 4. Signed TAL Generation 182 A TA MAY choose to generate a single Singed TAL object to publish in 183 its TA certificate publication point(s) in the RPKI. The TA MUST 184 perform the following steps to generate the Signed TAL: 186 o Generate a key pair for a "one-time-use" EE certificate to use for 187 the Signed TAL 189 o Generate a one-time-use EE certificate for the Signed TAL 191 o This EE certificate MUST have an SIA extension access description 192 field with an accessMethod OID value of id-ad-signedobject, where 193 the associated accessLocation references the publication point of 194 the Sigend TAL as an object URL. 196 o As described in [RFC6487], an [RFC3779] extension is required in 197 the EE certificate used for this object. However, because the 198 resource set is irrelevant to this object type, this certificate 199 MUST describe its Internet Number Resources (INRs) using the 200 "inherit" attribute, rather than explicit description of a 201 resource set. 203 o This EE certificate MUST have a "notBefore" time that is before 204 the moment that the Signed TAL will be published. 206 o This EE certificate MUST have a "notAfter" time that reflects the 207 intended time that this Signed TAL will be published. If the EE 208 certificate for a Signed TAL is expired, it MUST no longer be 209 publish, but of course it MAY be replaced by a newly generated 210 Signed TAL object with similar content and an updated "notAfter" 211 time. 213 5. Signed TAL Publication 215 A TA MAY publish a single Signed TAL object directly under its CA 216 repository publication points. A non-normative guideline for naming 217 this object is that the filename chosen for the signed TAL in the 218 publication repository be a value derived from the public key part of 219 the entity's key pair, using the algorithm described for CRLs in 220 section 2.2 of [RFC6481] for generation of filenames. The filename 221 extension of ".tal" MUST be used to denote the object as a signed 222 TAL. Note that this is in-line with filename extensions defined in 223 section 7.2 of [RFC6481]. 225 6. Supporting a TA Key Roll 227 A Signed TAL MAY be used to communicate a planned key roll for the 228 TA. 230 6.1. Preparing a new TA key 232 Prior to publishing the Signed TAL for the new key the TA MUST 233 perform the following steps: 235 o Generate a new key pair for the new TA certificate 237 o Generate a new TA Certificate, using a Subject Information Access 238 for CA certificates (see section 4.8.8.1 of [RFC6487]) that 239 references the URIs that will be used by the new key to publish 240 objects, that are different from the URIs used by the TA 241 certificate for the current key. 243 o ALL current signed certificates and other objects, with the 244 exception of the old CRL, Manifest and Signed TAL, must be re- 245 issued by the new key and published under the new publication 246 point(s). 248 o The new TA certificate itself MUST be published in a (number of) 249 new location(s) that are different from where the TA certificate 250 for the current key is published. 252 After these steps are performed a new Signed TAL MUST be generated as 253 described in Section 4, and published as described in Section 5. 255 6.2. Staging period - Using both the old and the new TA key 257 The staging period is initiated by the initial publication of a 258 Signed TAL for the new key and must be last at least 24 HOURS. 259 During the staging period the TA MUST continue to operate both the 260 old and the new TA key. Note that this is the same staging period 261 used for key roll of normal CAs in the RPKI, described in [RFC6489]. 263 6.3. Preserving the Signed TAL 265 The TA SHOULD preserve a Signed TAL for the old key after the staging 266 period as a hint for RPs that missed the key roll. The following 267 process can be used to achieve this: 269 o Produce a new long-lived CRL that revokes all previously signed 270 certificates 272 o Produce a new long-lived Signed TAL 274 o Produce a new long-lived manifest that includes the CRL and Signed 275 TAL 277 o Publish the CRL, MFT and Signed TAL 278 o Destroy the old TA key 280 6.4. Retiring the old key 282 The TA SHOULD retire and delete its old key after the staging period 283 is over. 285 6.5. Relying Party Use 287 When an RP discovers a valid Signed TAL signed under a TA, and it 288 notices that the contained TAL is different from its current TAL for 289 this TA and that the "subjectPublicKeyInfo" has changed, then the RP 290 MUST replace the TAL for this TA with the new TAL, abort the current 291 top-down validation operation, and initiate a new top-down validation 292 operation using the updated TAL. 294 It is RECOMMENDED that the software informs the operator of this 295 event. 297 7. Supporting changing TA certificate publication point(s) 299 A signed TAL MAY be used to communicate an addition or removal of one 300 or more publication locations where the TA certificate can be found. 302 7.1. Adding a publication point 304 When adding a publication point for a TA certificate, the TA MUST 305 publish the certificate in the new location(s) prior to publication 306 of the Signed TAL. 308 7.2. Withdrawing a publication point 310 When removing a publication point for TA certificate, the TA SHOULD 311 observe a staging period of at least 24 Hours. The staging period is 312 initiated by the publication of an updated Signed TAL where the 313 publication point has been removed. During the staging period the TA 314 SHOULD keep the old publication point up to date and available. 316 7.3. Publishing the Signed TAL 318 It is RECOMMENDED that a Trust Anchor publishes a valid Signed TAL 319 for what it believes its current TAL should be at all times. 321 7.4. Relying Party Use 323 When an RP discovers a valid Signed TAL signed under a TA, and it 324 notices that the contained TAL is different from its current TAL for 325 this TA and that the "subjectPublicKeyInfo" has not changed, then the 326 RP MUST replace the TAL for this TA with the new TAL for future use, 327 but can continue the current top-down validation operation. 329 It is RECOMMENDED that the software informs the operator of this 330 event. 332 8. IANA Considerations 334 8.1. OID 336 IANA is to add the following to the "RPKI Signed Objects" registry: 338 Decimal Description References 340 TBD signed-Tal [section 3.1] 342 8.2. File Extension 344 IANA is to add an item for the Signed TAL file extension to the "RPKI 345 Repository Name Scheme" created by [RFC6481] as follows: 347 Extension RPKI Object Reference 348 ------------------------------------------------------- 349 .tal Signed TAL [this document] 351 9. Security Considerations 353 TBD 355 10. Acknowledgements 357 TBD 359 11. References 361 11.1. Normative References 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, 365 DOI 10.17487/RFC2119, March 1997, 366 . 368 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 369 Addresses and AS Identifiers", RFC 3779, 370 DOI 10.17487/RFC3779, June 2004, 371 . 373 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 374 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 375 . 377 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 378 Housley, R., and W. Polk, "Internet X.509 Public Key 379 Infrastructure Certificate and Certificate Revocation List 380 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 381 . 383 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 384 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 385 . 387 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 388 Resource Certificate Repository Structure", RFC 6481, 389 DOI 10.17487/RFC6481, February 2012, 390 . 392 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 393 X.509 PKIX Resource Certificates", RFC 6487, 394 DOI 10.17487/RFC6487, February 2012, 395 . 397 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 398 Template for the Resource Public Key Infrastructure 399 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 400 . 402 [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 403 "Resource Public Key Infrastructure (RPKI) Trust Anchor 404 Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, 405 . 407 [X.509] ITU-T Recommendation X.509 (2000), "Recommendation X.509: 408 The Directory - Authentication Framework", 2000. 410 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 411 "Information technology - ASN.1 encoding rules: 412 Specification of Basic Encoding Rules (BER), Canonical 413 Encoding Rules (CER) and Distinguished Encoding Rules 414 (DER)", 2002. 416 11.2. Informative References 418 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 419 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 420 September 2007, . 422 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 423 Authority (CA) Key Rollover in the Resource Public Key 424 Infrastructure (RPKI)", BCP 174, RFC 6489, 425 DOI 10.17487/RFC6489, February 2012, 426 . 428 Authors' Addresses 430 Tim Bruijnzeels 431 RIPE NCC 433 Email: tim@ripe.net 435 Carlos Martinez 436 LACNIC 438 Email: carlos@lacnic.net