idnits 2.17.1 draft-ietf-sidrops-signed-tal-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-sidrops-https-tal], [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 (June 8, 2018) is 2143 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 158 == Outdated reference: A later version (-08) exists of draft-ietf-sidrops-https-tal-03 ** Downref: Normative reference to an Informational RFC: RFC 5781 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Bruijnzeels 3 Internet-Draft NLnet Labs 4 Intended status: Best Current Practice C. Martinez 5 Expires: December 10, 2018 LACNIC 6 June 8, 2018 8 RPKI signed object for TAL 9 draft-ietf-sidrops-signed-tal-01 11 Abstract 13 Trust Anchor Locators (TALs) [I-D.ietf-sidrops-https-tal] are used by 14 Relying Parties in the RPKI to locate and validate Trust Anchor 15 certificates used in RPKI validation. This document defines an RPKI 16 signed object [RFC6488] for a Trust Anchor Locator (TAL) that can be 17 used by Trust Anchors to perform a planned migration to a new key, 18 allowing Relying Parties to discover the new key up to one year after 19 the migration occurred. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 10, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Signed TAL definition . . . . . . . . . . . . . . . . . . . . 3 58 3.1. The Signed TAL Content Type . . . . . . . . . . . . . . . 4 59 3.2. The Signed TAL eContent . . . . . . . . . . . . . . . . . 4 60 3.2.1. version . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2.2. activationTime . . . . . . . . . . . . . . . . . . . 4 62 3.2.3. certificateURIs . . . . . . . . . . . . . . . . . . . 4 63 3.2.4. subjectPublicKeyInfo . . . . . . . . . . . . . . . . 4 64 3.3. Signed TAL Validation . . . . . . . . . . . . . . . . . . 5 65 4. Signed TAL Generation . . . . . . . . . . . . . . . . . . . . 5 66 5. Signed TAL Publication . . . . . . . . . . . . . . . . . . . 6 67 6. Performing a planned Key Roll as a Trust Anchor . . . . . . . 6 68 6.1. Prepare a new Trust Anchor key and CA certificate . . . . 7 69 6.2. Publish the new CA certificate . . . . . . . . . . . . . 7 70 6.3. Verify the validity of the new CA certificate . . . . . . 7 71 6.4. Publish the objects under the current key under the new 72 key . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 6.5. Verify that the validity of objects under the new key . . 7 74 6.6. Publish a Signed TAL as the only object under the current 75 key . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 6.7. Delete the current key . . . . . . . . . . . . . . . . . 8 77 7. Relying Party Use . . . . . . . . . . . . . . . . . . . . . . 8 78 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 79 9. Unplanned Key Roll operations . . . . . . . . . . . . . . . . 9 80 10. Changing a Trust Anchor Certificate URIs . . . . . . . . . . 9 81 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 82 11.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 11.2. File Extension . . . . . . . . . . . . . . . . . . . . . 10 84 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 86 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 14.1. Normative References . . . . . . . . . . . . . . . . . . 10 88 14.2. Informative References . . . . . . . . . . . . . . . . . 11 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 91 1. Requirements notation 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in BCP 96 14 [RFC2119] [RFC8174] when, and only when, they appear in all 97 capitals, as shown here. 99 2. Introduction 101 Trust Anchor Locators (TALs) [I-D.ietf-sidrops-https-tal] are used by 102 Relying Parties in the RPKI to locate and validate Trust Anchor 103 certificates used in RPKI validation. This document defines an RPKI 104 signed object [RFC6488] for a Trust Anchor Locator (TAL) that can be 105 used by Trust Anchors to perform a planned migration to a new key, 106 allowing Relying Parties to discover the new key up to one year after 107 the migration occurred. (Note "one year" is arbitrary, and may be 108 changed in a future version of this document) 110 Note that [RFC5011] describes Automated Updates of DNS Security 111 (DNSSEC) Trust Anchors and can provide some useful insight here as 112 well. However, concepts like a set of Trust Anchors, standby Trust 113 Anchors, and TTLs are not applicable to the RPKI. Therefore, an 114 alternative approach based on already existing concept of the Trust 115 Anchor Locator [I-D.ietf-sidrops-https-tal], and top-down validation 116 of an RPKI Trust Anchor certificate tree, where objects are retrieved 117 from the RPKI repositories, is appropriate. 119 3. Signed TAL definition 121 The Signed TAL makes use of the template for RPKI digitally signed 122 objects [RFC6488], which defines a Crytopgraphic Message Syntax (CMS) 123 [RFC5652] wrapper for the Signed TAL content as well as a generic 124 validation procedure for RPKI signed objects. Therefore, to complete 125 the specification of the Signed TAL (see Section 4 of [RFC6488]), 126 this document defines: 128 o The OID defined in Section 3.1 that identifies the signed object 129 as being a Signed TAL. (This OID appears within the eContentType 130 in the encapContentInfo object as well as the content-type signed 131 attribute in the signerInfo object). 133 o The ASN.1 syntax for the Signed TAL eContent defined in 134 Section 3.2. (This is the payload that specifies the AS being 135 authorized to originate routes as well as the prefixes to which 136 the AS may originate routes.) 138 o Additional steps to the validation steps specified in [RFC6488] 139 required to validate Signed TALs, defined in Section 3.3. 141 3.1. The Signed TAL Content Type 143 This document requests an OID for signed-Tal as follows: 145 signed-Tal OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 146 rsadsi(113549) pkcs(1) pkcs9(9) 16 id-smime (1) TBD } 148 This OID MUST appear both within the eContentType in the 149 encapContentInfo object as well as the content-type signed attribute 150 in the signerInfo object (see [RFC6488]) 152 3.2. The Signed TAL eContent 154 The content of a Signed TAL is ASN.1 encoded using the Distinguished 155 Encoding Rules (DER) [X.690], and is defined as follows: 157 SignedTAL ::= SEQUENCE { 158 version [0] INTEGER DEFAULT 0, 159 activationTime GeneralizedTime, 160 certificateURIs SEQUENCE SIZE (1..MAX) OF CertificateURI, 161 subjectPublicKeyInfo SubjectPublicKeyInfo } 163 CertificateURI ::= IA5String 165 SubjectPublicKeyInfo ::= IA5String 167 3.2.1. version 169 The version number of the SignedTAL MUST be 0. 171 3.2.2. activationTime 173 This field contains the time when this TAL is intended to replace any 174 previously known TAL for this Trust Anchor. 176 3.2.3. certificateURIs 178 This field is equivalent to the URI section in section 2.1 of 179 [I-D.ietf-sidrops-https-tal]. It MUST contain at least one 180 CertificateURI element. Each CertificateURI element contains the 181 IA5String representation of either an rsync URI [RFC5781], or an 182 HTTPS URI [RFC7230]. 184 3.2.4. subjectPublicKeyInfo 186 This field is equivalent to the subjectPublicKeyInfo section in 187 section 2.1 of [I-D.ietf-sidrops-https-tal]. 189 3.3. Signed TAL Validation 191 To determine whether a Signed TAL is valid, the RP MUST perform the 192 following steps in addition to those specified in [RFC6488]: 194 o The eContentType OID matches the OID described in Section 3.1 196 o The Signed TAL appears as the product of a Trust Anchor CA 197 certificate. 199 o This Trust Anchor CA has published only one Signed TAL object in 200 its repository, and this object appears on the Manifest as the 201 only entry using the ".tal" extension (see [RFC6481]). In case 202 more than one Signed TAL object is found, all such objects MUST be 203 considered invalid. 205 o The EE certificate of this Signed TAL describes its Internet 206 Number Resources (INRs) using the "inherit" attribute 208 o The decoded TAL content conforms to the format defined in 209 Section 3.2. 211 If the above procedure indicates that the manifest is invalid, then 212 the Signed TAL MUST be discarded and treated as though no Signed TAL 213 were present. 215 4. Signed TAL Generation 217 A TA MAY choose to generate a single Singed TAL object to publish in 218 its TA certificate publication point(s) in the RPKI. The TA MUST 219 perform the following steps to generate the Signed TAL: 221 o Generate a key pair for a "one-time-use" EE certificate to use for 222 the Signed TAL 224 o Generate a one-time-use EE certificate for the Signed TAL 226 o This EE certificate MUST have an SIA extension access description 227 field with an accessMethod OID value of id-ad-signedobject, where 228 the associated accessLocation references the publication point of 229 the Sigend TAL as an object URL. 231 o As described in [RFC6487], an [RFC3779] extension is required in 232 the EE certificate used for this object. However, because the 233 resource set is irrelevant to this object type, this certificate 234 MUST describe its Internet Number Resources (INRs) using the 235 "inherit" attribute, rather than explicit description of a 236 resource set. 238 o This EE certificate MUST have a "notBefore" time that is before 239 the moment that the Signed TAL will be published. 241 o This EE certificate MUST have a "notAfter" time that reflects the 242 intended time that this Signed TAL will be published. If the EE 243 certificate for a Signed TAL is expired, it MUST no longer be 244 publish, but of course it MAY be replaced by a newly generated 245 Signed TAL object with similar content and an updated "notAfter" 246 time. 248 o The Signed TAL MUST have an "activationTime" that reflects when 249 Relying Parties MUST use use this new TAL in place of any 250 previously known TAL for this Trust Anchor. 252 5. Signed TAL Publication 254 A TA MAY publish a single Signed TAL object directly under its CA 255 repository publication points. The TA MUST NOT publish multiple 256 Signed TAL objects at any time. It is RECOMMENDED that a TA 257 publishes a Signed TAL object for its current key and CA certificate 258 publication URIs at all times. 260 A non-normative guideline for naming this object is that the filename 261 chosen for the signed TAL in the publication repository be a value 262 derived from the public key part of the entity's key pair, using the 263 algorithm described for CRLs in section 2.2 of [RFC6481] for 264 generation of filenames. The filename extension of ".tal" MUST be 265 used to denote the object as a signed TAL. Note that this is in-line 266 with filename extensions defined in section 7.2 of [RFC6481] 268 6. Performing a planned Key Roll as a Trust Anchor 270 A Signed TAL SHOULD be used to communicate a planned key roll by a 271 Trust Anchor. From the Trust Anchor perspective a planned key roll 272 consists of the following steps: 274 o Prepare a new Trust Anchor key and CA certificate, see Section 6.1 276 o Publish the new CA certificate, see Section 6.2 278 o Verify the validity of the new CA certificate, see Section 6.3 280 o Publish the objects under the current key under the new key, see 281 Section 6.4 283 o Verify that the validity of objects under the new key, see 284 Section 6.5 286 o Publish a Signed TAL as the only object under the current key, see 287 Section 6.6 289 o Delete the current key, see Section 6.7 291 6.1. Prepare a new Trust Anchor key and CA certificate 293 The Trust Anchors MUST a new key pair and generate a new TA 294 Certificate. For the Subject Information Access (see section 4.8.8.1 295 of [RFC6487]) this MUST use URIs that will be used by the new key to 296 publish objects. These URIs MUST be uniqe for use by this new key 297 only. The Internet Number Resources on this new certificate MUST be 298 equivalent to those found on the current certificate. 300 6.2. Publish the new CA certificate 302 The new CA certificate MUST be published under one or more new 303 Certificate URIs for use by this new key only. 305 6.3. Verify the validity of the new CA certificate 307 The Trust Anchor MUST generate a new (unsigned) TAL file 308 [I-D.ietf-sidrops-https-tal] and verify with RP software that the new 309 Trust Anchor certificate can be retrieved from all locations and that 310 it matches the subjectPublicKeyInfo 312 6.4. Publish the objects under the current key under the new key 314 ALL current signed certificates and other objects, with the exception 315 of the CRL, Manifest and existing Signed TAL, must be re-issued by 316 the new key and published under the new publication point(s). 318 It is RECOMMENDED that a new Signed TAL object is generated and 319 published, listing the Certificate URIs for this new key, the 320 subjectPublicKeyInfo of this new key, and using an "activationTime" 321 that is effective immediately. Note that Relying Parties will not 322 discover this new Signed TAL object until they have effectively 323 switched over from the current key. 325 6.5. Verify that the validity of objects under the new key 327 The Trust Anchor MUST verify that validation using the new TAL file 328 generated in Section 6.3 results in the set of valid objects as when 329 the current TAL file is used. 331 6.6. Publish a Signed TAL as the only object under the current key 333 The Trust Anchor MUST publish a new Signed TAL, CRL and Manifest as 334 the only objects under the current, to be deleted, key. The 335 "nextUpdate" values of the Manifest and CRL objects SHOULD use a date 336 that is set at least one year into the future. (arbitrary value, open 337 to suggestions). The "notValidAfter" date on the Manifest and Signed 338 TAL EE certificate SHOULD use this same date. The Trust Anchor MUST 339 ensure that this Signed TAL, CRL and Manifest remain available for 340 download for this full period. Note that this is done to give RPs 341 the opportunity to discover the new key up to one year after the key 342 roll occurred. 344 6.7. Delete the current key 346 As the final step the current key, which has been replaced now, 347 SHOULD be deleted. The new key can now be marked as the current key. 349 7. Relying Party Use 351 When an RP discovers a valid Signed TAL signed under a TA, and it 352 notices that the "subjectPublicKeyInfo" has changed and/or the set of 353 "Certificate URIs" has changed from the values it knew for this TA, 354 and the "activationTime" is in the past, then the RP MUST accept 355 these new values for this TA, abort the current top-down validation 356 operation, and initiate a new top-down validation operation using the 357 updated information. 359 Note that the Trust Anchor MUST have verified that all objects are 360 available under the new key (Section 6.5) and that that the TA CA 361 certificate can be retrieved and validated for all new URIs 362 (Section 6.3). 364 8. Deployment Considerations 366 Including Signed TAL objects while RP tools do not support this 367 standard will result in these RPs rejecting these objects. It is not 368 expected that this will result in the invalidation of any other 369 object under a Trust Anchor. 371 That said, the flagging mechanism introduced here can only be trusted 372 on once a majority of RPs support it. Defining when that moment 373 arrives is by definition something that cannot be established at the 374 time of writing this document. 376 However, once the majority of RPs support this mechanism it would be 377 RECOMMENDED that Trust Anchor operators perform key rolls regularly. 379 The most assured way to know that such planned rolls will work is by 380 making them a part of normal operations. 382 9. Unplanned Key Roll operations 384 The mechanism described in this document is not applicable to 385 uplanned key rolls. Unplanned key rolls could theoretically be 386 supported by a mechanism where a new key is introduced before it's 387 used, with the power to revoke the current key. This would have to 388 be signalled from the new key, as the TA may have lost access to its 389 current key. 391 However, this introduces a great amount of operational complexity as 392 well as a new vulnerability: an adversary would need access to only 393 one of these keys in order to compromise a TA. 395 With that in mind we believe, for now, that unplanned key rolls 396 should not be covered here, and would need to be communicated to 397 Relying Parties in some other out-of-band fashion. 399 10. Changing a Trust Anchor Certificate URIs 401 Earlier versions of this document included a description of how 402 Signed TAL objects could be used to signal a change of Certificate 403 URIs only; i.e. where the key is not changed. 405 However, Relying Parties that do not support the mechanism described 406 in this document would not be able to learn about the changes in 407 URIs. While for RPs that do support this mechanism a planned key 408 roll will be a normal part of RPKI validation. 410 Therefore we believe that a planned key roll should be used in cases 411 like this, and that the set of Certificate URIs for any given key 412 must never be changed. 414 11. IANA Considerations 416 11.1. OID 418 IANA is to add the following to the "RPKI Signed Objects" registry: 420 Decimal | Description | References 421 --------+--------------------------------+--------------- 422 TBD | signed-Tal | [section 3.1] 424 11.2. File Extension 426 IANA is to add an item for the Signed TAL file extension to the "RPKI 427 Repository Name Scheme" created by [RFC6481] as follows: 429 Extension | RPKI Object | References 430 -----------+------------------------------------------- 431 .tal | Signed TAL | [this document] 433 12. Security Considerations 435 TBD 437 13. Acknowledgements 439 TBD 441 14. References 443 14.1. Normative References 445 [I-D.ietf-sidrops-https-tal] 446 Huston, G., Weiler, S., Michaelson, G., Kent, S., and T. 447 Bruijnzeels, "Resource Public Key Infrastructure (RPKI) 448 Trust Anchor Locator", draft-ietf-sidrops-https-tal-03 449 (work in progress), June 2018. 451 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 452 Requirement Levels", BCP 14, RFC 2119, 453 DOI 10.17487/RFC2119, March 1997, 454 . 456 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 457 Addresses and AS Identifiers", RFC 3779, 458 DOI 10.17487/RFC3779, June 2004, 459 . 461 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 462 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 463 September 2007, . 465 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 466 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 467 . 469 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 470 Resource Certificate Repository Structure", RFC 6481, 471 DOI 10.17487/RFC6481, February 2012, 472 . 474 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 475 X.509 PKIX Resource Certificates", RFC 6487, 476 DOI 10.17487/RFC6487, February 2012, 477 . 479 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 480 Template for the Resource Public Key Infrastructure 481 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 482 . 484 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 485 Protocol (HTTP/1.1): Message Syntax and Routing", 486 RFC 7230, DOI 10.17487/RFC7230, June 2014, 487 . 489 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 490 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 491 May 2017, . 493 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 494 "Information technology - ASN.1 encoding rules: 495 Specification of Basic Encoding Rules (BER), Canonical 496 Encoding Rules (CER) and Distinguished Encoding Rules 497 (DER)", 2002. 499 14.2. Informative References 501 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 502 RFC 5652, DOI 10.17487/RFC5652, September 2009, 503 . 505 Authors' Addresses 507 Tim Bruijnzeels 508 NLnet Labs 510 Email: tim@nlnetlabs.nl 511 URI: https://www.nlnetlabs.nl/ 512 Carlos Martinez 513 LACNIC 515 Email: carlos@lacnic.net 516 URI: https://www.lacnic.net/