idnits 2.17.00 (12 Aug 2021) /tmp/idnits54798/draft-ietf-sidrops-signed-tal-09.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 document date (7 March 2022) is 68 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 Summary: 1 error (**), 0 flaws (~~), 0 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Martinez 3 Internet-Draft LACNIC 4 Intended status: Standards Track G. Michaelson 5 Expires: 8 September 2022 T. Harrison 6 APNIC 7 T. Bruijnzeels 8 NLnet Labs 9 R. Austein 10 Dragon Research Labs 11 7 March 2022 13 RPKI Signed Object for Trust Anchor Key 14 draft-ietf-sidrops-signed-tal-09 16 Abstract 18 A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the 19 Resource Public Key Infrastructure (RPKI) to locate and validate a 20 Trust Anchor (TA) Certification Authority (CA) certificate used in 21 RPKI validation. This document defines an RPKI signed object for a 22 Trust Anchor Key (TAK), that can be used by a TA to signal the 23 location(s) of the accompanying CA certificate for the current key to 24 RPs, as well as the successor key and the location(s) of its CA 25 certificate. This object helps to support planned key rolls without 26 impacting RPKI validation. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 8 September 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 62 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. TAK Object Definition . . . . . . . . . . . . . . . . . . . . 4 64 3.1. The TAK Object Content Type . . . . . . . . . . . . . . . 4 65 3.2. The TAK Object eContent . . . . . . . . . . . . . . . . . 4 66 3.2.1. TAKey . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.2.2. TAK . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.3. TAK Object Validation . . . . . . . . . . . . . . . . . . 5 69 4. TAK Object Generation and Publication . . . . . . . . . . . . 6 70 5. Relying Party Use . . . . . . . . . . . . . . . . . . . . . . 7 71 6. Maintaining Multiple TA Keys . . . . . . . . . . . . . . . . 9 72 7. Performing TA Key Rolls . . . . . . . . . . . . . . . . . . . 10 73 7.1. Phase 1: Add a TAK for Key 'A' . . . . . . . . . . . . . 10 74 7.2. Phase 2: Add a Key 'B' . . . . . . . . . . . . . . . . . 10 75 7.3. Phase 3: Update TAL to point to 'B' . . . . . . . . . . . 11 76 7.4. Phase 4: Remove Key 'A' . . . . . . . . . . . . . . . . . 11 77 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 11 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 10.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 10.2. File Extension . . . . . . . . . . . . . . . . . . . . . 13 82 10.3. Module Identifier . . . . . . . . . . . . . . . . . . . 13 83 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 84 11.1. APNIC . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 12. Revision History . . . . . . . . . . . . . . . . . . . . . . 14 86 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 87 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 14.1. Normative References . . . . . . . . . . . . . . . . . . 15 89 14.2. Informative References . . . . . . . . . . . . . . . . . 16 90 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 93 1. Requirements Notation 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in BCP 98 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 2. Overview 103 A TAL [RFC8630] is used by an RP in the RPKI to locate and validate 104 TA CA certificates used in RPKI validation. However, until now there 105 has been no in-band way of notifying RPs of updates to a TAL. In- 106 band notification means that TAs can be more confident of RPs being 107 aware of key roll operations. 109 This document defines a new RPKI signed object that can be used to 110 document the location(s) of the TA CA certificate for the current TA 111 key, as well as the value of the successor key and the location(s) of 112 its TA CA certificate. This allows RPs to be notified automatically 113 of such changes, and enables TAs to stage a successor key so that 114 planned key rolls can be performed without risking the invalidation 115 of the RPKI tree under the TA. We call this object the Trust Anchor 116 Key (TAK) object. 118 When RPs are first bootstrapped, they use a TAL to discover the key 119 and location(s) of the CA certificate for a TA. The RP can then 120 retrieve and validate the CA certificate, and subsequently validate 121 the manifest [RFC6486] and CRL published by that TA (section 5 of 122 [RFC6487]). However, before processing any other objects it will 123 first validate the TAK object, if present. If the TAK object lists 124 only the current key, then the RP continues processing as per normal. 125 If the TAK object includes a successor key, the RP starts an 126 acceptance timer, and then continues processing as per normal. If, 127 during the following validation runs up until the expiry of the 128 acceptance timer, the RP has not observed any changes to the keys and 129 certificate URLs listed in the TAK object, then the RP will fetch the 130 successor key, update its local state with that key and its 131 associated certification location(s), and continue processing using 132 that key. 134 The primary motivation for this work is being able to migrate from a 135 Hardware Security Module (HSM) produced by one vendor to one produced 136 by another, where the first vendor does not support exporting keys 137 for use by the second. There may be other scenarios in which key 138 rollover is useful, though. 140 3. TAK Object Definition 142 The TAK object makes use of the template for RPKI digitally signed 143 objects [RFC6488], which defines a Cryptographic Message Syntax (CMS) 144 [RFC5652] wrapper for the content as well as a generic validation 145 procedure for RPKI signed objects. Therefore, to complete the 146 specification of the TAK object (see Section 4 of [RFC6488]), this 147 document defines: 149 * The OID (in Section 3.1) that identifies the signed object as 150 being a TAK. (This OID appears within the eContentType in the 151 encapContentInfo object, as well as the content-type signed 152 attribute in the signerInfo object.) 154 * The ASN.1 syntax for the TAK eContent, in Section 3.2. 156 * The additional steps required to validate a TAK, in Section 3.3. 158 3.1. The TAK Object Content Type 160 This document requests an OID for the TAK object as follows: 162 id-ct-signed-Tal OBJECT IDENTIFIER ::= 163 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 164 smime(16) id-smime ct(1) TBD } 166 This OID MUST appear both within the eContentType in the 167 encapContentInfo object, as well as the content-type signed attribute 168 in the signerInfo object (see [RFC6488]). 170 3.2. The TAK Object eContent 172 The content of a TAK object is ASN.1 encoded using the Distinguished 173 Encoding Rules (DER) [X.690], and is defined per the module in 174 Appendix A. 176 3.2.1. TAKey 178 This structure defines a TA key, similarly to [RFC8630]. It contains 179 a sequence of one or more URIs and a SubjectPublicKeyInfo. 181 3.2.1.1. certificateURIs 183 This field is equivalent to the URI section defined in section 2.2 of 184 [RFC8630]. It MUST contain at least one CertificateURI element. 185 Each CertificateURI element contains the IA5String representation of 186 either an rsync URI [RFC5781], or an HTTPS URI [RFC7230]. 188 3.2.1.2. subjectPublicKeyInfo 190 This field contains a SubjectPublicKeyInfo (section 4.1.2.7 of 191 [RFC5280]) in DER format [X.690]. 193 3.2.2. TAK 195 3.2.2.1. version 197 The version number of the TAK object MUST be 0. 199 3.2.2.2. current 201 This field contains the TA key of the repository in which the TAK 202 object is published. 204 3.2.2.3. predecessor 206 This field contains the TA key that was in use for this TA 207 immediately prior to the current TA key, if applicable. 209 3.2.2.4. successor 211 This field contains the TA key to be used in place of the current 212 key, after expiry of the relevant acceptance timer. 214 3.3. TAK Object Validation 216 To determine whether a TAK object is valid, the RP MUST perform the 217 following checks in addition to those specified in [RFC6488]: 219 * The eContentType OID matches the OID described in Section 3.1. 221 * The TAK object appears as the product of a TA CA certificate (i.e. 222 the TA CA certificate is itself the issuer of the EE certificate 223 of the TAK object). 225 * The TA CA has published only one TAK object in its repository for 226 this key, and this object appears on the manifest as the only 227 entry using the ".tak" extension (see [RFC6481]). 229 * The EE certificate of this TAK object describes its Internet 230 Number Resources (INRs) using the "inherit" attribute. 232 * The decoded TAK content conforms to the format defined in 233 Section 3.2. 235 * The SubjectPublicKeyInfo value of the current TA key in the TAK 236 object matches that of the TA CA certificate used to issue the EE 237 certificate of the TAK object. 239 If any of these checks does not succeed, the RP MUST ignore the TAK 240 object, and proceed as though it were not listed on the manifest. 242 The RP is not required to compare its current set of certificateURIs 243 for the current key with those listed in the TAK object. The RP MAY 244 alert the user that these sets of certificateURIs do not match, with 245 a view to the user manually updating the set of certificateURIs in 246 their configuration. The RP MUST NOT automatically update its 247 configuration to use these certificateURIs in the event of 248 inconsistency, though, because migration of users to new 249 certificateURIs should happen by way of the successor key process. 251 4. TAK Object Generation and Publication 253 A TA MAY choose to use TAK objects to communicate its current, 254 predecessor, and successor keys. If a TA chooses to use TAK objects, 255 then it SHOULD generate and publish TAK objects under each of its 256 keys. 258 A non-normative guideline for naming this object is that the filename 259 chosen for the TAK object in the publication repository be a value 260 derived from the public key part of the entity's key pair, using the 261 algorithm described for CRLs in section 2.2 of [RFC6481] for 262 generation of filenames. The filename extension of ".tak" MUST be 263 used to denote the object as a TAK. 265 In order to generate a TAK object, the TA MUST perform the following 266 actions: 268 * The TA MUST generate a key pair for a "one-time-use" EE 269 certificate to use for the TAK. 271 * The TA MUST generate a one-time-use EE certificate for the TAK. 273 * This EE certificate MUST have an SIA extension access description 274 field with an accessMethod OID value of id-ad-signedObject, where 275 the associated accessLocation references the publication point of 276 the TAK as an object URL. 278 * As described in [RFC6487], an [RFC3779] extension is required in 279 the EE certificate used for this object. However, because the 280 resource set is irrelevant to this object type, this certificate 281 MUST describe its Internet Number Resources (INRs) using the 282 "inherit" attribute, rather than explicit description of a 283 resource set. 285 * This EE certificate MUST have a "notBefore" time that matches or 286 predates the moment that the TAK will be published. 288 * This EE certificate MUST have a "notAfter" time that reflects the 289 intended duration for which this TAK will be published. If the EE 290 certificate for a TAK object is expired, it MUST no longer be 291 published, but it MAY be replaced by a newly generated TAK object 292 with equivalent content and an updated "notAfter" time. 294 * The current TA key for the TAK MUST match that of the TA CA 295 certificate under which the TAK was issued. 297 5. Relying Party Use 299 Relying Parties MUST keep a record of the current key for each 300 configured TA, as well as the URI(s) where the CA certificate for 301 this key may be retrieved. This record is typically bootstrapped by 302 the use of a pre-configured (and unsigned) TAL file [RFC8630]. 304 When performing top-down validation, RPs MUST first validate and 305 process the TAK object for its current known key, by performing the 306 following steps: 308 * A CA certificate is retrieved and validated from the known URIs as 309 described in sections 3 and 4 of [RFC8630]. 311 * The manifest and CRL for this certificate are then validated as 312 described in [RFC6487] and [RFC6486]. 314 * The TAK object, if present, is validated as described in 315 Section 3.3. 317 If the TAK object includes a successor key, then the RP must verify 318 the successor key by doing the following: 320 * performing top-down validation using the successor key, in order 321 to validate the TAK object for the successor TA; 323 * ensuring that a valid TAK object exists for the successor TA; 324 * ensuring that the successor TAK object's current key matches the 325 initial TAK object's successor key; and 327 * ensuring that the successor TAK object's predecessor key matches 328 the initial TAK object's current key. 330 If any of these steps fails, then the successor key has failed 331 verification. 333 If the successor key passes verification, and the RP has not seen 334 that successor key on the previous successful validation run for this 335 TA, then the RP: 337 * sets an acceptance timer of 30 days for this successor key for 338 this TA; 340 * cancels the existing acceptance timer for this TA (if applicable); 341 and 343 * continues standard top-down validation as described in [RFC6487] 344 using the current key. 346 If the successor key passes verification, and the RP has seen that 347 successor key on the previous successful validation run for this TA: 349 * if the relevant acceptance timer has not expired, the RP continues 350 standard top-down validation using the current key; 352 * otherwise, the RP updates its current known key details for this 353 TA to be those of the successor key, and then begins top-down 354 validation again using the successor key. 356 If the successor key does not pass verification, or if the TAK object 357 does not include a successor key, the RP cancels the existing 358 acceptance timer for this TA (if applicable). 360 An RP MUST NOT use a successor key for top-down validation outside of 361 the process described above, except for the purpose of testing that 362 the new key is working correctly. This allows a TA to publish a 363 successor key for a period of time, allowing RPs to test it, while 364 still being able to rely on RPs using the current key for their 365 production RPKI operations. 367 A successor key may have the same SubjectPublicKeyInfo value as the 368 current key: this will be the case where a TA is updating the 369 certificateURIs for that key. 371 6. Maintaining Multiple TA Keys 373 Although an RP that can process TAK objects will only ever use one 374 key for validation (either the current key, or the successor key, 375 once the relevant acceptance timer has expired), an RP that cannot 376 process TAK objects will continue to use the key details per its TAL 377 (or equivalent manual configuration) indefinitely. As a result, even 378 when a TA is using a TAK object in order to migrate clients to a new 379 key, the TA may have to maintain the previous key for a period of 380 time alongside the new key in order to ensure continuity of service 381 for older clients. 383 For each TA key that a TA is maintaining, the signed material for 384 these keys MUST be published under different directories in the 385 context of the 'id-ad-caRepository' and 'id-ad-rpkiManifest' Subject 386 Information Access descriptions contained on the CA certificates 387 [RFC6487]. Publishing objects under the same directory is 388 potentially confusing for RPs, and could lead to object invalidity in 389 the event of file name collisions. 391 Also, the CA certificates for each maintained key, and the contents 392 published by each key, MUST be equivalent (except for the TAK 393 object). In other words, for the purposes of RPKI validation, it 394 MUST NOT make a difference which of the keys is used as a starting 395 point. 397 This means that the IP and AS resources contained on all current CA 398 certificates for the maintained TA keys MUST be the same. 399 Furthermore, for any delegation of IP and AS resources to a child, 400 the TA MUST have an equivalent CA certificate published under each of 401 its keys. Any updates in delegations MUST be reflected under each of 402 its keys. A TA SHOULD NOT publish any other objects besides a CRL, a 403 Manifest, a single TAK object, and any number of CA certificates for 404 delegation to child CAs. 406 If a TA uses a single remote publication server for its keys, per 407 [RFC8181], then it MUST include all and PDUs 408 for the products of each of its keys in a single query, in order to 409 ensure that they will reflect the same content at all times. 411 If a TA uses multiple publication servers, then it is by definition 412 inevitable that the content of different keys will be out of sync at 413 times. In such cases, the TA SHOULD ensure that the duration of 414 these moments are limited to the shortest possible time. 415 Furthermore, the following should be observed: 417 * In cases where a CA certificate is revoked completely, or replaced 418 by a certificate with a reduced set of resources, these changes 419 will not take effect fully until all the relevant repository 420 publication points have been updated. Given that TA key 421 operations are normally performed infrequently, this is unlikely 422 to be a problem: if the revocation or shrinking of an issued CA 423 certificate is staged for days/weeks, then experiencing a delay of 424 several minutes for the repository publication points to be 425 updated is fairly insignificant. 427 * In cases where a CA certificate is replaced by a certificate with 428 an extended set of resources, the TA MUST inform the receiving CA 429 only after all of its repository publication points have been 430 updated. This ensures that the receiving CA will not issue any 431 products that could be invalid if an RP uses a TA key just before 432 the CA certificate was due to be updated. 434 Finally, note that the publication locations of CA certificates for 435 delegations to child CAs under each key will be different, and 436 therefore the Authority Information Access 'id-ad-caIssuers' values 437 (section 4.8.7 of [RFC6487]) on certificates issued by the child CAs 438 may not be as expected when performing top-down validation, depending 439 on the TA key that is used. However, these values are not critical 440 to top-down validation, so RPs performing such validation MUST NOT 441 reject a certificate simply because this value is not as expected. 443 7. Performing TA Key Rolls 445 In this section we will describe how present-day RPKI TAs that use 446 only one key pair, and that do not use TAK objects, can use a TAK 447 object to perform a planned key roll. 449 7.1. Phase 1: Add a TAK for Key 'A' 451 Before adding a successor key, a TA may want to confirm that it can 452 maintain a TAK object for its current key only. We will refer to 453 this key as key 'A' throughout this section. 455 7.2. Phase 2: Add a Key 'B' 457 The TA can now generate a new key pair for key 'B'. This key MUST 458 now be used to create a new CA certificate for this key, and to issue 459 equivalent CA certificates for delegations to child CAs, as described 460 in Section 6. 462 At this point, the TA can also construct a new TAL file [RFC8630] for 463 key 'B', and test locally that the validation outcome for the new key 464 is equivalent to that of the other current key(s). 466 When the TA is certain that both keys are equivalent, and wants to 467 initiate the migration from 'A' to 'B', it issues a new TAK object 468 under key 'A', with key 'A' as the current key for that object, key 469 'B' as the successor key, and no predecessor key. It also issues a 470 TAK object under key 'B', with key 'B' as the current key for that 471 object, key 'A' as the predecessor key, and no successor key. 473 Once this has happened, RP clients will start seeing the new key and 474 setting acceptance timers accordingly. 476 7.3. Phase 3: Update TAL to point to 'B' 478 At about the time that the TA expects clients to start setting key 479 'B' as the current key, the TA must release a new TAL file for key 480 'B'. It SHOULD use a different set of URIs in the TAL compared to 481 the TAK file, so that the TA can learn the proportion of RPs that can 482 successfully validate and use the updated TAK objects. 484 To support RPs that do not take account of TAK objects, the TA should 485 continue operating key 'A' for a period of time after the expected 486 migration of clients to 'B'. The length of that period of time is a 487 local policy matter for that TA: it might operate the key until no 488 clients are attempting to validate using it, for example. 490 7.4. Phase 4: Remove Key 'A' 492 The TA SHOULD now remove all content from the repository used by key 493 'A', and destroy the private key for key 'A'. RPs attempting to rely 494 on a TAL for key 'A' from this point will not be able to perform RPKI 495 validation for the TA, and will have to update their local state 496 manually, by way of a new TAL file. 498 8. Deployment Considerations 500 Including TAK objects while RPs do not support this standard will 501 result in those RPs rejecting these objects. It is not expected that 502 this will result in the invalidation of any other object under a 503 Trust Anchor. 505 The mechanism introduced here can only be relied on once a majority 506 of RPs support it. Defining when that moment arrives is something 507 that cannot be established at the time of writing this document. The 508 use of unique URIs for keys in TAK objects, different from those used 509 for the corresponding TAL files, should help TAs understand the 510 proportion of RPs that support this mechanism. 512 Some RPs may purposefully not support this mechanism: for example, 513 they may be implemented or configured such that they are unable to 514 update local current key data. TAs should take this into 515 consideration when planning key rollover. However, these RPs would 516 ideally still notify their operators of planned key rollovers, so 517 that the operator could update the relevant configuration manually. 519 9. Security Considerations 521 A TA needs to consider the length of time for which it will maintain 522 previously-current keys and their associated repositories. An RP 523 that is seeded with old TAL data will run for 30 days using the 524 previous key before migrating to the next key, due to the acceptance 525 timer requirements, and this 30-day delay applies to each new key 526 that has been issued since the old TAL data was initially published. 527 It may be better in these instances to have the old publication URLs 528 simply fail to resolve, so that the RP reports an error to its 529 operator and the operator seeds it with up-to-date TAL data 530 immediately. 532 Once a TA has decided not to maintain a previously-current key and 533 its associated repository, it needs to consider how to protect 534 against an adversary gaining access to that key and its associated 535 publication points in order to send invalid/incorrect data to RPs 536 seeded with the TAL data for that key. One possible mitigation here 537 is to reuse the TA CA certificate URLs from that TAL data for newer 538 keys. 540 The use of acceptance timers means that an adversary that gains 541 access to a TA's current key is not able to migrate RPs to a new key 542 without delay. Although access to that key does permit arbitrary 543 action within the corresponding TA (assuming that the adversary has 544 control over the relevant publication points), being unable to 545 migrate RPs to a new key means that it is possible for the TA 546 operator to regain control over the key and the TA itself, such that 547 it may not be necessary for all RPs to carry out manual 548 reconfiguration. 550 If an adversary gains access to the key listed as the successor to a 551 TA's current key (i.e. listed as the successor, but the acceptance 552 timer period has not yet elapsed since it was listed), the TA 553 operator can recover from this by simply removing the successor key 554 from the TAK object. 556 In general, the risk of key compromise can be mitigated by the use of 557 Hardware Security Modules (HSMs) by TAs, which will guard against 558 theft of a private key, as well as operational processes to guard 559 against (accidental) misuse of the keys in an HSM by operators. 561 Alternate models of TAL update exist and can be complementary to this 562 mechanism. For example, TAs can liaise directly with validation 563 software developers to include updated and reissued TAL files in new 564 code releases, and use existing code update mechanisms in the RP 565 community to distribute the changes. 567 10. IANA Considerations 569 10.1. OID 571 IANA is asked to add the following to the "RPKI Signed Objects" 572 registry: 574 Decimal | Description | References 575 --------+--------------------------------+--------------- 576 TBD | Trust Anchor Key | [section 3.1] 578 10.2. File Extension 580 IANA is asked to add an item for the Signed TAL file extension to the 581 "RPKI Repository Name Scheme" created by [RFC6481] as follows: 583 Extension | RPKI Object | References 584 -----------+------------------------------------------- 585 .tak | Trust Anchor Key | [this document] 587 10.3. Module Identifier 589 IANA is asked to register an object identifier for one module 590 identifier in the "SMI Security for S/MIME Module Identifier 591 (1.2.840.113549.1.9.16.0)" registry as follows: 593 Decimal | Description | References 594 --------+--------------------------------+--------------- 595 TBD | Trust Anchor Key | [section 3.1] 597 * Description: RPKISignedTrustAnchorList-2021 599 * OID: 1.2.840.113549.1.9.16.0.TBD 601 * Specification: [this document] 603 11. Implementation Status 605 NOTE: Please remove this section and the reference to RFC 7942 prior 606 to publication as an RFC. 608 This section records the status of known implementations of the 609 protocol defined by this specification at the time of posting of this 610 Internet-Draft, and is based on a proposal described in [RFC7942]. 611 The description of implementations in this section is intended to 612 assist the IETF in its decision processes in progressing drafts to 613 RFCs. Please note that the listing of any individual implementation 614 here does not imply endorsement by the IETF. Furthermore, no effort 615 has been spent to verify the information presented here that was 616 supplied by IETF contributors. This is not intended as, and must not 617 be construed to be, a catalog of available implementations or their 618 features. Readers are advised to note that other implementations may 619 exist. 621 According to RFC 7942, "this will allow reviewers and working groups 622 to assign due consideration to documents that have the benefit of 623 running code, which may serve as evidence of valuable experimentation 624 and feedback that have made the implemented protocols more mature. 625 It is up to the individual working groups to use this information as 626 they see fit". 628 11.1. APNIC 630 * Responsible Organization: Asia-Pacific Network Information Centre 632 * Location: https://github.com/APNIC-net/rpki-signed-tal-demo 634 * Description: A proof-of-concept for relying party TAK usage. 636 * Level of Maturity: This is a proof-of-concept implementation. 638 * Coverage: This implementation includes all of the features 639 described in version 08 of this specification. The repository 640 includes a link to various test TALs that can be used for testing 641 TAK scenarios, too. 643 * Contact Information: Tom Harrison, tomh@apnic.net 645 12. Revision History 647 03 - Last draft under Tim's authorship. 649 04 - First draft with George's authorship. No substantive revisions. 651 05 - First draft with Tom's authorship. No substantive revisions. 653 06 - Rob Kisteleki's critique. 655 07 - Switch to two-key model. 657 08 - Keepalive. 659 09 - Acceptance timers, predecessor keys, no long-lived CRL/MFT. 661 13. Acknowledgments 663 The authors wish to thank Martin Hoffmann for a thorough review of 664 this document, and Russ Housley for reviewing the ASN.1 definitions 665 and providing a new module for the TAK object. 667 14. References 669 14.1. Normative References 671 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 672 Requirement Levels", BCP 14, RFC 2119, 673 DOI 10.17487/RFC2119, March 1997, 674 . 676 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 677 Addresses and AS Identifiers", RFC 3779, 678 DOI 10.17487/RFC3779, June 2004, 679 . 681 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 682 Housley, R., and W. Polk, "Internet X.509 Public Key 683 Infrastructure Certificate and Certificate Revocation List 684 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 685 . 687 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 688 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 689 . 691 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 692 Resource Certificate Repository Structure", RFC 6481, 693 DOI 10.17487/RFC6481, February 2012, 694 . 696 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 697 "Manifests for the Resource Public Key Infrastructure 698 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 699 . 701 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 702 X.509 PKIX Resource Certificates", RFC 6487, 703 DOI 10.17487/RFC6487, February 2012, 704 . 706 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 707 Template for the Resource Public Key Infrastructure 708 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 709 . 711 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 712 Protocol (HTTP/1.1): Message Syntax and Routing", 713 RFC 7230, DOI 10.17487/RFC7230, June 2014, 714 . 716 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 717 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 718 May 2017, . 720 [RFC8181] Weiler, S., Sonalker, A., and R. Austein, "A Publication 721 Protocol for the Resource Public Key Infrastructure 722 (RPKI)", RFC 8181, DOI 10.17487/RFC8181, July 2017, 723 . 725 [RFC8630] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T. 726 Bruijnzeels, "Resource Public Key Infrastructure (RPKI) 727 Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630, 728 August 2019, . 730 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 731 "Information technology - ASN.1 encoding rules: 732 Specification of Basic Encoding Rules (BER), Canonical 733 Encoding Rules (CER) and Distinguished Encoding Rules 734 (DER)", 2002. 736 14.2. Informative References 738 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 739 RFC 5652, DOI 10.17487/RFC5652, September 2009, 740 . 742 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 743 Code: The Implementation Status Section", BCP 205, 744 RFC 7942, DOI 10.17487/RFC7942, July 2016, 745 . 747 Appendix A. ASN.1 Module 749 This appendix includes the ASN.1 module for the TAK object. 751 752 RPKISignedTrustAnchorList-2021 753 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 754 pkcs9(9) smime(16) mod(0) TBD } 756 DEFINITIONS EXPLICIT TAGS ::= 757 BEGIN 759 IMPORTS 761 CONTENT-TYPE 762 FROM CryptographicMessageSyntax-2009 -- in [RFC5911] 763 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 764 pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) } 766 SubjectPublicKeyInfo 767 FROM PKIX1Explicit-2009 -- in [RFC5912] 768 { iso(1) identified-organization(3) dod(6) internet(1) 769 security(5) mechanisms(5) pkix(7) id-mod(0) 770 id-mod-pkix1-explicit-02(51) } ; 772 ct-signedTAL CONTENT-TYPE ::= 773 { TYPE TAK IDENTIFIED BY 774 id-ct-signedTAL } 776 id-ct-signedTAL OBJECT IDENTIFIER ::= { iso(1) member-body(2) 777 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) TBD } 779 CertificateURI ::= IA5String 781 TAKey ::= SEQUENCE { 782 certificateURIs SEQUENCE SIZE (1..MAX) OF CertificateURI, 783 subjectPublicKeyInfo SubjectPublicKeyInfo 784 } 786 TAK ::= SEQUENCE { 787 version INTEGER DEFAULT 0, 788 current TAKey, 789 predecessor TAKey OPTIONAL, 790 successor TAKey OPTIONAL 791 } 793 END 794 796 Authors' Addresses 797 Carlos Martinez 798 LACNIC 799 Email: carlos@lacnic.net 800 URI: https://www.lacnic.net/ 802 George G. Michaelson 803 Asia Pacific Network Information Centre 804 6 Cordelia St 805 South Brisbane 806 QLD 4101 807 Australia 808 Email: ggm@apnic.net 810 Tom Harrison 811 Asia Pacific Network Information Centre 812 6 Cordelia St 813 South Brisbane 814 QLD 4101 815 Australia 816 Email: tomh@apnic.net 818 Tim Bruijnzeels 819 NLnet Labs 820 Email: tim@nlnetlabs.nl 821 URI: https://www.nlnetlabs.nl/ 823 Rob Austein 824 Dragon Research Labs 825 Email: sra@hactrn.net