idnits 2.17.1
draft-ietf-sidrops-signed-tal-02.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
-- The document date (October 16, 2018) is 2019 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)
== Outdated reference: A later version (-08) exists of
draft-ietf-sidrops-https-tal-05
** 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 Network Working Group T. Bruijnzeels
3 Internet-Draft NLnet Labs
4 Intended status: Standards Track C. Martinez
5 Expires: April 19, 2019 LACNIC
6 R. Austein
7 Dragon Research Labs
8 October 16, 2018
10 RPKI Signed Object for Trust Anchor Keys
11 draft-ietf-sidrops-signed-tal-02
13 Abstract
15 Trust Anchor Locators (TALs) [I-D.ietf-sidrops-https-tal] are used by
16 Relying Parties in the RPKI to locate and validate Trust Anchor
17 certificates used in RPKI validation. This document defines an RPKI
18 signed object for Trust Anchor Keys (TAK), that can be used by Trust
19 Anchors to signal their set of current keys and the location(s) of
20 the accompanying CA certiifcates to Relying Parties, as well as
21 changes to this set in the form of revoked keys and new keys, in
22 order to support both planned and unplanned key rolls without
23 impacting RPKI validation.
25 Status of This Memo
27 This Internet-Draft is submitted in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at https://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on April 19, 2019.
42 Copyright Notice
44 Copyright (c) 2018 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (https://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 Table of Contents
59 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
60 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
61 3. TAK Object definition . . . . . . . . . . . . . . . . . . . . 4
62 3.1. The TAK Object Content Type . . . . . . . . . . . . . . . 5
63 3.2. The TAK Object eContent . . . . . . . . . . . . . . . . . 5
64 3.2.1. version . . . . . . . . . . . . . . . . . . . . . . . 5
65 3.2.2. current . . . . . . . . . . . . . . . . . . . . . . . 5
66 3.2.3. revoked . . . . . . . . . . . . . . . . . . . . . . . 6
67 3.3. TAK Object Validation . . . . . . . . . . . . . . . . . . 6
68 4. Maintaining multiple TA keys . . . . . . . . . . . . . . . . 7
69 4.1. Prepare a new TA key . . . . . . . . . . . . . . . . . . 7
70 4.2. Publishing for Multiple TA Keys . . . . . . . . . . . . . 7
71 5. TAK Object Generation and Publication . . . . . . . . . . . . 8
72 6. Performing TA Key Rolls . . . . . . . . . . . . . . . . . . . 9
73 6.1. Opting in to Key Rolls . . . . . . . . . . . . . . . . . 10
74 6.1.1. Trust Anchor . . . . . . . . . . . . . . . . . . . . 10
75 6.1.2. Relying Parties . . . . . . . . . . . . . . . . . . . 12
76 6.2. Pre-stage a New Key . . . . . . . . . . . . . . . . . . . 12
77 6.2.1. Trust Anchor . . . . . . . . . . . . . . . . . . . . 12
78 6.2.2. Relying Parties . . . . . . . . . . . . . . . . . . . 14
79 6.3. Planned Key Revocation . . . . . . . . . . . . . . . . . 14
80 6.3.1. Trust Anchor . . . . . . . . . . . . . . . . . . . . 14
81 6.3.2. Relying Parties . . . . . . . . . . . . . . . . . . . 17
82 6.4. Unplanned revocation . . . . . . . . . . . . . . . . . . 17
83 6.4.1. Trust Anchor . . . . . . . . . . . . . . . . . . . . 17
84 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 18
85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
86 8.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
87 8.2. File Extension . . . . . . . . . . . . . . . . . . . . . 19
88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
91 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
92 11.2. Informative References . . . . . . . . . . . . . . . . . 21
93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
95 1. Requirements notation
97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
99 "OPTIONAL" in this document are to be interpreted as described in BCP
100 14 [RFC2119] [RFC8174] when, and only when, they appear in all
101 capitals, as shown here.
103 2. Overview
105 Trust Anchor Locators (TALs) [I-D.ietf-sidrops-https-tal] are used by
106 Relying Parties in the RPKI to locate and validate Trust Anchor (TA)
107 certificates used in RPKI validation. However, until now there has
108 been no formal way of notifying Relying Parties (RP) of updates to a
109 TAL. Such updates may be needed in particular in case a Trust Anchor
110 needs to perform a planned, or unplanned, key roll.
112 This document defines a new RPKI signed object that can be used to
113 document the current set of keys and the loctaion(s) of the
114 accompanying CA certificates, as well as any changes to this set.
115 This allows RPs to be notified automatically of such changes, and
116 enables Trust Anchors to pre-stage a number of operational keys so
117 that planned and unplanned key rolls can be performed without risking
118 the invalidation of the RPKI tree under the TA. We call this object
119 the Trust Anchor Keys (TAK) object.
121 When Relying Parties (RPs) are first bootstrapped, they use any
122 current TAL to discover a key and location(s) of the TA
123 certificate(s) for a TA. The RP can then retreive and validating the
124 TA certificate, and subsequently validate the manifest [RFC6486] and
125 CRL [section 5 of @!RFC6487]. However, before processing any other
126 objects it will then first validate the TAK object, if present. All
127 enumarated new keys (and locations) are then added to a new list of
128 current TA keys for this TA. The RP will then recursively fetch and
129 validate the TA certificates, manifest, CRL and TAK objects for each
130 of these keys. As a part of this process the RP will also compile a
131 list of revoked keys enumarated by any of the validly signed TAK
132 objects. As the final step the RP will then filter out any revoked
133 TA keys from its new set. This new set now replaces the previous
134 set.
136 If the key used to start this process is still considered current,
137 then validation continues. But if the key was revoked, then
138 validation is restarted using one of the remaining keys in the set.
140 This process allows Trust Anchors to operate a set of N current keys,
141 where any key can effectively revoke any or all of the other keys to
142 perform either a planned, or an unplanned, key roll. This also
143 allows Trust Anchors to produce long lived TAK objects as forward
144 pointers to RPs, and retire its old key when doing a key roll.
146 While the generic process is quite involved, the amount of work
147 needed to support an envisioned normal key roll is fairly limited.
148 Under normal circumstances a TA will typically have two current keys,
149 so that is can perform an emergency roll over in case one of the keys
150 is lost. This means that the RP will need to validate two TAK
151 objects. However, typically these files will agree that both keys
152 are current and validation continues.
154 When a key roll is executed a TA will remove one old key, and
155 introduce one new (back-up) key. The RP will remove the old key from
156 its set, and it will not be queried again, and it will add the new
157 key and its TA certifcate location(s).
159 Only in a situation where an RP is very outdated can it be expected
160 that the RP will have to discover several chained TAK object. But,
161 since it will remove the outdated TALs in this process, this presents
162 a one time cost only.
164 Note that in theory a TA can revoke all of its keys and make itself
165 obsolete. In practice however, a well operated TA will have measures
166 in place to prevent this. Furthermore they can protect themselves
167 against key loss to adversaries through the use of such as the use of
168 a Hardware Security Module (HSM) to protect keys. Protecting against
169 this mis-operation would incur complexity and guesswork on the RPs.
170 Therefore it is believed that it is best to keep the process
171 straightforward, and offer a solution for the more likely issues of
172 loss of a key, e.g. because an HSM or card set is broken, and
173 planned key rolls.
175 3. TAK Object definition
177 The TAK object makes use of the template for RPKI digitally signed
178 objects [RFC6488], which defines a Crytopgraphic Message Syntax (CMS)
179 [RFC5652] wrapper for the Signed TALs content as well as a generic
180 validation procedure for RPKI signed objects. Therefore, to complete
181 the specification of the TAK object (see Section 4 of [RFC6488]),
182 this document defines:
184 o The OID defined in Section 3.1 that identifies the signed object
185 as being a TAK. (This OID appears within the eContentType in the
186 encapContentInfo object as well as the content-type signed
187 attribute in the signerInfo object).
189 o The ASN.1 syntax for the TAK eContent defined in Section 3.2.
191 o Additional steps to the validation steps specified in [RFC6488]
192 required to validate the TAK, defined in Section 3.3.
194 3.1. The TAK Object Content Type
196 This document requests an OID for TAK objects as follows:
198 signed-Tal OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
199 rsadsi(113549) pkcs(1) pkcs9(9) 16 id-smime (1) TBD }
201 This OID MUST appear both within the eContentType in the
202 encapContentInfo object as well as the content-type signed attribute
203 in the signerInfo object (see [RFC6488])
205 3.2. The TAK Object eContent
207 The content of a TAK object is ASN.1 encoded using the Distinguished
208 Encoding Rules (DER) [X.690], and is defined as follows:
210 TAK ::= SEQUENCE {
211 version INTEGER DEFAULT 0,
212 current ::= SEQUENCE SIZE (1..MAX) OF CurrentKey,
213 revoked ::= SEQUENCE OF SubjectPublicKeyInfo
214 }
216 CurrentKey ::= SEQUENCE {
217 certificateURIs SEQUENCE SIZE (1..MAX) OF CertificateURI,
218 subjectPublicKeyInfo SubjectPublicKeyInfo
219 }
221 CertificateURI ::= IA5String
223 SubjectPublicKeyInfo ::= SEQUENCE {
224 algorithm AlgorithmIdentifier,
225 subjectPublicKey BIT STRING
226 }
228 3.2.1. version
230 The version number of the TAK object MUST be 0.
232 3.2.2. current
234 This field defines the set of current keys (CurrentKey) according to
235 the signer of this Signed TALs object.
237 3.2.2.1. CurrentKey
239 This field defines a current TA Key, equivalent to [I-D.ietf-sidrops-
240 https-tal]. This structure contains a sequence of one or more URIs
241 and a SubjectPublicKeyInfo.
243 3.2.2.1.1. certificateURIs
245 This field is equivalent to the URI section in section 2.1 of
246 [I-D.ietf-sidrops-https-tal]. It MUST contain at least one
247 CertificateURI element. Each CertificateURI element contains the
248 IA5String representation of either an rsync URI [RFC5781], or an
249 HTTPS URI [RFC7230].
251 3.2.2.1.2. subjectPublicKeyInfo
253 This field contains a SubjectPublicKeyInfo [section 4.1.2.7 or
254 @!RFC5280] in DER format [X.690].
256 3.2.3. revoked
258 This field contains the list of keys, identified by
259 SubjectPublicKeyInfo, that are no longer to be used according to the
260 signer of this document.
262 3.3. TAK Object Validation
264 To determine whether a TAK object is valid, the RP MUST perform the
265 following steps in addition to those specified in [RFC6488]:
267 o The eContentType OID matches the OID described in Section 3.1
269 o The TAK object appears as the product of a Trust Anchor CA
270 certificate.
272 o This Trust Anchor CA has published only one TAK object in its
273 repository for this key, and this object appears on the Manifest
274 as the only entry using the ".tak" extension (see [RFC6481]). In
275 case more than one TAK object is found, all such objects MUST be
276 considered invalid.
278 o The EE certificate of this TAK object describes its Internet
279 Number Resources (INRs) using the "inherit" attribute
281 o The decoded TAK content conforms to the format defined in
282 Section 3.2.
284 If the above procedure indicates that the manifest is invalid, then
285 the TAK object MUST be discarded and treated as though no TAK object
286 were present.
288 4. Maintaining multiple TA keys
290 As described in Section 6 a TA will most likely choose to operate two
291 keys at any one time in order to be prepared for an emergency key
292 roll. When a TA operates multiple keys, each key MUST use its own CA
293 repository publication point as described in [RFC6481]. The CRL and
294 Manifest [RFC6486] for each of these keys will be unique to each key,
295 but the TA MUST ensure that equivalent CA certificates and RPKI
296 signed objects are issued under each key. Note that this is similar
297 to how such certificates and RPKI signed objects are re-issued as
298 part of a lower level CA key roll, described in section 4 of
299 [RFC6489].
301 4.1. Prepare a new TA key
303 The Trust Anchors MUST generate a new key pair and generate a new TA
304 Certificate. For the Subject Information Access (see section 4.8.8.1
305 of [RFC6487]) this MUST use URIs that will be used by the new key to
306 publish objects. These URIs MUST be uniqe for use by this new key
307 only. The Internet Number Resources on this new certificate MUST be
308 equivalent to those found on the current certificate.
310 The new TA certificate MUST be published under one or more new
311 Certificate URIs for use by this new key only.
313 As decribed above, the TA MUST issue and publish equivalent CA
314 certificates and RPKI signed objects under this new key.
316 It is RECOMMENDED that the TA now generates a new TAL
317 [I-D.ietf-sidrops-https-tal] and verifies that the new Trust Anchor
318 certificate can be retrieved from all locations, and that it
319 generates the same results when it is used for top-down validation
320 instead of (any of) the current TA key(s).
322 Note that the TA MAY choose to make this TAL available to Relying
323 Parties, in particular to those that do not support TAK objects, and
324 for inclusion in the distribution of RP software in order to minimise
325 the overhead in bootstrapping fresh installations.
327 4.2. Publishing for Multiple TA Keys
329 If a TA uses a single remote publication server for its keys using
330 the RPKI publication protocol [RFC8181], then it MUST include all
331 and PDUs for the products of each of its keys
332 in a single query in order to ensure that they will reflect the same
333 content at all times.
335 If a TA uses multiple publication servers then it is by definition
336 inevitable that the content of different keys will be out of sync at
337 times. In such cases the TA SHOULD ensure that the duration of these
338 moments are limited to the shortest possible time. Furthermore the
339 following should be observed:
341 o It is strongly RECOMMENDED that TAs do not issue any RPKI Signed
342 Objects, such as ROAs [RFC6482], but limit their operations to
343 maintaining a CRL, Manifest and CA certificates only. If an
344 organisation maintaining a TA has an operational need for such
345 objects then it is strongly RECOMMENDED that they operate a
346 separate non-TA CA as a child of their TA for these operations.
347 If this approach is used the remaining issues regarding temporary
348 inconsistencies between multiple TA key repository publication
349 points is greatly reduced.
351 o In cases where a CA certificate is revoked completely, or replaced
352 by a certifcate with a reduced set of resources, these changes
353 will not take effect fully until all the TA keys repository
354 publication points have been updated. Given that TA key
355 operations are normally performed infrequently we don't expect
356 that this is a problem. I.e. if the revocation or shrinking of an
357 issued CA certificate is staged for days, or weeks anyway, then
358 experiencing a delay of several minutes for the repository
359 publication points to all be updated is fairly insignificant.
361 o In cases where a CA certificate is replaced by a certifcate with
362 an extend set of resources the TA MUST inform the receiving CA
363 only after all its repository publication points have been
364 updated. This ensures that the receiveing CA will not issue any
365 products that could be invalid if an RP uses a TA key just before
366 the CA certificate was due to be updated.
368 5. TAK Object Generation and Publication
370 A TA MAY choose to use TAK objects to communicate its set of current,
371 and revoked keys. If a TA chooses to use TAK objects, then it SHOULD
372 generate and publish TAK objects under each of its current keys. An
373 exception to this rule exists when a TA has lost permanent access to
374 one of its keys or the accompanying repository publication point. In
375 such cases however, the key in question MUST be revoked as described
376 below in Section 6.
378 A non-normative guideline for naming this object is that the filename
379 chosen for the Signed TAL Object in the publication repository be a
380 value derived from the public key part of the entity's key pair,
381 using the algorithm described for CRLs in section 2.2 of [RFC6481]
382 for generation of filenames. The filename extension of ".tak" MUST
383 be used to denote the object as a TAK. Note that this is in-line
384 with filename extensions defined in section 7.2 of [RFC6481]
386 In order to generate the TAK Objects, the TA MUST perform the
387 following actions:
389 o The TA MUST generate a key pair for a "one-time-use" EE
390 certificate to use for the TAK
392 o The TA MUST generate a one-time-use EE certificate for the TAK
394 o This EE certificate MUST have an SIA extension access description
395 field with an accessMethod OID value of id-ad-signedobject, where
396 the associated accessLocation references the publication point of
397 the TAK as an object URL.
399 o As described in [RFC6487], an [RFC3779] extension is required in
400 the EE certificate used for this object. However, because the
401 resource set is irrelevant to this object type, this certificate
402 MUST describe its Internet Number Resources (INRs) using the
403 "inherit" attribute, rather than explicit description of a
404 resource set.
406 o This EE certificate MUST have a "notBefore" time that matches, or
407 predates the moment that the TAK will be published.
409 o This EE certificate MUST have a "notAfter" time that reflects the
410 intended duration for which this TAK will be published. If the EE
411 certificate for a Signed TAL is expired, it MUST no longer be
412 published, but it MAY be replaced by a newly generated TAK object
413 with equivalent content and an updated "notAfter" time.
415 o The same set of current keys (see Section 3.2.2) MUST be included
416 on each TAK object for each current key.
418 o The TAK object MUST include all revoked keys (see Section 3.2.3)
419 that became revoked while the key signing the TAK in question was
420 current.
422 6. Performing TA Key Rolls
423 6.1. Opting in to Key Rolls
425 6.1.1. Trust Anchor
427 For simplicitly let's start with a situation where a TA has only one
428 key. The TA wants to start using TAK objects to perform key rolls in
429 future, so it introduces a TAK object under its single key 'A'. The
430 repository structure looks as follows (irrelevant details omitted):
432 +--------------------+
433 | A.MFT |
434 +--------------------+
435 | A.CRL |
436 | A.TAK |
437 | C1-A.CER |
438 | C2-A.CER |
439 +--------------------+
441 +--------------------+
442 | A.CRL |
443 +--------------------+
444 | revocations.. |
445 +--------------------+
447 +--------------------+
448 | A.TAK |
449 +--------------------+
450 | current: A |
451 | revoked: none |
452 +--------------------+
454 +--------------------+
455 | C1-A.CER |
456 +--------------------+
457 | resources: C1 res |
458 | subject: C1 name |
459 | pub key: C1 key |
460 | SIA: C1 SIAs |
461 | AKI: A |
462 +--------------------+
464 +--------------------+
465 | C2-A.CER |
466 +--------------------+
467 | resources: C2 res |
468 | subject: C2 name |
469 | pub key: C2 key |
470 | SIA: C2 SIAs |
471 | AKI: A |
472 +--------------------+
474 So, the TA publishes a CRL and MFT under its key A, listing a TAK
475 object and in this case two certificates issued to children 'C1' and
476 'C2' signed using key A. The TAK object lists key 'A' as the only
477 current key, and has no revoked keys.
479 6.1.2. Relying Parties
481 Relying Parties who have a TAL for key 'A' configured will discover
482 the TAK object. If the RP does not support this object, it will
483 reject this object but continue to validate the remaining RPKI tree
484 as usual. If the RP does support TAK objects it will conclude that
485 key 'A' is the one and only current key, and will proceed to validate
486 the remaining RPKI tree as usual.
488 6.2. Pre-stage a New Key
490 6.2.1. Trust Anchor
492 Now the TA prestages a new key 'B' and produces equivalent CA
493 certificates for children 'C1' and 'C2', i.e. the resources, subject
494 name, public key and SIA etc are all equivalent, but these
495 certificates are signed under key 'B'. (See Section 4 for a more
496 thorough description of this). The TAK object for key 'B' recognises
497 both keys 'A' and 'B' as current.
499 The repostory structure and TAK object for key B are then as follows:
501 +--------------------+
502 | B.MFT |
503 +--------------------+
504 | B.CRL |
505 | B.TAK |
506 | C1-B.CER |
507 | C2-B.CER |
508 +--------------------+
510 +--------------------+
511 | B.CRL |
512 +--------------------+
513 | revocations.. |
514 +--------------------+
516 +--------------------+
517 | B.TAK |
518 +--------------------+
519 | current: A, B |
520 | revoked: none |
521 +--------------------+
523 +--------------------+
524 | C1-B.CER |
525 +--------------------+
526 | resources: C1 res |
527 | subject: C1 name |
528 | pub key: C1 key |
529 | SIA: C1 SIAs |
530 | AKI: B |
531 +--------------------+
533 +--------------------+
534 | C2-B.CER |
535 +--------------------+
536 | resources: C2 res |
537 | subject: C2 name |
538 | pub key: C2 key |
539 | SIA: C2 SIAs |
540 | AKI: B |
541 +--------------------+
543 When the TA is certain that the content for key 'B' is correct, it
544 can also update the TAK object for key 'A' to include 'B':
546 +--------------------+
547 | A.TAK |
548 +--------------------+
549 | current: A, B |
550 | revoked: none |
551 +--------------------+
553 One way to do this is by generating a TAL
554 [I-D.ietf-sidrops-https-tal] for key B and verifying that validation
555 using this yields the same results as validation using the TAL for
556 key A would. However, note, that it is preferred that this is done
557 as part of an automated process that is sufficiently well tested, and
558 that the contents of the repositories for keys 'A' and 'B' are
559 updated as a single delta if the publication protocol [RFC8181] is
560 used (see also: Section 5).
562 6.2.2. Relying Parties
564 Relying Parties who have a TAL for key 'A' configured will discover
565 the TAK object. If the RP does not support this object, it will
566 reject this object but continue to validate the remaining RPKI tree
567 as usual. If the RP does support TAK objects it will conclude that
568 there are now two keys 'A' and 'B', and no revoked keys that it
569 should be aware of. Since key 'A' is still current, the RP will
570 continue to validate the RPKI tree structure using the repository for
571 key 'A', ignoring the non-TAK objects in the repository for key 'B'.
573 The result will be the same for Relying Parties who have a TAL for
574 key 'B' configured, because both keys are equivalent at this time.
576 6.3. Planned Key Revocation
578 6.3.1. Trust Anchor
580 The TA has now decided that key 'A' must be revoked. It still has
581 access to this key and the repository, so it can perform a planned
582 key roll. In addition to revoking key 'A', the TA will also generate
583 new key 'C' to ensure that it has at least two current keys at all
584 times for redundancy.
586 Keys 'B' and 'C' will become current keys on the TAK objects for all
587 keys: 'A', 'B' and 'C'. Key 'A' will become part of the revoked keys
588 on the TAK objects for keys 'A' and 'B'. Note that it is not needed
589 to list key 'A' as revoked on the TAK file for key 'C', because RPs
590 will only learn about key 'C' at the same time as learning about the
591 revocation of key 'A' (see also below).
593 The TA will publish a long-lived TAK file and MFT and CRL only for
594 key 'A' and publish these objects as waypointers for RPs that have a
595 TAL pointing at key 'A' before destroying key 'A'.
597 The resulting structure for key 'A' will be as follows:
599 +--------------------+
600 | A.MFT |
601 +--------------------+
602 | A.CRL |
603 | A.TAK |
604 +--------------------+
606 +--------------------+
607 | A.CRL |
608 +--------------------+
609 | revocations.. |
610 +--------------------+
612 +--------------------+
613 | A.TAK |
614 +--------------------+
615 | current: B, C |
616 | revoked: A |
617 +--------------------+
619 The resulting structures for keys 'B' and 'C' will be as follows:
621 +--------------------+ +--------------------+
622 | B.MFT | | C.MFT |
623 +--------------------+ +--------------------+
624 | B.CRL | | B.CRL |
625 | B.TAK | | B.TAK |
626 | C1-B.CER | | C1-C.CER |
627 | C2-B.CER | | C2-C.CER |
628 +--------------------+ +--------------------+
630 +--------------------+ +--------------------+
631 | B.CRL | | C.CRL |
632 +--------------------+ +--------------------+
633 | revocations.. | | revocations.. |
634 +--------------------+ +--------------------+
636 +--------------------+ +--------------------+
637 | B.TAK | | C.TAK |
638 +--------------------+ +--------------------+
639 | current: B, C | | current: B, C |
640 | revoked: A | | revoked: |
641 +--------------------+ +--------------------+
643 +--------------------+ +--------------------+
644 | C1-B.CER | | C1-C.CER |
645 +--------------------+ +--------------------+
646 | resources: C1 res | | resources: C1 res |
647 | subject: C1 name | | subject: C1 name |
648 | pub key: C1 key | | pub key: C1 key |
649 | SIA: C1 SIAs | | SIA: C1 SIAs |
650 | AKI: B | | AKI: C |
651 +--------------------+ +--------------------+
653 +--------------------+ +--------------------+
654 | C2-B.CER | | C2-B.CER |
655 +--------------------+ +--------------------+
656 | resources: C2 res | | resources: C2 res |
657 | subject: C2 name | | subject: C2 name |
658 | pub key: C2 key | | pub key: C2 key |
659 | SIA: C2 SIAs | | SIA: C2 SIAs |
660 | AKI: B | | AKI: B |
661 +--------------------+ +--------------------+
663 In addition to this the TA SHOULD reach out to RP vendors so that
664 they can update the TAL included in the RP software distribution to
665 use key 'B'.
667 6.3.2. Relying Parties
669 Relying Parties who have a TAL for key 'A' configured will discover
670 the TAK object. If the RP does not support this object, it will
671 reject this object but continue to validate the remaining RPKI tree
672 as usual. In this case that means that validation will stop, because
673 there are no more objects under key 'A'. Therefore it is important
674 that RPs that do not support TAK files are updated to use the TAL for
675 key 'B' through some other process.
677 If the RP uses a TAL for key 'A' and it supports TAK objects, it will
678 discover that the TAL for key 'A' has keys 'B' and 'C' as current,
679 and revokes itself. It will then proceed to process keys 'B' and 'C'
680 and find TALs which list the same current keys. So, it will now
681 replace its notion of the current key set for this TA based on its
682 TAL (key 'A') with what it learned. To keep things simple the RP
683 will now conclude that it should re-start validation using a
684 remaining current key, in this case key either 'B' or 'C' may be
685 used.
687 If the RP already had a TAL for key 'B' and it supports TAK objects,
688 or it simply started with key 'B' because it added it to its set of
689 current keys when this key was pre-staged (see Section 6.2), it will
690 learn that key 'A' is revoked and therefore will not attempt to
691 verify the TAK file for key 'A'. It will also learn about key 'C'
692 and inspect this key's TAL, and discover that only keys 'B' and 'C'
693 are considered current. Since it started the validation process with
694 a key that is still current, it can proceed to validate the RPKI tree
695 using the repository under key 'B'.
697 6.4. Unplanned revocation
699 6.4.1. Trust Anchor
701 Now keys 'B' and 'C' are current. The TA may have intended to revoke
702 key 'B', essentially rolling over to key 'C' and a new key 'D', but
703 let us suppose that the TA lost access to key 'C'. In this case the
704 TA will simply revoke key 'C' instead, and still introduce a new key
705 'D'.
707 The major difference with the process described above for planned
708 rolls, is that now the TA will not be able to update the TAK object,
709 MFT or CRL for key 'C'. However, because all TAL objects for current
710 keys are evaluated before tree validation is performed, it is safe to
711 leave these objects in a repository. Keys 'B' and 'D' will simply
712 mark key 'C' as being revoked.
714 If an RP still has a TAL pointing at key 'C' it will discover that
715 key 'D' is added, and that key 'B' has been revoked through the TAK
716 object published for keys 'B' and 'D'. At least, as long as the the
717 MFT and TAK EE certificates have not expired, and the CRL and MFT are
718 not stale.
720 If the TA is absolutely sure that the TAL for key 'C' never shipped
721 with any RP distribution, then it would also be safe to delete the
722 repository key 'C' altogether. RPs will learn that 'C' is revoked,
723 and therefore will not even attempt to download the TAK object.
724 However, it is hard to be certain of this and there this is NOT
725 RECOMMENDED.
727 7. Deployment Considerations
729 Including Signed TAL objects while RP tools do not support this
730 standard will result in these RPs rejecting these objects. It is not
731 expected that this will result in the invalidation of any other
732 object under a Trust Anchor.
734 That said, the flagging mechanism introduced here can only be relied
735 on once a majority of RPs support it. Defining when that moment
736 arrives is by definition something that cannot be established at the
737 time of writing this document. Until such time, TAs SHOULD continue
738 to generate unsigned TAL files [I-D.ietf-sidrops-https-tal], and
739 indicate which should be considered their current TAL, and
740 communicate them to RPs through other means.
742 However, once a majority of RPs support this mechanism it would be
743 RECOMMENDED that Trust Anchor operators perform key rolls regularly.
744 The most assured way to know that such key rolls will work is by
745 making them a part of normal operations. Determining when this
746 moment arrives is by definition out of scope for this document, as it
747 should be based on operational experience.
749 8. IANA Considerations
751 8.1. OID
753 IANA is to add the following to the "RPKI Signed Objects" registry:
755 Decimal | Description | References
756 --------+--------------------------------+---------------
757 TBD | Trust Anchor Keys | [section 3.1]
759 8.2. File Extension
761 IANA is to add an item for the Signed TAL file extension to the "RPKI
762 Repository Name Scheme" created by [RFC6481] as follows:
764 Extension | RPKI Object | References
765 -----------+-------------------------------------------
766 .tak | Trust Anchor Keys | [this document]
768 9. Security Considerations
770 TBD
772 10. Acknowledgements
774 The authors wish to thank Martin Hoffmann for a thourough review of
775 this document.
777 11. References
779 11.1. Normative References
781 [I-D.ietf-sidrops-https-tal]
782 Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
783 Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
784 Trust Anchor Locator", draft-ietf-sidrops-https-tal-05
785 (work in progress), October 2018.
787 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
788 Requirement Levels", BCP 14, RFC 2119,
789 DOI 10.17487/RFC2119, March 1997,
790 .
792 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
793 Addresses and AS Identifiers", RFC 3779,
794 DOI 10.17487/RFC3779, June 2004,
795 .
797 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
798 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010,
799 .
801 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
802 Resource Certificate Repository Structure", RFC 6481,
803 DOI 10.17487/RFC6481, February 2012,
804 .
806 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
807 Origin Authorizations (ROAs)", RFC 6482,
808 DOI 10.17487/RFC6482, February 2012,
809 .
811 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski,
812 "Manifests for the Resource Public Key Infrastructure
813 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012,
814 .
816 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
817 X.509 PKIX Resource Certificates", RFC 6487,
818 DOI 10.17487/RFC6487, February 2012,
819 .
821 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
822 Template for the Resource Public Key Infrastructure
823 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
824 .
826 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification
827 Authority (CA) Key Rollover in the Resource Public Key
828 Infrastructure (RPKI)", BCP 174, RFC 6489,
829 DOI 10.17487/RFC6489, February 2012,
830 .
832 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
833 Protocol (HTTP/1.1): Message Syntax and Routing",
834 RFC 7230, DOI 10.17487/RFC7230, June 2014,
835 .
837 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
838 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
839 May 2017, .
841 [RFC8181] Weiler, S., Sonalker, A., and R. Austein, "A Publication
842 Protocol for the Resource Public Key Infrastructure
843 (RPKI)", RFC 8181, DOI 10.17487/RFC8181, July 2017,
844 .
846 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
847 "Information technology - ASN.1 encoding rules:
848 Specification of Basic Encoding Rules (BER), Canonical
849 Encoding Rules (CER) and Distinguished Encoding Rules
850 (DER)", 2002.
852 11.2. Informative References
854 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
855 RFC 5652, DOI 10.17487/RFC5652, September 2009,
856 .
858 Authors' Addresses
860 Tim Bruijnzeels
861 NLnet Labs
863 Email: tim@nlnetlabs.nl
864 URI: https://www.nlnetlabs.nl/
866 Carlos Martinez
867 LACNIC
869 Email: carlos@lacnic.net
870 URI: https://www.lacnic.net/
872 Rob Austein
873 Dragon Research Labs
875 Email: sra@hactrn.net