idnits 2.17.1 draft-ietf-sidrops-signed-tal-07.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 (18 June 2021) is 1014 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 6486 (Obsoleted by RFC 9286) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) 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 C. Martinez 3 Internet-Draft LACNIC 4 Intended status: Standards Track G. Michaelson 5 Expires: 20 December 2021 T. Harrison 6 APNIC 7 T. Bruijnzeels 8 NLnet Labs 9 R. Austein 10 Dragon Research Labs 11 18 June 2021 13 RPKI Signed Object for Trust Anchor Key 14 draft-ietf-sidrops-signed-tal-07 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 both planned and unplanned 26 key rolls without 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 20 December 2021. 45 Copyright Notice 47 Copyright (c) 2021 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 Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . 8 72 7. Performing TA Key Rolls . . . . . . . . . . . . . . . . . . . 9 73 7.1. Phase 1: Add a TAK for Key 'A' . . . . . . . . . . . . . 9 74 7.2. Phase 2: Add a Key 'B' . . . . . . . . . . . . . . . . . 10 75 7.3. Phase 3: Activate Key 'B' . . . . . . . . . . . . . . . . 10 76 7.4. Phase 4: Remove Key 'A' . . . . . . . . . . . . . . . . . 11 77 7.5. Unplanned Direction Roll . . . . . . . . . . . . . . . . 11 78 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 11 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 10.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 10.2. File Extension . . . . . . . . . . . . . . . . . . . . . 12 83 10.3. Module Identifier . . . . . . . . . . . . . . . . . . . 13 84 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 85 11.1. APNIC . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 12. Revision History . . . . . . . . . . . . . . . . . . . . . . 14 87 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 88 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 90 14.2. Informative References . . . . . . . . . . . . . . . . . 16 91 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 16 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 94 1. Requirements Notation 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in BCP 99 14 [RFC2119] [RFC8174] when, and only when, they appear in all 100 capitals, as shown here. 102 2. Overview 104 A TAL [RFC8630] is used by an RP in the RPKI to locate and validate 105 TA CA certificates used in RPKI validation. However, until now there 106 has been no in-band way of notifying RPs of updates to a TAL. In- 107 band notification means that TAs can be more confident of RPs being 108 aware of key roll operations. 110 This document defines a new RPKI signed object that can be used to 111 document the location(s) of the TA CA certificate for the current TA 112 key, as well as the value of the successor key and the location(s) of 113 its TA CA certificate. This allows RPs to be notified automatically 114 of such changes, and enables TAs to pre-stage a successor key so that 115 planned and unplanned key rolls can be performed without risking the 116 invalidation of the RPKI tree under the TA. We call this object the 117 Trust Anchor Key (TAK) object. 119 When RPs are first bootstrapped, they use a TAL to discover the key 120 and location(s) of the CA certificate for a TA. The RP can then 121 retrieve and validate the CA certificate, and subsequently validate 122 the manifest [RFC6486] and CRL published by that TA (section 5 of 123 [RFC6487]). However, before processing any other objects it will 124 first validate the TAK object, if present. If the TAK object 125 indicates that the current key is still valid, then the RP updates 126 its local state to reflect any changes to the certificate location(s) 127 for that current key, and then continues processing as per normal. 128 If the TAK object indicates that the current key has been revoked, 129 then the RP will fetch the successor key, update its local state with 130 that key and its associated certificate location(s), and continue 131 processing using that key. 133 In a situation where an RP is very outdated, it may have to process a 134 large number of TAK objects in order to reach the current TA key. 135 This is a one-time cost only, though, since once the current TA key 136 is recorded as such by the RP, future operations will start at the 137 certificate location(s) for that TA key, and the previous TAK objects 138 will not need to be retrieved again. 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. successor 206 This field contains the TA key to be used once the current key is 207 revoked. 209 3.2.2.4. revoked 211 This field contains a boolean which (if true) indicates that the 212 current TA key should be considered as revoked, in which case RPs 213 should continue processing using the successor TA key. 215 3.3. TAK Object Validation 217 To determine whether a TAK object is valid, the RP MUST perform the 218 following checks in addition to those specified in [RFC6488]: 220 * The eContentType OID matches the OID described in Section 3.1. 222 * The TAK object appears as the product of a TA CA certificate. 224 * The TA CA has published only one TAK object in its repository for 225 this key, and this object appears on the manifest as the only 226 entry using the ".tak" extension (see [RFC6481]). 228 * The EE certificate of this TAK object describes its Internet 229 Number Resources (INRs) using the "inherit" attribute. 231 * The decoded TAK content conforms to the format defined in 232 Section 3.2. 234 * The SubjectPublicKeyInfo value of the current TA key in the TAK 235 object matches that of the TA CA certificate used to issue the EE 236 certificate of the TAK object. 238 If any of these checks does not succeed, the RP MUST ignore the TAK 239 object, and proceed as though it were not listed on the manifest. 241 4. TAK Object Generation and Publication 243 A TA MAY choose to use TAK objects to communicate its current and 244 successor keys. If a TA chooses to use TAK objects, then it SHOULD 245 generate and publish TAK objects under each of its keys. 247 A non-normative guideline for naming this object is that the filename 248 chosen for the TAK object in the publication repository be a value 249 derived from the public key part of the entity's key pair, using the 250 algorithm described for CRLs in section 2.2 of [RFC6481] for 251 generation of filenames. The filename extension of ".tak" MUST be 252 used to denote the object as a TAK. 254 In order to generate a TAK object, the TA MUST perform the following 255 actions: 257 * The TA MUST generate a key pair for a "one-time-use" EE 258 certificate to use for the TAK. 260 * The TA MUST generate a one-time-use EE certificate for the TAK. 262 * This EE certificate MUST have an SIA extension access description 263 field with an accessMethod OID value of id-ad-signedObject, where 264 the associated accessLocation references the publication point of 265 the TAK as an object URL. 267 * As described in [RFC6487], an [RFC3779] extension is required in 268 the EE certificate used for this object. However, because the 269 resource set is irrelevant to this object type, this certificate 270 MUST describe its Internet Number Resources (INRs) using the 271 "inherit" attribute, rather than explicit description of a 272 resource set. 274 * This EE certificate MUST have a "notBefore" time that matches or 275 predates the moment that the TAK will be published. 277 * This EE certificate MUST have a "notAfter" time that reflects the 278 intended duration for which this TAK will be published. If the EE 279 certificate for a TAK object is expired, it MUST no longer be 280 published, but it MAY be replaced by a newly generated TAK object 281 with equivalent content and an updated "notAfter" time. 283 * The current TA key for the TAK MUST match that of the TA CA 284 certificate under which the TAK was issued. 286 5. Relying Party Use 288 Relying Parties MUST keep a record of the current key for each 289 configured TA, as well as the URI(s) where the CA certificate for 290 this key may be retrieved. This record MAY be bootstrapped by the 291 use of a pre-configured (and unsigned) TAL file [RFC8630], but it 292 MUST be updated with authoritative signed information found in valid 293 TAK objects from subsequent validation runs. 295 When performing top-down validation, RPs MUST first validate and 296 process the TAK object for its current known key, by performing the 297 following steps: 299 * A CA certificate is retrieved and validated from the known URIs as 300 described in sections 3 and 4 of [RFC8630]. 302 * The manifest and CRL for this certificate are then validated as 303 described in [RFC6487] and [RFC6486]. 305 * The TAK object, if present, is validated as described in 306 Section 3.3. 308 If the TAK object indicates that the current key has not been 309 revoked, then the RP updates its local state with the URIs for that 310 key from the TAK object and continues standard top-down validation as 311 described in [RFC6487] using that key. 313 If the TAK object indicates that the current key has been revoked, 314 then the RP updates its current known key details to be those of the 315 successor key, and then begins top-down validation again using the 316 successor key. The RP repeats this process until it reaches a TA key 317 that either does not publish a TAK object, or publishes a TAK object 318 that indicates that the corresponding current key is not revoked. At 319 that point, it continues standard top-down validation using that key. 321 If the RP reaches a TAK object that does not include a successor key, 322 but is marked as revoked, then the TA has accidentally revoked its 323 current key. Similarly, if the RP processes the same TAK object 324 twice while attempting to validate a TA, then the TA has accidentally 325 set up a loop among its TAK objects. If the RP encounters either of 326 these scenarios, the RP MUST ignore the TAK objects that it has 327 processed, and proceed as though they were not listed on any of the 328 relevant manifests, so as to allow the TA time to fix the problem. 329 For discussion of how a TA can resolve these problems, see Section 8. 331 An RP MUST NOT use a successor key for top-down validation when the 332 current key is not revoked, except for the purposes of testing that 333 the new key is working correctly. This allows a TA to publish a 334 successor key for a period of time, allowing RPs to test it, while 335 still being able to rely on RPs using the current key for their 336 production RPKI operations. Once any RP problem reports have been 337 resolved, a TA can then revoke the current key to advance the 338 transition. 340 6. Maintaining Multiple TA Keys 342 Although an RP that can process TAK objects will only ever use one 343 key (either the current key, or the successor key if the current key 344 is revoked), an RP that cannot process TAK objects will continue to 345 use the current key even when it is marked as revoked in the TAK. As 346 a result, even when a TA has revoked a key, the TA may have to 347 maintain that key for a period of time alongside the new key in order 348 to ensure continuity of service for older clients. 350 If a TA has multiple TA keys, then the signed material for these keys 351 MUST be published under different directories in the context of the 352 'id-ad-caRepository' and 'id-ad-rpkiManifest' Subject Information 353 Access descriptions contained on the CA certificates [RFC6487]. 354 Publishing objects under the same directory is potentially confusing 355 for RPs, and could lead to object invalidity in the event of file 356 name collisions. 358 However, the CA certificates for each key, and the contents published 359 by each key, MUST be equivalent (except for the TAK object). In 360 other words, for the purposes of RPKI validation, it MUST NOT make a 361 difference which of the keys is used as a starting point. 363 This means that the IP and AS resources contained on all current CA 364 certificates for the current TA keys MUST be the same. Furthermore, 365 for any delegation of IP and AS resources to a child, the TA MUST 366 have an equivalent CA certificate published under each of its keys. 367 Any updates in delegations MUST be reflected under each of its keys. 368 A TA SHOULD NOT publish any other objects besides a CRL, a Manifest, 369 a single TAK object, and any number of CA certificates for delegation 370 to child CAs. 372 If a TA uses a single remote publication server for its keys, per 373 [RFC8181], then it MUST include all and PDUs 374 for the products of each of its keys in a single query, in order to 375 ensure that they will reflect the same content at all times. 377 If a TA uses multiple publication servers, then it is by definition 378 inevitable that the content of different keys will be out of sync at 379 times. In such cases, the TA SHOULD ensure that the duration of 380 these moments are limited to the shortest possible time. 381 Furthermore, the following should be observed: 383 * In cases where a CA certificate is revoked completely, or replaced 384 by a certificate with a reduced set of resources, these changes 385 will not take effect fully until all the relevant repository 386 publication points have been updated. Given that TA key 387 operations are normally performed infrequently, this is unlikely 388 to be a problem: if the revocation or shrinking of an issued CA 389 certificate is staged for days/weeks, then experiencing a delay of 390 several minutes for the repository publication points to be 391 updated is fairly insignificant. 393 * In cases where a CA certificate is replaced by a certificate with 394 an extended set of resources, the TA MUST inform the receiving CA 395 only after all of its repository publication points have been 396 updated. This ensures that the receiving CA will not issue any 397 products that could be invalid if an RP uses a TA key just before 398 the CA certificate was due to be updated. 400 Finally, note that the publication locations of CA certificates for 401 delegations to child CAs under each key will be different, and 402 therefore the Authority Information Access 'id-ad-caIssuers' values 403 (section 4.8.7 of [RFC6487]) on certificates issued by the child CAs 404 may not be as expected when performing top-down validation, depending 405 on the TA key that is used. However, these values are not critical 406 to top-down validation, so RPs performing such validation MUST NOT 407 reject a certificate simply because this value is not as expected. 409 7. Performing TA Key Rolls 411 In this section we will describe how present day RPKI TAs that use 412 only one key pair, and that do not use TAK objects, can change to 413 having a successor key, allowing them to perform both planned and 414 unplanned key rolls. 416 7.1. Phase 1: Add a TAK for Key 'A' 418 Before adding a successor key, a Trust Anchor may want to build up 419 operational experience in maintaining a TAK object that describes its 420 current key only. We will refer to this key as key 'A' throughout 421 this section. 423 The TA will have a TAL file [RFC8630] that contains one or more URIs 424 where the (equivalent) CA certificates for this key 'A' can be 425 retrieved. The TA can now generate a TAK object that sets key 'A' as 426 its current key. 428 The TA SHOULD publish the CA certificate for key 'A' at one or more 429 new locations not used in the TAL file, and use these new URIs in the 430 TAK object. The TA is free to choose any naming strategy for these 431 locations. As a non-normative suggestion, the TA could use the date 432 that this phase was started as part of the file name or directory 433 where the CA certificate is published. 435 The TA can now monitor the retrieval of its CA certificates from the 436 URI(s) in the newly published TAK object, relative to the retrieval 437 from the URI(s) listed in its TAL file, to learn the proportion of 438 RPs that can successfully validate and use the TAK object. 440 7.2. Phase 2: Add a Key 'B' 442 The TA can now generate a new key pair, key 'B'. This key MUST now 443 be used to create a new CA certificate for this key, and issue 444 equivalent CA certificates for delegations to child CAs, as described 445 in Section 6. 447 At this point, the TA can also construct a new TAL file [RFC8630] for 448 key 'B', and test locally that the validation outcome for the new key 449 is indeed equivalent to the other current key(s). 451 When the TA is certain that both keys are equivalent, it MUST issue a 452 new TAK object under key 'A', setting key 'B' as the successor key 453 for key 'A' without revoking key 'A'. It MUST also issue a TAK 454 object under key 'B', with key 'B' as the current key for that 455 object. 457 7.3. Phase 3: Activate Key 'B' 459 To roll to key 'B', the TA issues a new TAK object under key 'A' with 460 the revoked field set to true. RPs that process TAK objects will 461 start validating from key 'B' at that point. 463 The TA must also release a new TAL file for key 'B', as the intended 464 key to be used by RP software. As described above, it SHOULD use a 465 different set of URIs in the TAL compared to the TAK file, so that 466 the TA can learn the proportion of RPs that can successfully validate 467 and use the updated TAK objects. 469 To support RPs that do not take account of TAK objects, the TA should 470 continue operating key 'A' for a period of time after it has been 471 marked as revoked. The length of that period of time is a local 472 policy matter for that TA: it might operate the key until no clients 473 are attempting to validate using it, for example. 475 7.4. Phase 4: Remove Key 'A' 477 The TA SHOULD now publish a long-lived TAK object, CRL and manifest 478 under key 'A', remove all other content, and destroy key 'A'. This 479 way, RP software that uses a TAL for key 'A' can still successfully 480 find keys 'B' and 'C', and in future 'D', 'E', etc. 482 If access to key 'A' was lost, then there is no way to indicate to 483 clients still using key 'A' that key 'B' should be used from that 484 point onwards. In this instance, the TA will rely on clients 485 updating their local state manually, by way of the new TAL file. 487 7.5. Unplanned Direction Roll 489 If key 'B' is compromised, then the TA replaces it as the successor 490 key for key 'A' with another new key ('C'). Since RPs cannot move to 491 key 'B' until key 'A' is marked as revoked, they will begin 492 validation using key 'A', and note that key 'B' has since been 493 replaced as the successor key. 495 8. Deployment Considerations 497 Including TAK objects while RPs do not support this standard will 498 result in those RPs rejecting these objects. It is not expected that 499 this will result in the invalidation of any other object under a 500 Trust Anchor. 502 The mechanism introduced here can only be relied on once a majority 503 of RPs support it. Defining when that moment arrives is something 504 that cannot be established at the time of writing this document. The 505 use of unique URIs for keys in TAK objects, different from those used 506 for the corresponding TAL files, should help TAs understand the 507 proportion of RPs that support this mechanism. 509 A TA that accidentally revokes a current key via a TAK object without 510 listing a successor key can set the 'revoked' field on that TAK 511 object to false and republish that TAK object. The same is true of a 512 TA that accidentally sets up a loop among its TAK objects, such that 513 a client cannot access a TAK with an unrevoked key and proceed with 514 validation. These are the only instances in which it would be 515 sensible for a TA to publish a TAK object that marked a TA key as not 516 revoked after having already published a TAK object that marked that 517 TA key as revoked. In all other instances, publishing such a TAK 518 object could lead to a split in the RP population for the TA: RPs 519 that had already processed the TAK object with the 'revoked' field 520 set to true would have moved on to the successor key, while RPs that 521 had not would continue to use the current key. 523 9. Security Considerations 525 Because a TA key can mark itself as revoked and require clients to 526 start using a new key, an adversary that gains access to a TA's 527 current key and its associated publication servers can essentially 528 take over the TA. 530 This risk can be mitigated by the use of Hardware Security Modules 531 (HSMs) by TAs, which will guard against theft of a private key, as 532 well as operational processes to guard against (accidental) misuse of 533 the keys in an HSM by operators. 535 An example where planned rolls are useful is when a TA is using an 536 HSM from vendor X, and they want to migrate to an HSM from vendor Y. 538 Alternate models of TAL update exist and can be complementary to this 539 mechanism. For example, TAs can liaise directly with validation 540 software developers to include updated and reissued TAL files in new 541 code releases, and use existing code update mechanisms in the RP 542 community to distribute the changes. 544 10. IANA Considerations 546 10.1. OID 548 IANA is asked to add the following to the "RPKI Signed Objects" 549 registry: 551 Decimal | Description | References 552 --------+--------------------------------+--------------- 553 TBD | Trust Anchor Key | [section 3.1] 555 10.2. File Extension 557 IANA is asked to add an item for the Signed TAL file extension to the 558 "RPKI Repository Name Scheme" created by [RFC6481] as follows: 560 Extension | RPKI Object | References 561 -----------+------------------------------------------- 562 .tak | Trust Anchor Key | [this document] 564 10.3. Module Identifier 566 IANA is asked to register an object identifier for one module 567 identifier in the "SMI Security for S/MIME Module Identifier 568 (1.2.840.113549.1.9.16.0)" registry as follows: 570 Decimal | Description | References 571 --------+--------------------------------+--------------- 572 TBD | Trust Anchor Key | [section 3.1] 574 * Description: RPKISignedTrustAnchorList-2021 576 * OID: 1.2.840.113549.1.9.16.0.TBD 578 * Specification: [this document] 580 11. Implementation Status 582 NOTE: Please remove this section and the reference to RFC 7942 prior 583 to publication as an RFC. 585 This section records the status of known implementations of the 586 protocol defined by this specification at the time of posting of this 587 Internet-Draft, and is based on a proposal described in [RFC7942]. 588 The description of implementations in this section is intended to 589 assist the IETF in its decision processes in progressing drafts to 590 RFCs. Please note that the listing of any individual implementation 591 here does not imply endorsement by the IETF. Furthermore, no effort 592 has been spent to verify the information presented here that was 593 supplied by IETF contributors. This is not intended as, and must not 594 be construed to be, a catalog of available implementations or their 595 features. Readers are advised to note that other implementations may 596 exist. 598 According to RFC 7942, "this will allow reviewers and working groups 599 to assign due consideration to documents that have the benefit of 600 running code, which may serve as evidence of valuable experimentation 601 and feedback that have made the implemented protocols more mature. 602 It is up to the individual working groups to use this information as 603 they see fit". 605 11.1. APNIC 607 * Responsible Organization: Asia-Pacific Network Information Centre 609 * Location: https://github.com/APNIC-net/rpki-signed-tal-demo 611 * Description: A proof-of-concept for relying party TAK usage. 613 * Level of Maturity: This is a proof-of-concept implementation. 615 * Coverage: This implementation includes all of the features 616 described in this specification. The repository includes a link 617 to various test TALs that can be used for testing TAK scenarios, 618 too. 620 * Contact Information: Tom Harrison, tomh@apnic.net 622 12. Revision History 624 03 - Last draft under Tim's authorship. 626 04 - First draft with George's authorship. No substantive revisions. 628 05 - First draft with Tom's authorship. No substantive revisions. 630 06 - Rob Kisteleki's critique. 632 07 - Switch to two-key model. 634 13. Acknowledgments 636 The authors wish to thank Martin Hoffmann for a thorough review of 637 this document, and Russ Housley for reviewing the ASN.1 definitions 638 and providing a new module for the TAK object. 640 14. References 642 14.1. Normative References 644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 645 Requirement Levels", BCP 14, RFC 2119, 646 DOI 10.17487/RFC2119, March 1997, 647 . 649 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 650 Addresses and AS Identifiers", RFC 3779, 651 DOI 10.17487/RFC3779, June 2004, 652 . 654 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 655 Housley, R., and W. Polk, "Internet X.509 Public Key 656 Infrastructure Certificate and Certificate Revocation List 657 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 658 . 660 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 661 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 662 . 664 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 665 Resource Certificate Repository Structure", RFC 6481, 666 DOI 10.17487/RFC6481, February 2012, 667 . 669 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 670 "Manifests for the Resource Public Key Infrastructure 671 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 672 . 674 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 675 X.509 PKIX Resource Certificates", RFC 6487, 676 DOI 10.17487/RFC6487, February 2012, 677 . 679 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 680 Template for the Resource Public Key Infrastructure 681 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 682 . 684 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 685 Protocol (HTTP/1.1): Message Syntax and Routing", 686 RFC 7230, DOI 10.17487/RFC7230, June 2014, 687 . 689 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 690 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 691 May 2017, . 693 [RFC8181] Weiler, S., Sonalker, A., and R. Austein, "A Publication 694 Protocol for the Resource Public Key Infrastructure 695 (RPKI)", RFC 8181, DOI 10.17487/RFC8181, July 2017, 696 . 698 [RFC8630] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T. 699 Bruijnzeels, "Resource Public Key Infrastructure (RPKI) 700 Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630, 701 August 2019, . 703 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 704 "Information technology - ASN.1 encoding rules: 705 Specification of Basic Encoding Rules (BER), Canonical 706 Encoding Rules (CER) and Distinguished Encoding Rules 707 (DER)", 2002. 709 14.2. Informative References 711 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 712 RFC 5652, DOI 10.17487/RFC5652, September 2009, 713 . 715 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 716 Code: The Implementation Status Section", BCP 205, 717 RFC 7942, DOI 10.17487/RFC7942, July 2016, 718 . 720 Appendix A. ASN.1 Module 722 This appendix includes the ASN.1 module for the TAK object. 724 725 RPKISignedTrustAnchorList-2021 726 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 727 pkcs9(9) smime(16) mod(0) TBD } 729 DEFINITIONS EXPLICIT TAGS ::= 730 BEGIN 732 IMPORTS 734 CONTENT-TYPE 735 FROM CryptographicMessageSyntax-2009 -- in [RFC5911] 736 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 737 pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) } 739 SubjectPublicKeyInfo 740 FROM PKIX1Explicit-2009 -- in [RFC5912] 741 { iso(1) identified-organization(3) dod(6) internet(1) 742 security(5) mechanisms(5) pkix(7) id-mod(0) 743 id-mod-pkix1-explicit-02(51) } ; 745 ct-signedTAL CONTENT-TYPE ::= 746 { TYPE TAK IDENTIFIED BY 747 id-ct-signedTAL } 749 id-ct-signedTAL OBJECT IDENTIFIER ::= { iso(1) member-body(2) 750 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) TBD } 752 CertificateURI ::= IA5String 754 TAKey ::= SEQUENCE { 755 certificateURIs SEQUENCE SIZE (1..MAX) OF CertificateURI, 756 subjectPublicKeyInfo SubjectPublicKeyInfo 757 } 759 TAK ::= SEQUENCE { 760 version INTEGER DEFAULT 0, 761 current TAKey, 762 successor TAKey OPTIONAL, 763 revoked BOOLEAN 764 } 765 767 Authors' Addresses 769 Carlos Martinez 770 LACNIC 771 Email: carlos@lacnic.net 772 URI: https://www.lacnic.net/ 774 George G. Michaelson 775 Asia Pacific Network Information Centre 776 6 Cordelia St 777 South Brisbane 778 QLD 4101 779 Australia 781 Email: ggm@apnic.net 783 Tom Harrison 784 Asia Pacific Network Information Centre 785 6 Cordelia St 786 South Brisbane 787 QLD 4101 788 Australia 790 Email: tomh@apnic.net 792 Tim Bruijnzeels 793 NLnet Labs 795 Email: tim@nlnetlabs.nl 796 URI: https://www.nlnetlabs.nl/ 798 Rob Austein 799 Dragon Research Labs 801 Email: sra@hactrn.net