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