1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
|
<pre>Internet Engineering Task Force (IETF) G. Huston
Request for Comments: 6481 R. Loomans
Category: Standards Track G. Michaelson
ISSN: 2070-1721 APNIC
February 2012
<span class="h1">A Profile for Resource Certificate Repository Structure</span>
Abstract
This document defines a profile for the structure of the Resource
Public Key Infrastructure (RPKI) distributed repository. Each
individual repository publication point is a directory that contains
files that correspond to X.509/PKIX Resource Certificates,
Certificate Revocation Lists and signed objects. This profile
defines the object (file) naming scheme, the contents of repository
publication points (directories), and a suggested internal structure
of a local repository cache that is intended to facilitate
synchronization across a distributed collection of repository
publication points and to facilitate certification path construction.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6481">http://www.rfc-editor.org/info/rfc6481</a>.
<span class="grey">Huston, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6481">RFC 6481</a> ResCert Repository Structure February 2012</span>
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Terminology ................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. RPKI Repository Publication Point Content and Structure .........<a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Manifests ..................................................<a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. CA Repository Publication Points ...........................<a href="#page-6">6</a>
<a href="#section-3">3</a>. Resource Certificate Publication Repository Considerations ......<a href="#page-8">8</a>
<a href="#section-4">4</a>. Certificate Reissuance and Repositories ........................<a href="#page-10">10</a>
<a href="#section-5">5</a>. Synchronizing Repositories with a Local Cache ..................<a href="#page-10">10</a>
<a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-11">11</a>
<a href="#section-7">7</a>. IANA Considerations ............................................<a href="#page-12">12</a>
<a href="#section-7.1">7.1</a>. Media Types ...............................................<a href="#page-12">12</a>
<a href="#section-7.1.1">7.1.1</a>. application/rpki-manifest ..........................<a href="#page-12">12</a>
<a href="#section-7.1.2">7.1.2</a>. application/rpki-roa ...............................<a href="#page-13">13</a>
<a href="#section-7.2">7.2</a>. RPKI Repository Name Scheme Registry ......................<a href="#page-13">13</a>
<a href="#section-8">8</a>. Acknowledgements ...............................................<a href="#page-13">13</a>
<a href="#section-9">9</a>. References .....................................................<a href="#page-14">14</a>
<a href="#section-9.1">9.1</a>. Normative References ......................................<a href="#page-14">14</a>
<a href="#section-9.2">9.2</a>. Informative References ....................................<a href="#page-14">14</a>
<span class="grey">Huston, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6481">RFC 6481</a> ResCert Repository Structure February 2012</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
To validate attestations made in the context of the Resource Public
Key Infrastructure (RPKI) [<a href="./rfc6480" title=""An Infrastructure to Support Secure Internet Routing"">RFC6480</a>], relying parties (RPs) need
access to all the X.509/PKIX Resource Certificates, Certificate
Revocation Lists (CRLs), and signed objects that collectively define
the RPKI.
Each issuer of a certificate, CRL, or a signed object makes it
available for download to RPs through the publication of the object
in an RPKI repository.
The repository system is a collection of all signed objects that MUST
be globally accessible to all RPs. When certificates, CRLs and
signed objects are created, they are uploaded to a repository
publication point, from whence they can be downloaded for use by RPs.
This profile defines the recommended object (file) naming scheme, the
recommended contents of repository publication points (directories),
and a suggested internal structure of a local repository cache that
is intended to facilitate synchronization across a distributed
collection of repository publication points and facilitate
certification path construction.
A resource certificate attests to a binding of an entity's public key
to a set of IP address blocks and AS numbers. The subject of a
resource certificate can demonstrate that it is the holder of the
resources enumerated in the certificate by using its private key to
generate a digital signature (that can be verified using the public
key from the certificate).
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
It is assumed that the reader is familiar with the terms and concepts
described in "Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile" [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>], and "X.509
Extensions for IP Addresses and AS Identifiers" [<a href="./rfc3779" title=""X.509 Extensions for IP Addresses and AS Identifiers"">RFC3779</a>].
In addition, the following terms are used in this document:
Repository Object (or Object):
This refers to a terminal object in a repository publication
point. A terminal object is conventionally implemented as a file
in a publicly accessible directory, where the file is not a
directory itself, although another form of object that has an
analogous public appearance to a file is encompassed by this term.
<span class="grey">Huston, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6481">RFC 6481</a> ResCert Repository Structure February 2012</span>
Repository Publication Point:
This refers to a collection of Repository Objects that are
published at a common publication point. This is conventionally
implemented as a directory in a publicly accessible filesystem
that is identified by a URI [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>], although another form of
local storage that has an analogous public appearance to a simple
directory of files is also encompassed by this term.
Repository Instance:
This refers to a collection of one or more Repository Publication
Points that share a common publication instance. This
conventionally is implemented as a collection of filesystem
directories that share a common URI prefix, where each directory
is also identifiable by its own unique URI.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. RPKI Repository Publication Point Content and Structure</span>
The RPKI does not require that a single repository instance contain
all published RPKI objects. Instead, the RPKI repository system is
comprised of multiple repository instances. Each individual
repository instance is composed of one or more repository publication
points. Each repository publication point is used by one or more
entities referenced in RPKI certificates, as defined in the
certificate's Subject Information Access (SIA) extension.
This section describes the collection of objects (RPKI certificates,
CRLs, manifests, and signed objects) held in repository publication
points.
For every Certification Authority (CA) certificate in the RPKI, there
is a corresponding repository publication point that is the
authoritative publication point for all current certificates and CRLs
issued by this CA. The certificate's SIA extension contains a URI
[<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>] that references this repository publication point and
identifies the repository access mechanisms. Additionally, a
certificate's Authority Information Access (AIA) extension contains a
URI that references the authoritative location for the CA certificate
under which the given certificate was issued.
For example, if the subject of certificate A has issued certificates
B and C, then the AIA extensions of certificates B and C both point
to the publication point for the certificate A object, and the SIA
extension of certificate A points to a repository publication point
(directory) containing certificates B and C (see Figure 1).
<span class="grey">Huston, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6481">RFC 6481</a> ResCert Repository Structure February 2012</span>
+--------+
+--------->| Cert A |<----+
| | AIA | |
| +--------- SIA | |
| | +--------+ |
| | |
| | +-------------------|------------------+
| | | | |
| +->| +--------+ | +--------+ |
| | | Cert B | | | Cert C | |
| | | CRLDP-------+ | | CRLDP-----+ |
+----------- AIA | | +----- AIA | | |
| | SIA------+ | | SIA------------+
| +--------+ | | +--------+ | | |
| | V V | |
| | +-----------------+ | |
| | | CRL issued by A | | |
| A's Repository| +-----------------+ | |
| Directory | | |
+---------------|----------------------+ |
| |
+----------------+ | +----------------+ |
| B's Repository |<-------+ | C's Repository |<--+
| Directory | | Directory |
+----------------+ +----------------+
Figure 1. Use of AIA and SIA Extensions in the RPKI
In Figure 1, certificates B and C are issued by CA A. Therefore, the
AIA extensions of certificates B and C point to (certificate) A, and
the SIA extension of certificate A points to the repository
publication point of CA A's subordinate products, which includes
certificates B and C, as well as the CRL issued by A. The CRL
Distribution Points (CRLDP) extension in certificates B and C both
point to the CRL issued by A.
In this distributed repository structure, an instance of a CA's
repository publication point contains all published certificates
issued by that CA, and the CRL issued by that CA. This repository
also contains all published digitally signed objects that are
verified by an end-entity (EE) certificate issued by this CA.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Manifests</span>
Every repository publication point MUST contain a manifest [<a href="./rfc6486" title=""Manifests for the Resource Public Key Infrastructure (RPKI)"">RFC6486</a>].
The manifest contains a list of the names of all objects, as well as
the hash value of each object's contents that are currently published
by a CA or an EE.
<span class="grey">Huston, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6481">RFC 6481</a> ResCert Repository Structure February 2012</span>
An authority MAY perform a number of object operations on a
publication repository within the scope of a repository change before
issuing a single manifest that covers all the operations within the
scope of this change. Repository operators SHOULD implement some
form of directory management regime function on the repository to
ensure that RPs who are performing retrieval operations on the
repository are not exposed to intermediate states during changes to
the repository and the associated manifest. (It is noted that if no
such access regime is in place, then RPs MAY be exposed to
intermediate repository states where the manifest and the repository
contents may not be precisely aligned. Specific cases and actions in
such a situation of misalignment of the manifest and the repository
contents are considered in [<a href="./rfc6486" title=""Manifests for the Resource Public Key Infrastructure (RPKI)"">RFC6486</a>].)
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. CA Repository Publication Points</span>
A CA certificate has two accessMethod elements specified in its SIA
field. The id-ad-caRepository accessMethod element has an associated
accessLocation element that points to the repository publication
point of the certificates issued by this CA, as specified in
[<a href="./rfc6487" title=""A Profile for X.509 PKIX Resource Certificates"">RFC6487</a>]. The id-ad-rpkiManifest accessMethod element has an
associated accessLocation element that points to the manifest object,
as an object URI (as distinct to a directory URI), that is associated
with this CA.
A CA's publication repository contains the current (non-expired and
non-revoked) certificates issued by this CA, the most recent CRL
issued by this CA, the current manifest, and all other current signed
objects that can be verified using an EE certificate [<a href="./rfc6487" title=""A Profile for X.509 PKIX Resource Certificates"">RFC6487</a>] issued
by this CA.
The CA's manifest contains the names of this collection of objects,
together with the hash value of each object's contents, with the
single exception of the manifest itself.
The RPKI design requires that a CA be uniquely associated with a
single key pair. Thus, the administrative entity that is a CA
performs key rollover by generating a new CA certificate with a new
subject name, as well as a new key pair [<a href="./rfc6489" title=""Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)"">RFC6489</a>]. (The reason for
the new subject name is that in the context of the RPKI, the subject
names in all certificates issued by a CA are intended to be unique,
and because the RPKI key rollover procedure creates a new instance of
a CA with the new key, the name constraint implies the need for a new
subject name for the CA with the new key.) In such cases, the entity
SHOULD continue to use the same repository publication point for both
CA instances during the key rollover, ensuring that the value of the
AIA extension in indirect subordinate objects that refer to the
certificates issued by this CA remain valid across the key rollover,
<span class="grey">Huston, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6481">RFC 6481</a> ResCert Repository Structure February 2012</span>
and that the reissuance of subordinate certificates in a key rollover
is limited to the collection of immediate subordinate products of
this CA [<a href="./rfc6489" title=""Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)"">RFC6489</a>]. In such cases, the repository publication point
will contain the CRL, manifest and subordinate certificates of both
CA instances. (It is feasible for the entity to use distinct
repository publication points for the old and new CA keys, but, in
such a case, very careful coordination would be required with
subordinate CAs and EEs to ensure that the AIA pointers in the
indirect subordinate levels of the RPKI hierarchy are correctly
aligned to the subordinate products of the new CA.)
The following paragraphs provide guidelines for naming objects in a
CA's repository publication point:
CRL:
When a CA issues a new CRL, it replaces the previous CRL (issued
under the same CA key pair) in the repository publication point.
CAs MUST NOT continue to publish previous CRLs in the repository
publication point. Thus, it MUST replace (overwrite) previous
CRLs signed by the same CA (instance). A non-normative guideline
for naming such objects is that the file name chosen for the CRL
in the repository be a value derived from the public key of the
CA. One such method of generating a CRL publication name is
described in <a href="./rfc4387#section-2.1">Section 2.1 of [RFC4387]</a>; convert the 160-bit hash of
a CA's public key value into a 27-character string using a
modified form of Base64 encoding, with an additional modification
as proposed in <a href="#section-5">Section 5</a>, table 2, of [<a href="./rfc4648" title=""The Base16, Base32, and Base64 Data Encodings"">RFC4648</a>]. The filename
extension of ".crl" MUST be used to denote the file as a CRL.
Each ".crl" file contains exactly one CRL encoded in DER format.
Manifest:
When a new instance of a manifest is published, it MUST replace
the previous manifest to avoid confusion. CAs MUST NOT continue
to publish previous CA manifests in the repository publication
point. A non-normative guideline for naming such objects is that
the filename chosen for the manifest in the publication repository
be a value derived from the public key part of the entity's key
pair, using the algorithm described for CRLs above for generation
of filenames. The filename extension of ".mft" MUST be used to
denote the object as a manifest.
Certificates:
Within the RPKI framework, it is possible that a CA MAY issue a
series of certificates to the same subject name, the same subject
public key, and the same resource collection. However, a relying
party requires access only to the most recently published
certificate in such a series. Thus, such a series of certificates
SHOULD share the same filename. This ensures that each successive
<span class="grey">Huston, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6481">RFC 6481</a> ResCert Repository Structure February 2012</span>
issued certificate in such a series effectively overwrites the
previous instance of the certificate. It is feasible to use
different filenames, but this imposes a burden on the validating
user. A non-normative guideline for naming such objects is for
the CA to adopt a (local) policy requiring a subject to use a
unique key pair for each unique instance of a certificate series
issued to the same subject, thereby allowing the CA to use a file
name generation scheme based on the subject's public key, e.g.,
using the algorithm described above for CRLs above. Published
certificates MUST use a filename extension of ".cer" to denote the
object as a certificate. Each ".cer" file contains exactly one
certificate encoded in DER format.
Signed Objects:
RPKI signed objects [<a href="./rfc6488" title=""Signed Object Template for the Resource Public Key Infrastructure (RPKI)"">RFC6488</a>] are published in the repository
publication point referenced by the SIA of the CA certificate that
issued the EE certificate used to validate the digital signature
of the signed object (and are directly referenced by the SIA of
that EE certificate). A general non-normative guideline for
naming such RPKI signed objects is for the filename of such
objects to be derived from the associated EE certificate's public
key, applying the algorithm described above. Published RPKI
signed objects MUST NOT use the filename extensions ".crl",
".mft", or ".cer".
One form of signed object defined at the time of publication of
this document is a Route Origination Authorization (ROA)
[<a href="./rfc6482" title=""A Profile for Route Origin Authorizations (ROAs)"">RFC6482</a>]. Published ROAs MUST use a filename extension of ".roa"
to denote the object as a ROA.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Resource Certificate Publication Repository Considerations</span>
Each issuer MAY publish its issued certificates and CRL in any
repository. However, there are a number of considerations that guide
the choice of a suitable repository publication structure:
* The publication repository SHOULD be hosted on a highly
available service and high-capacity publication platform.
* The publication repository MUST be available using rsync
[<a href="./rfc5781" title=""The rsync URI Scheme"">RFC5781</a>] [<a href="#ref-RSYNC">RSYNC</a>]. Support of additional retrieval mechanisms
is the choice of the repository operator. The supported
retrieval mechanisms MUST be consistent with the accessMethod
element value(s) specified in the SIA of the associated CA or
EE certificate.
<span class="grey">Huston, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6481">RFC 6481</a> ResCert Repository Structure February 2012</span>
* Each CA repository publication point SHOULD contain the
products of this CA, including those objects that can be
verified by EE certificates that have been issued by this CA.
The signed products of related CA's that are operated by the
same entity MAY share this CA repository publication point.
Aside from subdirectories, any other objects SHOULD NOT be
placed in a repository publication point.
Any such subdirectory SHOULD be the repository publication
point of a CA or EE certificate that is contained in the CA
directory. These considerations also apply recursively to
subdirectories of these directories. Detection of content that
is not a CA product has the potential to cause confusion to
RPs, and in such a case RPs should exercise caution not to
invalidate the valid CA products found at the CA's repository
publication point.
* Signed objects are published in the location indicated by the
SIA field of the EE certificate used to verify the signature of
each object. Signed objects are published in the repository
publication point of the CA certificate that issued the EE
certificate. The SIA extension of the EE certificate
references this object rather than the repository publication
directory [<a href="./rfc6487" title=""A Profile for X.509 PKIX Resource Certificates"">RFC6487</a>].
* <a href="#section-2.1">Section 2.1</a> states that repository operators SHOULD implement
some form of directory management regime function on the
repository to ensure that RPs who are performing retrieval
operations on the repository are not exposed to intermediate
states during changes to the repository and the associated
manifest. Notwithstanding the following commentary, RPs SHOULD
NOT assume that a consistent repository and manifest state are
assured, and they SHOULD organize their retrieval operations
accordingly (see <a href="#section-5">Section 5</a>).
The manner in which a repository operator can implement a
directory update regime that mitigates the risk of the manifest
and directory contents being inconsistent, to some extent, is
dependent on the operational characteristics of the filesystem
that hosts the repository, so the following comments are non-
normative in terms of any implicit guidelines for repository
operators.
A commonly used technique to avoid exposure to inconsistent
retrieval states during updates to a large directory is to
batch a set of changes to be made, create a working copy of the
directory's contents, and then perform the batch of changes to
the local copy of the directory. On completion, rename the
<span class="grey">Huston, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6481">RFC 6481</a> ResCert Repository Structure February 2012</span>
filesystem symbolic link of the repository directory name to
point to this working copy of the directory. The old
repository directory contents can be purged at a slightly later
time. However, it is noted that the outcomes of this technique
in terms of ensuring the integrity of client synchronization
functions performed over the directory depend on the
interaction between the supported access mechanisms and the
local filesystem behavior. It is probable that this technique
will not remove all possibilities for RPs to see inconsistent
states between the manifest and the repository. Because a
repository has the potential to be in an partially updated
state, it cannot be guaranteed to be internally self consistent
all the time.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Certificate Reissuance and Repositories</span>
If a CA certificate is reissued, e.g., due to changes in the set of
resources contained in the number resource extensions, it should not
be necessary to reissue all certificates issued under it. Because
these certificates contain AIA extensions that point to the
publication point for the CA certificate, a CA SHOULD use a name for
its repository publication point that persists across certificate
reissuance events. That is, reissued CA certificates SHOULD use the
same repository publication point as previously issued CA
certificates having the same subject and subject public key, such
that certificate reissuance SHOULD intentionally overwrite the
previously issued certificate within the repository publication
point.
It is noted in <a href="#section-2.2">Section 2.2</a> that when a CA performs a key rollover,
the entity SHOULD use a name for its repository publication point
that persists across key rollover. In such cases, the repository
publication point will contain the CRLs and manifests of both CA
instances as a transient state in the key rollover procedure. The
RPKI key rollover procedure [<a href="./rfc6489" title=""Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)"">RFC6489</a>] requires that the subordinate
products of the old CA be overwritten in the common repository
publication point by subordinate products issued by the new CA.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Synchronizing Repositories with a Local Cache</span>
It is possible to perform the validation-related task of certificate
path construction using the retrieval of individual certificates, and
certificate revocation lists using online retrieval of individual
certificates, sets of candidate certificates and certificate
revocation lists based on the AIA, SIA, and CRLDP certificate fields.
This is NOT recommended in circumstances where speed and efficiency
are relevant considerations.
<span class="grey">Huston, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6481">RFC 6481</a> ResCert Repository Structure February 2012</span>
To enable efficient validation of RPKI certificates, CRLs, and signed
objects, it is recommended that each relying party maintain a local
repository containing a synchronized copy of all valid certificates,
current certificate revocation lists, and all related signed objects.
The general approach to repository synchronization is one of a "top-
down" walk of the distributed repository structure. This commences
with the collection of locally selected trust anchor material
corresponding to the local choice of Trust Anchors, which can be used
to load the initial set of self-signed resource certificate(s) that
form the "seed" of this process [<a href="./rfc6490" title=""Resource Public Key Infrastructure (RPKI) Trust Anchor Locator"">RFC6490</a>]. The process then
populates the local repository cache with all valid certificates that
have been issued by these issuers. This procedure can be recursively
applied to each of these subordinate certificates. Such a repository
traversal process SHOULD support a locally configured maximal chain
length from the initial trust anchors. If this is not done, then
there might be a SIA pointer loop, or other degenerate forms of the
logical RPKI hierarchy, that would cause an RP to malfunction when
performing a repository synchronization operation with the RP's local
RPKI cache.
RPs SHOULD ensure that this local synchronization uses the retrieved
manifests [<a href="./rfc6486" title=""Manifests for the Resource Public Key Infrastructure (RPKI)"">RFC6486</a>] to ensure that they are synchronizing against a
current, consistent state of each repository publication point. It
is noted in <a href="#section-3">Section 3</a> that when the repository publication point
contents are updated, a repository operator cannot assure RPs that
the manifest contents and the repository contents will be precisely
aligned at all times. RPs SHOULD use a retrieval algorithm that
takes this potential for transient inconsistency into account. For
the RP to mitigate this situation, possible algorithms include
performing the synchronization across the repository twice in
succession, or performing a manifest retrieval both before and after
the synchronization of the directory contents, and repeating the
synchronization function if the second copy of the manifest differs
from the first.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
Repositories are not assumed to be integrity-protected databases, and
repository retrieval operations might be vulnerable to various forms
of "man-in-the-middle" attacks. Corruption of retrieved objects is
detectable by a relying party through the validation of the signature
associated with each retrieved object. Replacement of newer
instances of an object with an older instance of the same object is
detectable through the use of manifests. Insertion of revoked,
deleted certificates is detected through the retrieval and processing
<span class="grey">Huston, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6481">RFC 6481</a> ResCert Repository Structure February 2012</span>
of CRLs at scheduled intervals. However, even the use of manifests
and CRLs will not allow a relying party to detect all forms of
substitution attacks based on older (but not expired) valid objects.
Confidentiality is not provided by the repository or by the signed
objects published in the repository. Data that is subject to
controlled access should not be included in signed objects in the
repository unless there is some specified mechanism used to ensure
the confidentiality of the data contained in the signed object.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Media Types</span>
IANA has registered the following two media types:
application/rpki-manifest
application/rpki-roa
This document also uses the .cer and .crl file extensions from the
application/pkix-cert and application/pkix-crl media registries
defined in [<a href="./rfc2585" title=""Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP"">RFC2585</a>].
<span class="h4"><a class="selflink" id="section-7.1.1" href="#section-7.1.1">7.1.1</a>. application/rpki-manifest</span>
MIME media type name: application
MIME subtype name: rpki-manifest
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries an RPKI Manifest [<a href="./rfc6486" title=""Manifests for the Resource Public Key Infrastructure (RPKI)"">RFC6486</a>]
Interoperability considerations: None
Published specification: This document
Applications that use this media type: Any MIME-complaint transport
Additional information:
Magic number(s): None
File extension(s): .mft
Macintosh File Type Code(s):
Person & email address to contact for further information:
Geoff Huston <gih@apnic.net>
Intended usage: COMMON
Author/Change controller: Geoff Huston <gih@apnic.net>
<span class="grey">Huston, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6481">RFC 6481</a> ResCert Repository Structure February 2012</span>
<span class="h4"><a class="selflink" id="section-7.1.2" href="#section-7.1.2">7.1.2</a>. application/rpki-roa</span>
MIME media type name: application
MIME subtype name: rpki-roa
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries an RPKI ROA [<a href="./rfc6482" title=""A Profile for Route Origin Authorizations (ROAs)"">RFC6482</a>]
Interoperability considerations: None
Published specification: This document
Applications that use this media type: Any MIME-complaint transport
Additional information:
Magic number(s): None
File extension(s): .roa
Macintosh File Type Code(s):
Person & email address to contact for further information:
Geoff Huston <gih@apnic.net>
Intended usage: COMMON
Author/Change controller: Geoff Huston <gih@apnic.net>
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. RPKI Repository Name Scheme Registry</span>
IANA has created the "RPKI Repository Name Scheme" registry. The
registry contains three-letter filename extensions for RPKI
repository objects. The registry's contents are managed by IETF
Review [<a href="./rfc5226" title="">RFC5226</a>]. The initial contents of this registry are the
following:
Filename extension RPKI Object Reference
.cer Certificate [<a href="./rfc6481">RFC6481</a>]
.crl Certificate Revocation List [<a href="./rfc6481">RFC6481</a>]
.mft Manifest [<a href="./rfc6481">RFC6481</a>]
.roa Route Origination Authorization [<a href="./rfc6481">RFC6481</a>]
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgements</span>
This document has benefitted from helpful review comments and input
from Stephen Kent, Matt Lepenski, Michael Elkins, Russ Housley, and
Sean Turner.
<span class="grey">Huston, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6481">RFC 6481</a> ResCert Repository Structure February 2012</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC6482">RFC6482</a>] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", <a href="./rfc6482">RFC 6482</a>, February 2012.
[<a id="ref-RFC6486">RFC6486</a>] Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure
(RPKI)", <a href="./rfc6486">RFC 6486</a>, February 2012.
[<a id="ref-RFC6487">RFC6487</a>] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", <a href="./rfc6487">RFC 6487</a>, February 2012.
[<a id="ref-RFC6488">RFC6488</a>] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template
for the Resource Public Key Infrastructure (RPKI)", <a href="./rfc6488">RFC</a>
<a href="./rfc6488">6488</a>, February 2012.
[<a id="ref-RSYNC">RSYNC</a>] rsync web pages, <<a href="http://rsync.samba.org/">http://rsync.samba.org/</a>>.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-RFC2585">RFC2585</a>] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", <a href="./rfc2585">RFC</a>
<a href="./rfc2585">2585</a>, May 1999.
[<a id="ref-RFC3779">RFC3779</a>] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", <a href="./rfc3779">RFC 3779</a>, June 2004.
[<a id="ref-RFC3986">RFC3986</a>] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, <a href="./rfc3986">RFC</a>
<a href="./rfc3986">3986</a>, January 2005.
[<a id="ref-RFC4387">RFC4387</a>] Gutmann, P., Ed., "Internet X.509 Public Key Infrastructure
Operational Protocols: Certificate Store Access via HTTP",
<a href="./rfc4387">RFC 4387</a>, February 2006.
[<a id="ref-RFC4648">RFC4648</a>] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", <a href="./rfc4648">RFC 4648</a>, October 2006.
[<a id="ref-RFC5226">RFC5226</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>, May
2008.
<span class="grey">Huston, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6481">RFC 6481</a> ResCert Repository Structure February 2012</span>
[<a id="ref-RFC5280">RFC5280</a>] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", <a href="./rfc5280">RFC 5280</a>, May 2008.
[<a id="ref-RFC5781">RFC5781</a>] Weiler, S., Ward, D., and R. Housley, "The rsync URI
Scheme", <a href="./rfc5781">RFC 5781</a>, February 2010.
[<a id="ref-RFC6480">RFC6480</a>] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", <a href="./rfc6480">RFC 6480</a>, February 2012.
[<a id="ref-RFC6489">RFC6489</a>] Huston, G., Michaelson, G., and S. Kent, "Certification
Authority (CA) Key Rollover in the Resource Public Key
Infrastructure (RPKI)", <a href="https://www.rfc-editor.org/bcp/bcp174">BCP 174</a>, <a href="./rfc6489">RFC 6489</a>, February 2012.
[<a id="ref-RFC6490">RFC6490</a>] Huston, G., Weiler, S., Michaelson, G., and S. Kent,
"Resource Public Key Infrastructure (RPKI) Trust Anchor
Locator", <a href="./rfc6490">RFC 6490</a>, February 2012.
Authors' Addresses
Geoff Huston
APNIC
EMail: gih@apnic.net
URI: <a href="http://www.apnic.net">http://www.apnic.net</a>
Robert Loomans
APNIC
EMail: robertl@apnic.net
URI: <a href="http://www.apnic.net">http://www.apnic.net</a>
George Michaelson
APNIC
EMail: ggm@apnic.net
URI: <a href="http://www.apnic.net">http://www.apnic.net</a>
Huston, et al. Standards Track [Page 15]
</pre>
|
