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