idnits 2.17.1
draft-ietf-sidrops-signed-tal-03.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 (July 8, 2019) is 1753 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 Network Working Group T. Bruijnzeels
3 Internet-Draft NLnet Labs
4 Intended status: Standards Track C. Martinez
5 Expires: January 9, 2020 LACNIC
6 R. Austein
7 Dragon Research Labs
8 July 8, 2019
10 RPKI Signed Object for Trust Anchor Keys
11 draft-ietf-sidrops-signed-tal-03
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 January 9, 2020.
42 Copyright Notice
44 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . 2
60 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
61 3. TAK Object definition . . . . . . . . . . . . . . . . . . . . 4
62 3.1. The TAK Object Content Type . . . . . . . . . . . . . . . 4
63 3.2. The TAK Object eContent . . . . . . . . . . . . . . . . . 4
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. TAK Object Generation and Publication . . . . . . . . . . . . 6
69 5. Relying Party Use . . . . . . . . . . . . . . . . . . . . . . 7
70 6. Maintaining multiple TA keys . . . . . . . . . . . . . . . . 8
71 7. Performing TA Key Rolls . . . . . . . . . . . . . . . . . . . 10
72 7.1. Phase 1: Add a TAK for Key 'A' . . . . . . . . . . . . . 10
73 7.2. Phase 2: Add a Key 'B' . . . . . . . . . . . . . . . . . 10
74 7.3. Phase 3: Roll to Key 'C' . . . . . . . . . . . . . . . . 11
75 7.3.1. Planned Direction Roll . . . . . . . . . . . . . . . 11
76 7.3.2. Unplanned Direction Roll . . . . . . . . . . . . . . 11
77 7.4. Phase X: Roll to Key 'D', 'E', .. . . . . . . . . . . . . 12
78 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 12
79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
81 10.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . 13
82 10.2. File Extension . . . . . . . . . . . . . . . . . . . . . 13
83 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
84 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
85 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
86 13.1. Normative References . . . . . . . . . . . . . . . . . . 13
87 13.2. Informative References . . . . . . . . . . . . . . . . . 15
88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
90 1. Requirements notation
92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
94 "OPTIONAL" in this document are to be interpreted as described in BCP
95 14 [RFC2119] [RFC8174] when, and only when, they appear in all
96 capitals, as shown here.
98 2. Overview
100 Trust Anchor Locators (TALs) [I-D.ietf-sidrops-https-tal] are used by
101 Relying Parties in the RPKI to locate and validate Trust Anchor (TA)
102 certificates used in RPKI validation. However, until now there has
103 been no formal way of notifying Relying Parties (RP) of updates to a
104 TAL. Such updates may be needed in particular in case a Trust Anchor
105 needs to perform a planned, or unplanned, key roll.
107 This document defines a new RPKI signed object that can be used to
108 document the current set of keys and the location(s) of the
109 accompanying CA certificates, as well as any changes to this set.
110 This allows RPs to be notified automatically of such changes, and
111 enables Trust Anchors to pre-stage a number of operational keys so
112 that planned and unplanned key rolls can be performed without risking
113 the invalidation of the RPKI tree under the TA. We call this object
114 the Trust Anchor Keys (TAK) object.
116 When Relying Parties (RPs) are first bootstrapped, they use any
117 current TAL to discover a key and location(s) of the TA
118 certificate(s) for a TA. The RP can then retrieve and validating the
119 TA certificate, and subsequently validate the manifest [RFC6486] and
120 CRL [section 5 of @!RFC6487]. However, before processing any other
121 objects it will then first validate the TAK object, if present. All
122 enumerated new keys (and locations) are then added to a new list of
123 current TA keys for this TA. The RP will then recursively fetch and
124 validate the TA certificates, manifest, CRL and TAK objects for each
125 of these keys. As a part of this process the RP will also compile a
126 list of revoked keys enumerated by any of the validly signed TAK
127 objects. As the final step the RP will then filter out any revoked
128 TA keys from its new set. This new set now replaces the previous
129 set.
131 This process allows Trust Anchors to operate a set of N current keys,
132 where any key can effectively revoke any or all of the other keys to
133 perform either a planned, or an unplanned, key roll. This also
134 allows Trust Anchors to produce long lived TAK objects as forward
135 pointers to RPs, and retire its old key when doing a key roll. While
136 the generic process is quite involved, the amount of work needed to
137 support an envisioned normal key roll is fairly limited. Under
138 normal circumstances a TA will typically have two current keys, so
139 that is can perform an emergency roll over in case one of the keys is
140 lost. This means that the RP will need to validate one additional CA
141 certificate, a CRL, a manifest and two TAK objects.
143 When a key roll is executed a TA will remove one old key, and
144 introduce one new (back-up) key. The RP will remove the old key from
145 its set, and it will not be queried again, and it will add the new
146 key and its TA certifcate location(s).
148 Only in a situation where an RP is very outdated can it be expected
149 that the RP will have to discover several chained TAK object. But,
150 since it will remove the outdated TALs in this process, this presents
151 a one time cost only.
153 3. TAK Object definition
155 The TAK object makes use of the template for RPKI digitally signed
156 objects [RFC6488], which defines a Crytopgraphic Message Syntax (CMS)
157 [RFC5652] wrapper for the Signed TALs content as well as a generic
158 validation procedure for RPKI signed objects. Therefore, to complete
159 the specification of the TAK object (see Section 4 of [RFC6488]),
160 this document defines:
162 o The OID defined in Section 3.1 that identifies the signed object
163 as being a TAK. (This OID appears within the eContentType in the
164 encapContentInfo object as well as the content-type signed
165 attribute in the signerInfo object).
167 o The ASN.1 syntax for the TAK eContent defined in Section 3.2.
169 o Additional steps to the validation steps specified in [RFC6488]
170 required to validate the TAK, defined in Section 3.3.
172 3.1. The TAK Object Content Type
174 This document requests an OID for TAK objects as follows:
176 signed-Tal OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
177 rsadsi(113549) pkcs(1) pkcs9(9) 16 id-smime (1) TBD }
179 This OID MUST appear both within the eContentType in the
180 encapContentInfo object as well as the content-type signed attribute
181 in the signerInfo object (see [RFC6488])
183 3.2. The TAK Object eContent
185 The content of a TAK object is ASN.1 encoded using the Distinguished
186 Encoding Rules (DER) [X.690], and is defined as follows:
188 TAK ::= SEQUENCE {
189 version INTEGER DEFAULT 0,
190 current ::= SEQUENCE SIZE (1..MAX) OF CurrentKey,
191 revoked ::= SEQUENCE OF SubjectPublicKeyInfo
192 }
194 CurrentKey ::= SEQUENCE {
195 certificateURIs SEQUENCE SIZE (1..MAX) OF CertificateURI,
196 subjectPublicKeyInfo SubjectPublicKeyInfo
197 }
199 CertificateURI ::= IA5String
201 SubjectPublicKeyInfo ::= SEQUENCE {
202 algorithm AlgorithmIdentifier,
203 subjectPublicKey BIT STRING
204 }
206 3.2.1. version
208 The version number of the TAK object MUST be 0.
210 3.2.2. current
212 This field defines the set of current keys (CurrentKey) according to
213 the signer of this Signed TALs object.
215 3.2.2.1. CurrentKey
217 This field defines a current TA Key, equivalent to [I-D.ietf-sidrops-
218 https-tal]. This structure contains a sequence of one or more URIs
219 and a SubjectPublicKeyInfo.
221 3.2.2.1.1. certificateURIs
223 This field is equivalent to the URI section in section 2.1 of
224 [I-D.ietf-sidrops-https-tal]. It MUST contain at least one
225 CertificateURI element. Each CertificateURI element contains the
226 IA5String representation of either an rsync URI [RFC5781], or an
227 HTTPS URI [RFC7230].
229 3.2.2.1.2. subjectPublicKeyInfo
231 This field contains a SubjectPublicKeyInfo [section 4.1.2.7 or
232 @!RFC5280] in DER format [X.690].
234 3.2.3. revoked
236 This field contains the list of keys, identified by
237 SubjectPublicKeyInfo, that are no longer to be used according to the
238 signer of this document.
240 3.3. TAK Object Validation
242 To determine whether a TAK object is valid, the RP MUST perform the
243 following steps in addition to those specified in [RFC6488]:
245 o The eContentType OID matches the OID described in Section 3.1
247 o The TAK object appears as the product of a Trust Anchor CA
248 certificate.
250 o This Trust Anchor CA has published only one TAK object in its
251 repository for this key, and this object appears on the Manifest
252 as the only entry using the ".tak" extension (see [RFC6481]). In
253 case more than one TAK object is found, all such objects MUST be
254 considered invalid.
256 o The EE certificate of this TAK object describes its Internet
257 Number Resources (INRs) using the "inherit" attribute
259 o The decoded TAK content conforms to the format defined in
260 Section 3.2.
262 If the above procedure indicates that the manifest is invalid, then
263 the TAK object MUST be discarded and treated as though no TAK object
264 were present.
266 4. TAK Object Generation and Publication
268 A TA MAY choose to use TAK objects to communicate its set of current,
269 and revoked keys. If a TA chooses to use TAK objects, then it SHOULD
270 generate and publish TAK objects under each of its current keys. An
271 exception to this rule exists when a TA has lost permanent access to
272 one of its keys or the accompanying repository publication point. In
273 such cases however, the key in question MUST be revoked as described
274 below in Section 7.
276 A non-normative guideline for naming this object is that the filename
277 chosen for the Signed TAL Object in the publication repository be a
278 value derived from the public key part of the entity's key pair,
279 using the algorithm described for CRLs in section 2.2 of [RFC6481]
280 for generation of filenames. The filename extension of ".tak" MUST
281 be used to denote the object as a TAK. Note that this is in-line
282 with filename extensions defined in section 7.2 of [RFC6481]
284 In order to generate the TAK Objects, the TA MUST perform the
285 following actions:
287 o The TA MUST generate a key pair for a "one-time-use" EE
288 certificate to use for the TAK
290 o The TA MUST generate a one-time-use EE certificate for the TAK
292 o This EE certificate MUST have an SIA extension access description
293 field with an accessMethod OID value of id-ad-signedobject, where
294 the associated accessLocation references the publication point of
295 the TAK as an object URL.
297 o As described in [RFC6487], an [RFC3779] extension is required in
298 the EE certificate used for this object. However, because the
299 resource set is irrelevant to this object type, this certificate
300 MUST describe its Internet Number Resources (INRs) using the
301 "inherit" attribute, rather than explicit description of a
302 resource set.
304 o This EE certificate MUST have a "notBefore" time that matches, or
305 predates the moment that the TAK will be published.
307 o This EE certificate MUST have a "notAfter" time that reflects the
308 intended duration for which this TAK will be published. If the EE
309 certificate for a Signed TAL is expired, it MUST no longer be
310 published, but it MAY be replaced by a newly generated TAK object
311 with equivalent content and an updated "notAfter" time.
313 o The same set of current keys (see Section 3.2.2) MUST be included
314 on each TAK object for each current key.
316 o The TAK object MUST include all revoked keys (see Section 3.2.3)
317 that became revoked while the key signing the TAK in question was
318 current.
320 5. Relying Party Use
322 Relying Parties MUST keep a record of all current keys for each
323 configured Trust Anchor, as well as the URI(s) where the CA
324 certificate for each of these keys may be retrieved. This record MAY
325 be bootstrapped by the use of a pre-configured (and unsigned) TAL
326 file [I-D.ietf-sidrops-https-tal], but it MUST be updated with
327 authoritative signed information found in valid TAK objects found in
328 subsequent validation runs.
330 When performing top-down validation RPs MUST first validate and
331 process any TAK objects for each of its known current keys for a TA
332 by performing the following steps:
334 o A CA certificate is retrieved and validated from the known URIs as
335 described in sections 3 and 4 of [I-D.ietf-sidrops-https-tal].
337 o The manifest and CRL for this certificate are then validated first
338 as described in [RFC6487] and [RFC6486].
340 o The TAK file, if present, is validated as described in
341 Section 3.3.
343 For each valid TAK file thus found all current keys, i.e.
344 SubjectPublicKeyInfo and URIs, are kept. If any previously unknown
345 keys are added to the set of current keys, then they MUST also be
346 processed as described above.
348 Once the TAK objects for all keys are processed the set of current
349 keys and URIs for the TA is updated as follows: * All new current
350 keys found on any valid TAK object are added to the set of current
351 keys. * The set of URIs for each current key is replaced by the
352 union of all URIs for this key found on all valid TAK objects. *
353 Finally, any current key that matches any revoked key on any valid
354 TAK object is removed from the set of current keys.
356 Note that if a current key does not occur on any valid TAK object,
357 but it is not revoked either, then it and any previously known URIs
358 for it are kept. Also note that if an RP was bootstrapped using a
359 TAL file [I-D.ietf-sidrops-https-tal], the keys and URIs will now
360 have been replaced by values found on TAK objects.
362 After this the RP can choose any one of the valid CA certificates for
363 any key that is still in the set of current keys for this TA, in
364 order to continue the top-down validation of object for this TA as
365 described in [RFC6487].
367 6. Maintaining multiple TA keys
369 If a TA operates multiple keys, then the signed material for these
370 keys MUST be published under different directories in the context of
371 the 'id-ad-caRepository' and 'id-ad-rpkiManifest' Subject Information
372 Access descriptions contained on the CA certificates [RFC6487].
373 Publishing objects under the same space would lead to confusion at
374 best, and in case of file name collisions of objects invalidity.
376 However, the CA certificates for each key, and the contents published
377 by each key MUST be equivalent. In other words it MUST not make a
378 difference which of the keys is used as a starting point for top-down
379 validation by RP software.
381 This means that the IP and AS resources contained on all current CA
382 certificates for the current TA keys MUST be the same. Furthermore
383 for any delegation of IP and AS resources to a child, the TA MUST
384 have an equivalent CA certificate published under each of its keys.
385 Any updates in delegations MUST be reflected under each of its keys.
386 A TA SHOULD NOT publish any other objects besides a CRL, a Manifest,
387 a single TAK object, and any number of CA certificates for delegation
388 to child Certification Authorities.
390 If a TA uses a single remote publication server for its keys using
391 the RPKI publication protocol [RFC8181], then it MUST include all
392 and PDUs for the products of each of its keys
393 in a single query in order to ensure that they will reflect the same
394 content at all times.
396 If a TA uses multiple publication servers then it is by definition
397 inevitable that the content of different keys will be out of sync at
398 times. In such cases the TA SHOULD ensure that the duration of these
399 moments are limited to the shortest possible time. Furthermore the
400 following should be observed:
402 o In cases where a CA certificate is revoked completely, or replaced
403 by a certificate with a reduced set of resources, these changes
404 will not take effect fully until all the TA keys repository
405 publication points have been updated. Given that TA key
406 operations are normally performed infrequently we don't expect
407 that this is a problem. I.e. if the revocation or shrinking of an
408 issued CA certificate is staged for days, or weeks anyway, then
409 experiencing a delay of several minutes for the repository
410 publication points to all be updated is fairly insignificant.
412 o In cases where a CA certificate is replaced by a certificate with
413 an extend set of resources the TA MUST inform the receiving CA
414 only after all its repository publication points have been
415 updated. This ensures that the receiving CA will not issue any
416 products that could be invalid if an RP uses a TA key just before
417 the CA certificate was due to be updated.
419 Finally, note that the publication locations of CA certificates for
420 delegations to child CAs under each key will be different, and
421 therefore the Authority Information Access 'id-ad-caIssuers' value on
422 certificates issued by the child CAs may not match (section 4.8.7 of
423 [RFC6487]). However, this information is not considered critical for
424 validation of these objects and provided as hints to RP software
425 only. Therefore RP software MUST NOT reject these certificates based
426 on a mismatch of this value.
428 7. Performing TA Key Rolls
430 In this section we will describe how present day RPKI TAs that use
431 only one key pair, and that do not use TAK objects, can change to
432 having two current keys at all times allowing them to perform both
433 planned and unplanned key rolls.
435 7.1. Phase 1: Add a TAK for Key 'A'
437 Before adding any new keys a Trust Anchor may want to build up
438 operational experience in maintaining a TAK object that describes its
439 current key only. We will call refer to this key as key 'A'
440 throughout this section.
442 The TA will have a TAL file [I-D.ietf-sidrops-https-tal] that
443 contains one or more URIs where the (equivalent) CA certificates for
444 this key 'A' can be retrieved. The TA can now generate a TAK objects
445 that includes key 'A' only in its sequence of 'CurrentKey' values.
447 The TA SHOULD publish the CA certificate for key 'A' at one or more
448 new locations not used in the TAL file, and use these new URIs in the
449 TAK object. The TA is free to choose any naming strategy for these
450 locations. As a non-normative suggestion, one such approach could be
451 to use the date that this phase was started as part of the file name
452 or a directory where the CA certificate is published.
454 The TA can now monitor the retrieval of its CA certificates from the
455 URI(s) in the newly published TAK object, relative to the retrieval
456 from the URI(s) listed in its TAL file, to learn the proportion of
457 RPs that can successfully validate and use the TAK object.
459 7.2. Phase 2: Add a Key 'B'
461 The TA can now generate a new key pair, key 'B'. This key MUST now
462 be used to create a new CA certificate for this key, and issue
463 equivalent CA certificates for delegations to child CAs, as described
464 in Section 6.
466 At this point, the TA can also issue a new TAL file
467 [I-D.ietf-sidrops-https-tal] for key 'B', and test locally that the
468 validation outcome for the new key is indeed equivalent to the other
469 current key(s).
471 When the TA is certain that both keys are equivalent, it MUST issue a
472 new TAK object under each of its current keys, and include both the
473 old key 'A' and this new key 'B' in the set of current keys.
475 The TA SHOULD now also release a new TAL file for this new key 'B' as
476 the intended new key to be used by RP software. However, as
477 described above, it SHOULD use a different set of URIs in the TAL
478 compared to the TAK file, so that it can learn the proportion of RPs
479 that can successfully validate and use the updated TAK objects.
481 7.3. Phase 3: Roll to Key 'C'
483 In this phase a new key, key 'C' is generated as described above in
484 Section 7.2. And one of the previous keys is revoked.
486 7.3.1. Planned Direction Roll
488 If the key roll is planned, and the TA has access to all its keys
489 'A', 'B' and 'C', and the publication servers for each of the keys,
490 then a new TAK object is generated for each of these keys listing
491 keys 'B' and 'C' as current, and key 'A' as revoked.
493 The TA SHOULD now publish a long-lived TAK file, CRL and Manifest
494 under key 'A', remove all other content, and destroy key 'A'. This
495 way RP software that uses a TAL for key 'A' can still successfully
496 find keys 'B' and 'C', and in future 'D', 'E', etc.
498 If access to key 'A' was lost, then the process is slightly
499 different. The TAK object for key 'A' cannot be updated and will
500 therefore still refer to keys 'A' and 'B' as the current keys, and
501 include no revocations. However, an updated TAK object listing keys
502 'B' and 'C' as current, and listing key 'A' as revoked can still be
503 issued and published under keys 'B' and 'C'. As described in
504 Section 5 RPs will then discover that key 'A' is revoked, and
505 continue to use keys 'B' and 'C'.
507 7.3.2. Unplanned Direction Roll
509 If key 'B' is compromised, the process is similar to above, except of
510 course that now keys 'A' and 'C' are included in the set of current
511 keys, and key 'B' is in the set of revoked keys. If the TA still has
512 access to key 'B', then it SHOULD publish a long-lived TAK file, CRL
513 and manifest for key 'B' and remove all other content for it. If it
514 cannot perform this action then simply marking key 'B' as revoked
515 will still notify RPs to disregard it.
517 7.4. Phase X: Roll to Key 'D', 'E', ..
519 Further key rolls are essentially no different the roll to key 'C'
520 described in Section 7.3, except that there is no need to still
521 include key 'A' in the list of revoked keys when the the roll to key
522 'D' is performed. RPs will already have learned to that key 'A' is
523 revoked, before they learn about key 'D'.
525 8. Deployment Considerations
527 Including Signed TAL objects while RP tools do not support this
528 standard will result in these RPs rejecting these objects. It is not
529 expected that this will result in the invalidation of any other
530 object under a Trust Anchor.
532 That said, the flagging mechanism introduced here can only be relied
533 on once a majority of RPs support it. Defining when that moment
534 arrives is by definition something that cannot be established at the
535 time of writing this document. The use of unique URIs in TAK objects
536 compared to their equivalent TAL files should help operators
537 understand which proportion of RPs support this mechanism.
539 9. Security Considerations
541 It should be noted that because any key can revoke the other key(s),
542 a risk introduced: if an adversary can gain access to one of the
543 keys, and publication servers for it, then they can essentially take
544 over a TA. It should also be noted that a TA can revoke all of its
545 keys by accident and make itself obsolete.
547 However, these risks can be mitigated greatly by the use of Hardware
548 Security Modules (HSM) by TAs, which will guard against theft of a
549 private key, and operational processes to guard against (accidental)
550 mis-use of the keys in an HSM by operators.
552 Although HSMs can help against key theft, the risk of key loss is
553 still very applicable. In some ways more so, because back-ups are
554 hard by design. Key loss can easily happen for example when an
555 operator card set that is used to authorise use of a key in an HSM
556 can no longer be used, e.g. because cards are broken or lost, or a
557 persons who holds a card is sadly no longer with us, or passwords are
558 forgotten, etc.
560 In such cases the ability to perform an unplanned roll as described
561 in this document will be very useful, provided that access to the
562 both keys is arranged differently, and the issues affecting one key,
563 do not necessarily affect the other key.
565 An example where the planned rolls are useful is when a TA is using
566 an HSM from vendor X, and they want to migrate to an HSM from vendor
567 Y.
569 10. IANA Considerations
571 10.1. OID
573 IANA is to add the following to the "RPKI Signed Objects" registry:
575 Decimal | Description | References
576 --------+--------------------------------+---------------
577 TBD | Trust Anchor Keys | [section 3.1]
579 10.2. File Extension
581 IANA is to add an item for the Signed TAL file extension to the "RPKI
582 Repository Name Scheme" created by [RFC6481] as follows:
584 Extension | RPKI Object | References
585 -----------+-------------------------------------------
586 .tak | Trust Anchor Keys | [this document]
588 11. Security Considerations
590 TBD
592 12. Acknowledgements
594 The authors wish to thank Martin Hoffmann for a thourough review of
595 this document.
597 13. References
599 13.1. Normative References
601 [I-D.ietf-sidrops-https-tal]
602 Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
603 Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
604 Trust Anchor Locator", draft-ietf-sidrops-https-tal-08
605 (work in progress), April 2019.
607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
608 Requirement Levels", BCP 14, RFC 2119,
609 DOI 10.17487/RFC2119, March 1997,
610 .
612 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
613 Addresses and AS Identifiers", RFC 3779,
614 DOI 10.17487/RFC3779, June 2004,
615 .
617 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
618 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010,
619 .
621 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
622 Resource Certificate Repository Structure", RFC 6481,
623 DOI 10.17487/RFC6481, February 2012,
624 .
626 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski,
627 "Manifests for the Resource Public Key Infrastructure
628 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012,
629 .
631 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
632 X.509 PKIX Resource Certificates", RFC 6487,
633 DOI 10.17487/RFC6487, February 2012,
634 .
636 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
637 Template for the Resource Public Key Infrastructure
638 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
639 .
641 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
642 Protocol (HTTP/1.1): Message Syntax and Routing",
643 RFC 7230, DOI 10.17487/RFC7230, June 2014,
644 .
646 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
647 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
648 May 2017, .
650 [RFC8181] Weiler, S., Sonalker, A., and R. Austein, "A Publication
651 Protocol for the Resource Public Key Infrastructure
652 (RPKI)", RFC 8181, DOI 10.17487/RFC8181, July 2017,
653 .
655 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
656 "Information technology - ASN.1 encoding rules:
657 Specification of Basic Encoding Rules (BER), Canonical
658 Encoding Rules (CER) and Distinguished Encoding Rules
659 (DER)", 2002.
661 13.2. Informative References
663 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
664 RFC 5652, DOI 10.17487/RFC5652, September 2009,
665 .
667 Authors' Addresses
669 Tim Bruijnzeels
670 NLnet Labs
672 Email: tim@nlnetlabs.nl
673 URI: https://www.nlnetlabs.nl/
675 Carlos Martinez
676 LACNIC
678 Email: carlos@lacnic.net
679 URI: https://www.lacnic.net/
681 Rob Austein
682 Dragon Research Labs
684 Email: sra@hactrn.net