idnits 2.17.1
draft-ietf-sidrops-signed-tal-06.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The abstract seems to contain references ([I-D.ietf-sidrops-https-tal]),
which it shouldn't. Please replace those with straight textual mentions
of the documents in question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'MUST not' in this paragraph:
However, the CA certificates for each key, and the contents
published by each key MUST be equivalent. In other words it MUST not
make a difference which of the keys is used as a starting point for
top-down validation by RP software.
-- The document date (November 02, 2020) is 1242 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: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 C. Martinez
3 Internet-Draft LACNIC
4 Intended status: Standards Track G. Michaelson
5 Expires: May 6, 2021 T. Harrison
6 APNIC
7 T. Bruijnzeels
8 NLnet Labs
9 R. Austein
10 Dragon Research Labs
11 November 02, 2020
13 RPKI Signed Object for Trust Anchor Keys
14 draft-ietf-sidrops-signed-tal-06
16 Abstract
18 A Trust Anchor Locator (TAL) [I-D.ietf-sidrops-https-tal] is used by
19 Relying Parties (RP) in the RPKI to locate and validate a Trust
20 Anchor (TA) CA certificate used in RPKI validation. This document
21 defines an RPKI signed object for a set of Trust Anchor Keys (TAK),
22 that can be used by TA creators and publishers to signal their set of
23 current keys and the location(s) of the accompanying CA certificates
24 to RPs, as well as changes to this set in the form of revoked keys
25 and new keys, in order to support both planned and unplanned key
26 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 May 6, 2021.
45 Copyright Notice
47 Copyright (c) 2020 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
52 (https://trustee.ietf.org/license-info) in effect on the date of
53 publication of this document. Please review these documents
54 carefully, as they describe your rights and restrictions with respect
55 to this document. Code Components extracted from this document must
56 include Simplified BSD License text as described in Section 4.e of
57 the Trust Legal Provisions and are provided without warranty as
58 described in the Simplified BSD License.
60 Table of Contents
62 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
63 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
64 3. TAK Object definition . . . . . . . . . . . . . . . . . . . . 4
65 3.1. The TAK Object Content Type . . . . . . . . . . . . . . . 4
66 3.2. The TAK Object eContent . . . . . . . . . . . . . . . . . 5
67 3.2.1. version . . . . . . . . . . . . . . . . . . . . . . . 5
68 3.2.2. current . . . . . . . . . . . . . . . . . . . . . . . 5
69 3.2.3. revoked . . . . . . . . . . . . . . . . . . . . . . . 6
70 3.3. TAK Object Validation . . . . . . . . . . . . . . . . . . 6
71 4. TAK Object Generation and Publication . . . . . . . . . . . . 6
72 5. Relying Party Use . . . . . . . . . . . . . . . . . . . . . . 8
73 6. Maintaining multiple TA keys . . . . . . . . . . . . . . . . 9
74 7. Performing TA Key Rolls . . . . . . . . . . . . . . . . . . . 10
75 7.1. Phase 1: Add a TAK for Key 'A' . . . . . . . . . . . . . 10
76 7.2. Phase 2: Add a Key 'B' . . . . . . . . . . . . . . . . . 11
77 7.3. Phase 3: Roll to Key 'C' . . . . . . . . . . . . . . . . 11
78 7.3.1. Planned Direction Roll . . . . . . . . . . . . . . . 11
79 7.3.2. Unplanned Direction Roll . . . . . . . . . . . . . . 12
80 7.4. Phase X: Roll to Key 'D', 'E', .. . . . . . . . . . . . . 12
81 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 12
82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
84 10.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . 13
85 10.2. File Extension . . . . . . . . . . . . . . . . . . . . . 13
86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
87 12. Revision History . . . . . . . . . . . . . . . . . . . . . . 14
88 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
89 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
90 14.1. Normative References . . . . . . . . . . . . . . . . . . 14
91 14.2. Informative References . . . . . . . . . . . . . . . . . 15
92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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 Trust Anchor Locator (TAL) [I-D.ietf-sidrops-https-tal] is used by
105 a Relying Party (RP) in the RPKI to locate and validate Trust Anchor
106 (TA) CA certificates used in RPKI validation. However, until now
107 there has been no formal way of notifying RP of updates to a TAL.
108 Such updates may be needed in particular in case a TA needs to
109 perform a planned or unplanned key roll.
111 This document defines a new RPKI signed object that can be used to
112 document the current set of keys and the location(s) of the
113 accompanying CA certificates, as well as any changes to this set.
114 This allows RPs to be notified automatically of such changes, and
115 enables TAs to pre-stage a number of operational keys so that planned
116 and unplanned key rolls can be performed without risking the
117 invalidation of the RPKI tree under the TA. We call this object the
118 Trust Anchor Keys (TAK) object.
120 When RPs are first bootstrapped, they use any current TAL to discover
121 a key and location(s) of the TA certificate(s) for a TA. The RP can
122 then retrieve and validate the TA certificate, and subsequently
123 validate the manifest [RFC6486] and CRL published by that TA [section
124 5 of @!RFC6487]. However, before processing any other objects it
125 will then first validate the TAK object, if present. All enumerated
126 new keys (and locations) are then added to a new list of current TA
127 keys for this TA. The RP will then recursively fetch and validate
128 the TA certificates, manifest, CRL and TAK objects for each of these
129 keys. As a part of this process the RP will also compile a list of
130 revoked keys enumerated by any of the validly signed TAK objects. As
131 the final step the RP will then filter out any revoked TA keys from
132 its new set. This new set now replaces the previous set.
134 This process allows Trust Anchors to operate a set of N current keys,
135 where any key can effectively revoke any or all of the other keys to
136 perform either a planned, or an unplanned, key roll. This also
137 allows Trust Anchors to produce long lived TAK objects as forward
138 pointers to RPs, and retire its old key when doing a key roll. While
139 the generic process is quite involved, the amount of work needed to
140 support an envisioned normal key roll is fairly limited. Under
141 normal circumstances a TA will typically have two current keys, so
142 that is can perform an emergency roll over in case one of the keys is
143 lost. This means that the RP will need to validate one additional CA
144 certificate, a CRL, a manifest and two TAK objects.
146 When a key roll is executed a TA will remove one old key, and
147 introduce one new (back-up) key. The RP will remove the old key from
148 its set, and it will not be queried again, and it will add the new
149 key and its TA certificate location(s).
151 Only in a situation where an RP is very outdated can it be expected
152 that the RP will have to discover several chained TAK object. But,
153 since it will remove the outdated TALs in this process, this presents
154 a one time cost only.
156 3. TAK Object definition
158 The TAK object makes use of the template for RPKI digitally signed
159 objects [RFC6488], which defines a Cryptographic Message Syntax (CMS)
160 [RFC5652] wrapper for the Signed TALs content as well as a generic
161 validation procedure for RPKI signed objects. Therefore, to complete
162 the specification of the TAK object (see Section 4 of [RFC6488]),
163 this document defines:
165 o The OID defined in Section 3.1 that identifies the signed object
166 as being a TAK. (This OID appears within the eContentType in the
167 encapContentInfo object as well as the content-type signed
168 attribute in the signerInfo object).
170 o The ASN.1 syntax for the TAK eContent defined in Section 3.2.
172 o Additional steps to the validation steps specified in [RFC6488]
173 required to validate the TAK, defined in Section 3.3.
175 3.1. The TAK Object Content Type
177 This document requests an OID for TAK objects as follows:
179 signed-Tal OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
180 rsadsi(113549) pkcs(1) pkcs9(9) 16 id-smime (1) TBD }
182 This OID MUST appear both within the eContentType in the
183 encapContentInfo object as well as the content-type signed attribute
184 in the signerInfo object (see [RFC6488])
186 3.2. The TAK Object eContent
188 The content of a TAK object is ASN.1 encoded using the Distinguished
189 Encoding Rules (DER) [X.690], and is defined as follows:
191 TAK ::= SEQUENCE {
192 version INTEGER DEFAULT 0,
193 current ::= SEQUENCE SIZE (1..MAX) OF CurrentKey,
194 revoked ::= SEQUENCE OF SubjectPublicKeyInfo
195 }
197 CurrentKey ::= SEQUENCE {
198 certificateURIs SEQUENCE SIZE (1..MAX) OF CertificateURI,
199 subjectPublicKeyInfo SubjectPublicKeyInfo
200 }
202 CertificateURI ::= IA5String
204 SubjectPublicKeyInfo ::= SEQUENCE {
205 algorithm AlgorithmIdentifier,
206 subjectPublicKey BIT STRING
207 }
209 3.2.1. version
211 The version number of the TAK object MUST be 0.
213 3.2.2. current
215 This field defines the set of current keys (CurrentKey) according to
216 the signer of this Signed TALs object.
218 3.2.2.1. CurrentKey
220 This field defines a current TA Key, equivalent to [I-D.ietf-sidrops-
221 https-tal]. This structure contains a sequence of one or more URIs
222 and a SubjectPublicKeyInfo.
224 3.2.2.1.1. certificateURIs
226 This field is equivalent to the URI section in section 2.1 of
227 [I-D.ietf-sidrops-https-tal]. It MUST contain at least one
228 CertificateURI element. Each CertificateURI element contains the
229 IA5String representation of either an rsync URI [RFC5781], or an
230 HTTPS URI [RFC7230].
232 3.2.2.1.2. subjectPublicKeyInfo
234 This field contains a SubjectPublicKeyInfo [section 4.1.2.7 or
235 @!RFC5280] in DER format [X.690].
237 3.2.3. revoked
239 This field contains the list of keys, identified by
240 SubjectPublicKeyInfo, that are no longer to be used according to the
241 signer of this document.
243 3.3. TAK Object Validation
245 To determine whether a TAK object is valid, the RP MUST perform the
246 following steps in addition to those specified in [RFC6488]:
248 o The eContentType OID matches the OID described in Section 3.1
250 o The TAK object appears as the product of a Trust Anchor CA
251 certificate.
253 o This Trust Anchor CA has published only one TAK object in its
254 repository for this key, and this object appears on the Manifest
255 as the only entry using the ".tak" extension (see [RFC6481]). In
256 case more than one TAK object is found, all such objects MUST be
257 considered invalid.
259 o The EE certificate of this TAK object describes its Internet
260 Number Resources (INRs) using the "inherit" attribute
262 o The decoded TAK content conforms to the format defined in
263 Section 3.2.
265 If the above procedure indicates that the manifest is invalid, then
266 the TAK object MUST be discarded and treated as though no TAK object
267 were present.
269 4. TAK Object Generation and Publication
271 A TA MAY choose to use TAK objects to communicate its set of current,
272 and revoked keys. If a TA chooses to use TAK objects, then it SHOULD
273 generate and publish TAK objects under each of its current keys. An
274 exception to this rule exists when a TA has lost permanent access to
275 one of its keys or the accompanying repository publication point. In
276 such cases however, the key in question MUST be revoked as described
277 below in Section 7.
279 A non-normative guideline for naming this object is that the filename
280 chosen for the Signed TAL Object in the publication repository be a
281 value derived from the public key part of the entity's key pair,
282 using the algorithm described for CRLs in section 2.2 of [RFC6481]
283 for generation of filenames. The filename extension of ".tak" MUST
284 be used to denote the object as a TAK. Note that this is in-line
285 with filename extensions defined in section 7.2 of [RFC6481]
287 In order to generate the TAK Objects, the TA MUST perform the
288 following actions:
290 o The TA MUST generate a key pair for a "one-time-use" EE
291 certificate to use for the TAK
293 o The TA MUST generate a one-time-use EE certificate for the TAK
295 o This EE certificate MUST have an SIA extension access description
296 field with an accessMethod OID value of id-ad-signedobject, where
297 the associated accessLocation references the publication point of
298 the TAK as an object URL.
300 o As described in [RFC6487], an [RFC3779] extension is required in
301 the EE certificate used for this object. However, because the
302 resource set is irrelevant to this object type, this certificate
303 MUST describe its Internet Number Resources (INRs) using the
304 "inherit" attribute, rather than explicit description of a
305 resource set.
307 o This EE certificate MUST have a "notBefore" time that matches, or
308 predates the moment that the TAK will be published.
310 o This EE certificate MUST have a "notAfter" time that reflects the
311 intended duration for which this TAK will be published. If the EE
312 certificate for a Signed TAL is expired, it MUST no longer be
313 published, but it MAY be replaced by a newly generated TAK object
314 with equivalent content and an updated "notAfter" time.
316 o The same set of current keys (see Section 3.2.2) MUST be included
317 on each TAK object for each current key.
319 o The TAK object MUST include all revoked keys (see Section 3.2.3)
320 that became revoked while the key signing the TAK in question was
321 current.
323 5. Relying Party Use
325 Relying Parties MUST keep a record of all current keys for each
326 configured Trust Anchor, as well as the URI(s) where the CA
327 certificate for each of these keys may be retrieved. This record MAY
328 be bootstrapped by the use of a pre-configured (and unsigned) TAL
329 file [I-D.ietf-sidrops-https-tal], but it MUST be updated with
330 authoritative signed information found in valid TAK objects found in
331 subsequent validation runs.
333 When performing top-down validation RPs MUST first validate and
334 process any TAK objects for each of its known current keys for a TA
335 by performing the following steps:
337 o A CA certificate is retrieved and validated from the known URIs as
338 described in sections 3 and 4 of [I-D.ietf-sidrops-https-tal].
340 o The manifest and CRL for this certificate are then validated first
341 as described in [RFC6487] and [RFC6486].
343 o The TAK file, if present, is validated as described in
344 Section 3.3.
346 For each valid TAK file thus found all current keys, i.e.
347 SubjectPublicKeyInfo and URIs, are kept. If any previously unknown
348 keys are added to the set of current keys, then they MUST also be
349 processed as described above.
351 Once the TAK objects for all keys are processed the set of current
352 keys and URIs for the TA is updated as follows: * All new current
353 keys found on any valid TAK object are added to the set of current
354 keys. * The set of URIs for each current key is replaced by the union
355 of all URIs for this key found on all valid TAK objects. * Finally,
356 any current key that matches any revoked key on any valid TAK object
357 is removed from the set of current keys.
359 Note that if a current key does not occur on any valid TAK object,
360 but it is not revoked either, then it and any previously known URIs
361 for it are kept. Also note that if an RP was bootstrapped using a
362 TAL file [I-D.ietf-sidrops-https-tal], the keys and URIs will now
363 have been replaced by values found on TAK objects.
365 After this the RP can choose any one of the valid CA certificates for
366 any key that is still in the set of current keys for this TA, in
367 order to continue the top-down validation of object for this TA as
368 described in [RFC6487].
370 6. Maintaining multiple TA keys
372 If a TA operates multiple keys, then the signed material for these
373 keys MUST be published under different directories in the context of
374 the 'id-ad-caRepository' and 'id-ad-rpkiManifest' Subject Information
375 Access descriptions contained on the CA certificates [RFC6487].
376 Publishing objects under the same space would lead to confusion at
377 best, and in case of file name collisions of objects invalidity.
379 However, the CA certificates for each key, and the contents published
380 by each key MUST be equivalent. In other words it MUST not make a
381 difference which of the keys is used as a starting point for top-down
382 validation by RP software.
384 This means that the IP and AS resources contained on all current CA
385 certificates for the current TA keys MUST be the same. Furthermore
386 for any delegation of IP and AS resources to a child, the TA MUST
387 have an equivalent CA certificate published under each of its keys.
388 Any updates in delegations MUST be reflected under each of its keys.
389 A TA SHOULD NOT publish any other objects besides a CRL, a Manifest,
390 a single TAK object, and any number of CA certificates for delegation
391 to child Certification Authorities.
393 If a TA uses a single remote publication server for its keys using
394 the RPKI publication protocol [RFC8181], then it MUST include all
395 and PDUs for the products of each of its keys
396 in a single query in order to ensure that they will reflect the same
397 content at all times.
399 If a TA uses multiple publication servers then it is by definition
400 inevitable that the content of different keys will be out of sync at
401 times. In such cases the TA SHOULD ensure that the duration of these
402 moments are limited to the shortest possible time. Furthermore the
403 following should be observed:
405 o In cases where a CA certificate is revoked completely, or replaced
406 by a certificate with a reduced set of resources, these changes
407 will not take effect fully until all the TA keys repository
408 publication points have been updated. Given that TA key
409 operations are normally performed infrequently we don't expect
410 that this is a problem. I.e. if the revocation or shrinking of an
411 issued CA certificate is staged for days, or weeks anyway, then
412 experiencing a delay of several minutes for the repository
413 publication points to all be updated is fairly insignificant.
415 o In cases where a CA certificate is replaced by a certificate with
416 an extend set of resources the TA MUST inform the receiving CA
417 only after all its repository publication points have been
418 updated. This ensures that the receiving CA will not issue any
419 products that could be invalid if an RP uses a TA key just before
420 the CA certificate was due to be updated.
422 Finally, note that the publication locations of CA certificates for
423 delegations to child CAs under each key will be different, and
424 therefore the Authority Information Access 'id-ad-caIssuers' value on
425 certificates issued by the child CAs may not match (section 4.8.7 of
426 [RFC6487]). However, this information is not considered critical for
427 validation of these objects and provided as hints to RP software
428 only. Therefore RP software MUST NOT reject these certificates based
429 on a mismatch of this value.
431 7. Performing TA Key Rolls
433 In this section we will describe how present day RPKI TAs that use
434 only one key pair, and that do not use TAK objects, can change to
435 having two current keys at all times allowing them to perform both
436 planned and unplanned key rolls.
438 7.1. Phase 1: Add a TAK for Key 'A'
440 Before adding any new keys a Trust Anchor may want to build up
441 operational experience in maintaining a TAK object that describes its
442 current key only. We will call refer to this key as key 'A'
443 throughout this section.
445 The TA will have a TAL file [I-D.ietf-sidrops-https-tal] that
446 contains one or more URIs where the (equivalent) CA certificates for
447 this key 'A' can be retrieved. The TA can now generate a TAK objects
448 that includes key 'A' only in its sequence of 'CurrentKey' values.
450 The TA SHOULD publish the CA certificate for key 'A' at one or more
451 new locations not used in the TAL file, and use these new URIs in the
452 TAK object. The TA is free to choose any naming strategy for these
453 locations. As a non-normative suggestion, one such approach could be
454 to use the date that this phase was started as part of the file name
455 or a directory where the CA certificate is published.
457 The TA can now monitor the retrieval of its CA certificates from the
458 URI(s) in the newly published TAK object, relative to the retrieval
459 from the URI(s) listed in its TAL file, to learn the proportion of
460 RPs that can successfully validate and use the TAK object.
462 7.2. Phase 2: Add a Key 'B'
464 The TA can now generate a new key pair, key 'B'. This key MUST now
465 be used to create a new CA certificate for this key, and issue
466 equivalent CA certificates for delegations to child CAs, as described
467 in Section 6.
469 At this point, the TA can also issue a new TAL file
470 [I-D.ietf-sidrops-https-tal] for key 'B', and test locally that the
471 validation outcome for the new key is indeed equivalent to the other
472 current key(s).
474 When the TA is certain that both keys are equivalent, it MUST issue a
475 new TAK object under each of its current keys, and include both the
476 old key 'A' and this new key 'B' in the set of current keys.
478 The TA SHOULD now also release a new TAL file for this new key 'B' as
479 the intended new key to be used by RP software. However, as
480 described above, it SHOULD use a different set of URIs in the TAL
481 compared to the TAK file, so that it can learn the proportion of RPs
482 that can successfully validate and use the updated TAK objects.
484 7.3. Phase 3: Roll to Key 'C'
486 In this phase a new key, key 'C' is generated as described above in
487 Section 7.2. And one of the previous keys is revoked.
489 7.3.1. Planned Direction Roll
491 If the key roll is planned, and the TA has access to all its keys
492 'A', 'B' and 'C', and the publication servers for each of the keys,
493 then a new TAK object is generated for each of these keys listing
494 keys 'B' and 'C' as current, and key 'A' as revoked.
496 The TA SHOULD now publish a long-lived TAK file, CRL and Manifest
497 under key 'A', remove all other content, and destroy key 'A'. This
498 way RP software that uses a TAL for key 'A' can still successfully
499 find keys 'B' and 'C', and in future 'D', 'E', etc.
501 If access to key 'A' was lost, then the process is slightly
502 different. The TAK object for key 'A' cannot be updated and will
503 therefore still refer to keys 'A' and 'B' as the current keys, and
504 include no revocations. However, an updated TAK object listing keys
505 'B' and 'C' as current, and listing key 'A' as revoked can still be
506 issued and published under keys 'B' and 'C'. As described in
507 Section 5 RPs will then discover that key 'A' is revoked, and
508 continue to use keys 'B' and 'C'.
510 7.3.2. Unplanned Direction Roll
512 If key 'B' is compromised, the process is similar to above, except of
513 course that now keys 'A' and 'C' are included in the set of current
514 keys, and key 'B' is in the set of revoked keys. If the TA still has
515 access to key 'B', then it SHOULD publish a long-lived TAK file, CRL
516 and manifest for key 'B' and remove all other content for it. If it
517 cannot perform this action then simply marking key 'B' as revoked
518 will still notify RPs to disregard it.
520 7.4. Phase X: Roll to Key 'D', 'E', ..
522 Further key rolls are essentially no different the roll to key 'C'
523 described in Section 7.3, except that there is no need to still
524 include key 'A' in the list of revoked keys when the the roll to key
525 'D' is performed. RPs will already have learned to that key 'A' is
526 revoked, before they learn about key 'D'.
528 8. Deployment Considerations
530 Including Signed TAL objects while RP tools do not support this
531 standard will result in these RPs rejecting these objects. It is not
532 expected that this will result in the invalidation of any other
533 object under a Trust Anchor.
535 That said, the flagging mechanism introduced here can only be relied
536 on once a majority of RPs support it. Defining when that moment
537 arrives is by definition something that cannot be established at the
538 time of writing this document. The use of unique URIs in TAK objects
539 compared to their equivalent TAL files should help operators
540 understand which proportion of RPs support this mechanism.
542 9. Security Considerations
544 It should be noted that because any key can revoke the other key(s),
545 a risk introduced: if an adversary can gain access to one of the
546 keys, and publication servers for it, then they can essentially take
547 over a TA. It should also be noted that a TA can revoke all of its
548 keys by accident and make itself obsolete.
550 However, these risks can be mitigated greatly by the use of Hardware
551 Security Modules (HSM) by TAs, which will guard against theft of a
552 private key, and operational processes to guard against (accidental)
553 mis-use of the keys in an HSM by operators.
555 Although HSMs can help against key theft, the risk of key loss is
556 still very applicable. In some ways more so, because back-ups are
557 hard by design. Key loss can easily happen for example when an
558 operator card set that is used to authorize use of a key in an HSM
559 can no longer be used, e.g. because cards are broken or lost, or a
560 persons who holds a card is sadly no longer with us, or passwords are
561 forgotten, etc.
563 In such cases the ability to perform an unplanned roll as described
564 in this document will be very useful, provided that access to the
565 both keys is arranged differently, and the issues affecting one key,
566 do not necessarily affect the other key.
568 An example where the planned rolls are useful is when a TA is using
569 an HSM from vendor X, and they want to migrate to an HSM from vendor
570 Y.
572 Alternate models of TAL update exist and can be complementary to this
573 mechanism. For example, TAL maintainers can liaise directly with
574 validation software developers to include updated and re-issued TAL
575 in new code release, and use existing code update mechanisms in the
576 RP community to distribute the changes. Broadly speaking, this is
577 the mechanism used inside web browsers to propagate significant
578 changes of the trust anchor set included in the browser by default.
580 10. IANA Considerations
582 10.1. OID
584 IANA is to add the following to the "RPKI Signed Objects" registry:
586 Decimal | Description | References
587 --------+--------------------------------+---------------
588 TBD | Trust Anchor Keys | [section 3.1]
590 10.2. File Extension
592 IANA is to add an item for the Signed TAL file extension to the "RPKI
593 Repository Name Scheme" created by [RFC6481] as follows:
595 Extension | RPKI Object | References
596 -----------+-------------------------------------------
597 .tak | Trust Anchor Keys | [this document]
599 11. Security Considerations
601 TBD
603 12. Revision History
605 03 - Last Draft under Tim's authorship.
607 04 - First Draft with Georges's authorship. No substantive
608 revisions.
610 05 - First Draft with Toms's authorship. No substantive revisions.
612 06 - Rob Kisteleki's critique
614 13. Acknowledgments
616 The authors wish to thank Martin Hoffmann for a thorough review of
617 this document.
619 14. References
621 14.1. Normative References
623 [I-D.ietf-sidrops-https-tal]
624 Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
625 Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
626 Trust Anchor Locator", draft-ietf-sidrops-https-tal-08
627 (work in progress), April 2019.
629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
630 Requirement Levels", BCP 14, RFC 2119,
631 DOI 10.17487/RFC2119, March 1997,
632 .
634 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
635 Addresses and AS Identifiers", RFC 3779,
636 DOI 10.17487/RFC3779, June 2004,
637 .
639 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
640 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010,
641 .
643 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
644 Resource Certificate Repository Structure", RFC 6481,
645 DOI 10.17487/RFC6481, February 2012,
646 .
648 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski,
649 "Manifests for the Resource Public Key Infrastructure
650 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012,
651 .
653 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
654 X.509 PKIX Resource Certificates", RFC 6487,
655 DOI 10.17487/RFC6487, February 2012,
656 .
658 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
659 Template for the Resource Public Key Infrastructure
660 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
661 .
663 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
664 Protocol (HTTP/1.1): Message Syntax and Routing",
665 RFC 7230, DOI 10.17487/RFC7230, June 2014,
666 .
668 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
669 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
670 May 2017, .
672 [RFC8181] Weiler, S., Sonalker, A., and R. Austein, "A Publication
673 Protocol for the Resource Public Key Infrastructure
674 (RPKI)", RFC 8181, DOI 10.17487/RFC8181, July 2017,
675 .
677 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
678 "Information technology - ASN.1 encoding rules:
679 Specification of Basic Encoding Rules (BER), Canonical
680 Encoding Rules (CER) and Distinguished Encoding Rules
681 (DER)", 2002.
683 14.2. Informative References
685 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
686 RFC 5652, DOI 10.17487/RFC5652, September 2009,
687 .
689 Authors' Addresses
690 Carlos Martinez
691 LACNIC
693 ,
695 Phone:
697 Email: carlos@lacnic.net
699 URI: https://www.lacnic.net/
701 George G. Michaelson
702 Asia Pacific Network Information Centre
703 6 Cordelia St
705 South Brisbane
706 , QLD
707 4101
709 Australia
711 Phone:
713 Email: ggm@apnic.net
715 URI:
717 Tom Harrison
718 Asia Pacific Network Information Centre
719 6 Cordelia St
721 South Brisbane
722 , QLD
723 4101
725 Australia
727 Phone:
729 Email: tomh@apnic.net
731 URI:
733 Tim Bruijnzeels
734 NLnet Labs
736 ,
738 Phone:
740 Email: tim@nlnetlabs.nl
742 URI: https://www.nlnetlabs.nl/
743 Rob Austein
744 Dragon Research Labs
746 ,
748 Phone:
750 Email: sra@hactrn.net
752 URI: