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
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
|
<pre>Internet Engineering Task Force (IETF) R. Austein
Request for Comments: 6486 ISC
Category: Standards Track G. Huston
ISSN: 2070-1721 APNIC
S. Kent
M. Lepinski
BBN
February 2012
<span class="h1">Manifests for the Resource Public Key Infrastructure (RPKI)</span>
Abstract
This document defines a "manifest" for use in the Resource Public Key
Infrastructure (RPKI). A manifest is a signed object (file) that
contains a listing of all the signed objects (files) in the
repository publication point (directory) associated with an authority
responsible for publishing in the repository. For each certificate,
Certificate Revocation List (CRL), or other type of signed objects
issued by the authority that are published at this repository
publication point, the manifest contains both the name of the file
containing the object and a hash of the file content. Manifests are
intended to enable a relying party (RP) to detect certain forms of
attacks against a repository. Specifically, if an RP checks a
manifest's contents against the signed objects retrieved from a
repository publication point, then the RP can detect "stale" (valid)
data and deletion of signed objects.
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/rfc6486">http://www.rfc-editor.org/info/rfc6486</a>.
<span class="grey">Austein, 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="./rfc6486">RFC 6486</a> RPKI Manifests 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>. Manifest Scope ..................................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Manifest Signing ................................................<a href="#page-4">4</a>
<a href="#section-4">4</a>. Manifest Definition .............................................<a href="#page-5">5</a>
<a href="#section-4.1">4.1</a>. eContentType ...............................................<a href="#page-5">5</a>
<a href="#section-4.2">4.2</a>. eContent ...................................................<a href="#page-5">5</a>
<a href="#section-4.2.1">4.2.1</a>. Manifest ............................................<a href="#page-5">5</a>
<a href="#section-4.3">4.3</a>. Content-Type Attribute .....................................<a href="#page-7">7</a>
<a href="#section-4.4">4.4</a>. Manifest Validation ........................................<a href="#page-7">7</a>
<a href="#section-5">5</a>. Manifest Generation .............................................<a href="#page-7">7</a>
<a href="#section-5.1">5.1</a>. Manifest Generation Procedure ..............................<a href="#page-7">7</a>
<a href="#section-5.2">5.2</a>. Considerations for Manifest Generation .....................<a href="#page-9">9</a>
<a href="#section-6">6</a>. Relying Party Use of Manifests ..................................<a href="#page-9">9</a>
<a href="#section-6.1">6.1</a>. Tests for Determining Manifest State ......................<a href="#page-10">10</a>
<a href="#section-6.2">6.2</a>. Missing Manifests .........................................<a href="#page-11">11</a>
<a href="#section-6.3">6.3</a>. Invalid Manifests .........................................<a href="#page-12">12</a>
<a href="#section-6.4">6.4</a>. Stale Manifests ...........................................<a href="#page-12">12</a>
<a href="#section-6.5">6.5</a>. Mismatch between Manifest and Publication Point ...........<a href="#page-13">13</a>
<a href="#section-6.6">6.6</a>. Hash Values Not Matching Manifests ........................<a href="#page-14">14</a>
<a href="#section-7">7</a>. Publication Repositories .......................................<a href="#page-15">15</a>
<a href="#section-8">8</a>. Security Considerations ........................................<a href="#page-15">15</a>
<a href="#section-9">9</a>. IANA Considerations ............................................<a href="#page-16">16</a>
<a href="#section-10">10</a>. Acknowledgements ..............................................<a href="#page-16">16</a>
<a href="#section-11">11</a>. References ....................................................<a href="#page-16">16</a>
<a href="#section-11.1">11.1</a>. Normative References .....................................<a href="#page-16">16</a>
<a href="#section-11.2">11.2</a>. Informative References ...................................<a href="#page-17">17</a>
<a href="#appendix-A">Appendix A</a>. ASN.1 Module ..........................................<a href="#page-18">18</a>
<span class="grey">Austein, 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="./rfc6486">RFC 6486</a> RPKI Manifests February 2012</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Resource Public Key Infrastructure (RPKI) [<a href="./rfc6480" title=""An Infrastructure to Support Secure Internet Routing"">RFC6480</a>] makes use of
a distributed repository system [<a href="./rfc6481" title=""A Profile for Resource Certificate Repository Structure"">RFC6481</a>] to make available a variety
of objects needed by relying parties (RPs). Because all of the
objects stored in the repository system are digitally signed by the
entities that created them, attacks that modify these published
objects are detectable by RPs. However, digital signatures provide
no protection against attacks that substitute "stale" versions of
signed objects (i.e., objects that were valid and have not expired,
but have since been superseded) or attacks that remove an object that
should be present in the repository. To assist in the detection of
such attacks, the RPKI repository system can make use of a signed
object called a "manifest".
A manifest is a signed object that enumerates all the signed objects
(files) in the repository publication point (directory) that are
associated with an authority responsible for publishing at that
publication point. Each manifest contains both the name of the file
containing the object and a hash of the file content, for every
signed object issued by an authority that is published at the
authority's repository publication point. A manifest is intended to
allow an RP to detect unauthorized object removal or the substitution
of stale versions of objects at a publication point. A manifest also
is intended to allow an RP to detect similar outcomes that may result
from a man-in-the-middle attack on the retrieval of objects from the
repository. Manifests are intended to be used in Certification
Authority (CA) publication points in repositories (directories
containing files that are subordinate certificates and Certificate
Revocation Lists (CRLs) issued by this CA and other signed objects
that are verified by end-entity (EE) certificates issued by this CA).
Manifests are modeled on CRLs, as the issues involved in detecting
stale manifests and potential attacks using manifest replays, etc.,
are similar to those for CRLs. The syntax of the manifest payload
differs from CRLs, since RPKI repositories contain objects not
covered by CRLs, e.g., digitally signed objects, such as Route
Origination Authorizations (ROAs).
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
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="grey">Austein, 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="./rfc6486">RFC 6486</a> RPKI Manifests February 2012</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Manifest Scope</span>
A manifest associated with a CA's repository publication point
contains a list of:
* the set of (non-expired, non-revoked) certificates issued and
published by this CA,
* the most recent CRL issued by this CA, and
* all published signed objects that are verifiable using EE
certificates [<a href="./rfc6487" title=""A Profile for X.509 PKIX Resource Certificates"">RFC6487</a>] issued by this CA.
Every RPKI signed object includes, in the Cryptographic Message
Syntax (CMS) [<a href="./rfc3370" title=""Cryptographic Message Syntax (CMS) Algorithms"">RFC3370</a>] wrapper of the object, the EE certificate used
to verify it [<a href="./rfc6488" title=""Signed Object Template for the Resource Public Key Infrastructure (RPKI)"">RFC6488</a>]. Thus, there is no requirement to separately
publish that EE certificate at the CA's repository publication point.
Where multiple CA instances share a common publication point, as can
occur when an entity performs a key-rollover operation [<a href="./rfc6489" title=""Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)"">RFC6489</a>], the
repository publication point will contain multiple manifests. In
this case, each manifest describes only the collection of published
products of its associated CA instance.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Manifest Signing</span>
A CA's manifest is verified using an EE certificate. The
SubjectInfoAccess (SIA) field of this EE certificate contains the
access method OID of id-ad-signedObject.
The CA MAY choose to sign only one manifest with each generated
private key, and generate a new key pair for each new version of the
manifest. This form of use of the associated EE certificate is
termed a "one-time-use" EE certificate.
Alternatively, the CA MAY elect to use the same private key to sign a
sequence of manifests. Because only a single manifest (issued under
a single CA instance) is current at any point in time, the associated
EE certificate is used to verify only a single object at a time. As
long as the sequence of objects verified by this EE certificate are
published using the same file name, then this sequential, multiple
use of the EE certificate is also valid. This form of use of an EE
certificate is termed a "sequential-use" EE certificate.
<span class="grey">Austein, 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="./rfc6486">RFC 6486</a> RPKI Manifests February 2012</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Manifest Definition</span>
A manifest is an RPKI signed object, as specified in [<a href="./rfc6488" title=""Signed Object Template for the Resource Public Key Infrastructure (RPKI)"">RFC6488</a>]. The
RPKI signed object template requires specification of the following
data elements in the context of the manifest structure.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. eContentType</span>
The eContentType for a manifest is defined as id-ct-rpkiManifest and
has the numerical value of 1.2.840.113549.1.9.16.1.26.
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. eContent</span>
The content of a manifest is ASN.1 encoded using the Distinguished
Encoding Rules (DER) [<a href="#ref-X.690" title=" Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER)">X.690</a>]. The content of a manifest is defined
as follows:
Manifest ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
manifestNumber INTEGER (0..MAX),
thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime,
fileHashAlg OBJECT IDENTIFIER,
fileList SEQUENCE SIZE (0..MAX) OF FileAndHash
}
FileAndHash ::= SEQUENCE {
file IA5String,
hash BIT STRING
}
<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>. Manifest</span>
The manifestNumber, thisUpdate, and nextUpdate fields are modeled
after the corresponding fields in X.509 CRLs (see [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>]).
Analogous to CRLs, a manifest is nominally current until the time
specified in nextUpdate or until a manifest is issued with a greater
manifest number, whichever comes first.
If a "one-time-use" EE certificate is employed to verify a manifest,
the EE certificate MUST have a validity period that coincides with
<span class="grey">Austein, 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="./rfc6486">RFC 6486</a> RPKI Manifests February 2012</span>
the interval from thisUpdate to nextUpdate, to prevent needless
growth of the CA's CRL.
If a "sequential-use" EE certificate is employed to verify a
manifest, the EE certificate's validity period needs to be no shorter
than the nextUpdate time of the current manifest. The extended
validity time raises the possibility of a substitution attack using a
stale manifest, as described in <a href="#section-6.4">Section 6.4</a>.
The data elements of the manifest structure are defined as follows:
version:
The version number of this version of the manifest specification
MUST be 0.
manifestNumber:
This field is an integer that is incremented each time a new
manifest is issued for a given publication point. This field
allows an RP to detect gaps in a sequence of published manifests.
As the manifest is modeled on the CRL specification, the
ManifestNumber is analogous to the CRLNumber, and the guidance in
[<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>] for CRLNumber values is appropriate as to the range of
number values that can be used for the manifestNumber. Manifest
numbers can be expected to contain long integers. Manifest
verifiers MUST be able to handle number values up to 20 octets.
Conforming manifest issuers MUST NOT use number values longer than
20 octets.
thisUpdate:
This field contains the time when the manifest was created. This
field has the same format constraints as specified in [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>]
for the CRL field of the same name.
nextUpdate:
This field contains the time at which the next scheduled manifest
will be issued. The value of nextUpdate MUST be later than the
value of thisUpdate. The specification of the GeneralizedTime
value is the same as required for the thisUpdate field.
If the authority alters any of the items that it has published in
the repository publication point, then the authority MUST issue a
new manifest before the nextUpdate time. If a manifest
encompasses a CRL, the nextUpdate field of the manifest MUST match
that of the CRL's nextUpdate field, as the manifest will be
re-issued when a new CRL is published. If a "one-time-use" EE
certificate is used to verify the manifest, then when a new
manifest is issued before the time specified in nextUpdate of the
<span class="grey">Austein, 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="./rfc6486">RFC 6486</a> RPKI Manifests February 2012</span>
current manifest, the CA MUST also issue a new CRL that includes
the EE certificate corresponding to the old manifest.
fileHashAlg:
This field contains the OID of the hash algorithm used to hash the
files that the authority has placed into the repository. The hash
algorithm used MUST conform to the RPKI Algorithms and Key Size
Profile specification [<a href="./rfc6485" title=""A Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)"">RFC6485</a>].
fileList:
This field is a sequence of FileAndHash objects. There is one
FileAndHash entry for each currently valid signed object that has
been published by the authority (at this publication point). Each
FileAndHash is an ordered pair consisting of the name of the file
in the repository publication point (directory) that contains the
object in question and a hash of the file's contents.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Content-Type Attribute</span>
The mandatory content-type attribute MUST have its attrValues field
set to the same OID as eContentType. This OID is id-ct-rpkiManifest
and has the numerical value of 1.2.840.113549.1.9.16.1.26.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Manifest Validation</span>
To determine whether a manifest is valid, the RP MUST perform the
following checks in addition to those specified in [<a href="./rfc6488" title=""Signed Object Template for the Resource Public Key Infrastructure (RPKI)"">RFC6488</a>]:
1. The eContentType in the EncapsulatedContentInfo is
id-ad-rpkiManifest (OID 1.2.840.113549.1.9.16.1.26).
2. The version of the rpkiManifest is 0.
3. In the rpkiManifest, thisUpdate precedes nextUpdate.
If the above procedure indicates that the manifest is invalid, then
the manifest MUST be discarded and treated as though no manifest were
present.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Manifest Generation</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Manifest Generation Procedure</span>
For a CA publication point in the RPKI repository system, a CA MUST
perform the following steps to generate a manifest:
1. If no key pair exists, or if using a "one-time-use" EE certificate
with a new key pair, generate a key pair.
<span class="grey">Austein, 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="./rfc6486">RFC 6486</a> RPKI Manifests February 2012</span>
2. If using a "one-time-use" EE certificate, or if a key pair was
generated in step 1, or if using a "sequential-use" EE certificate
that will expire before the intended nextUpdate time of this
manifest, issue an EE certificate for this key pair.
This EE certificate MUST have an SIA extension access
description field with an accessMethod OID value of
id-ad-signedobject, where the associated accessLocation
references the publication point of the manifest as an object
URL.
This EE certificate MUST describe its Internet Number Resources
(INRs) using the "inherit" attribute, rather than explicit
description of a resource set (see [<a href="./rfc3779" title=""X.509 Extensions for IP Addresses and AS Identifiers"">RFC3779</a>]).
In the case of a "one-time-use" EE certificate, the validity
times of the EE certificate MUST exactly match the thisUpdate
and nextUpdate times of the manifest.
In the case of a "sequential-use" EE certificate, the validity
times of the EE certificate MUST encompass the time interval
from thisUpdate to nextUpdate.
3. The EE certificate MUST NOT be published in the authority's
repository publication point.
4. Construct the manifest content.
The manifest content is described in <a href="#section-4.2.1">Section 4.2.1</a>. The
manifest's fileList includes the file name and hash pair for each
object issued by this CA that has been published at this
repository publication point (directory). The collection of
objects to be included in the manifest includes all certificates
issued by this CA that are published at the CA's repository
publication point, the most recent CRL issued by the CA, and all
objects verified by EE certificates that were issued by this CA
that are published at this repository publication point.
Note that the manifest does not include a self reference (i.e.,
its own file name and hash), since it would be impossible to
compute the hash of the manifest itself prior to it being signed.
5. Encapsulate the manifest content using the CMS SignedData content
type (as specified <a href="#section-4">Section 4</a>), sign the manifest using the private
key corresponding to the subject key contained in the EE
certificate, and publish the manifest in the repository system
publication point that is described by the manifest.
<span class="grey">Austein, 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="./rfc6486">RFC 6486</a> RPKI Manifests February 2012</span>
6. In the case of a key pair that is to be used only once, in
conjunction with a "one-time-use" EE certificate, the private key
associated with this key pair MUST now be destroyed.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Considerations for Manifest Generation</span>
A new manifest MUST be issued and published on or before the
nextUpdate time.
An authority MUST issue a new manifest in conjunction with the
finalization of changes made to objects in the publication point. 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
repository update procedure that mitigates, to the extent possible,
the risk that RPs that are performing retrieval operations on the
repository are exposed to inconsistent, transient, intermediate
states during updates to the repository publication point (directory)
and the associated manifest.
Since the manifest object URL is included in the SIA of issued
certificates, a new manifest MUST NOT invalidate the manifest object
URL of previously issued certificates. This implies that the
manifest's publication name in the repository, in the form of an
object URL, is unchanged across manifest generation cycles.
When a CA entity is performing a key rollover, the entity MAY choose
to have two CA instances simultaneously publishing into the same
repository publication point. In this case, there will be one
manifest associated with each active CA instance that is publishing
into the common repository publication point (directory).
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Relying Party Use of Manifests</span>
The goal of an RP is to determine which signed objects to use for
validating assertions about INRs and their use (e.g., which ROAs to
use in the construction of route filters). Ultimately, this
selection is a matter of local policy. However, in the following
sections, we describe a sequence of tests that the RP SHOULD perform
to determine the manifest state of the given publication point. We
then discuss the risks associated with using signed objects in the
publication point, given the manifest state; we also provide suitable
warning text that SHOULD be placed in a user-accessible log file. It
is the responsibility of the RP to weigh these risks against the risk
of routing failure that could occur if valid data is rejected, and to
implement a suitable local policy. Note that if a certificate is
deemed unfit for use due to local policy, then any signed object that
<span class="grey">Austein, 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="./rfc6486">RFC 6486</a> RPKI Manifests February 2012</span>
is validated using this certificate also SHOULD be deemed unfit for
use (regardless of the status of the manifest at its own publication
point).
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Tests for Determining Manifest State</span>
For a given publication point, the RP SHOULD perform the following
tests to determine the manifest state of the publication point:
1. For each CA using this publication point, select the CA's current
manifest (the "current" manifest is the manifest issued by this CA
having the highest manifestNumber among all valid manifests, and
where manifest validity is defined in <a href="#section-4.4">Section 4.4</a>).
If the publication point does not contain a valid manifest, see
<a href="#section-6.2">Section 6.2</a>. Lacking a valid manifest, the following tests cannot
be performed.
2. To verify completeness, an RP MAY check that every file at each
publication point appears in one and only one current manifest,
and that every file listed in a current manifest is published at
the same publication point as the manifest.
If there exist files at the publication point that do not appear
on any manifest, or files listed in a manifest that do not appear
at the publication point, then see <a href="#section-6.5">Section 6.5</a>, but still continue
with the following test.
3. Check that the current time (translated to UTC) is between
thisUpdate and nextUpdate.
If the current time does not lie within this interval, then see
<a href="#section-6.4">Section 6.4</a>, but still continue with the following tests.
4. Verify that the listed hash value of every file listed in each
manifest matches the value obtained by hashing the file at the
publication point.
If the computed hash value of a file listed on the manifest does
not match the hash value contained in the manifest, then see
<a href="#section-6.6">Section 6.6</a>.
5. An RP MAY check that the contents of each current manifest
conforms to the manifest's scope constraints, as specified in
<a href="#section-2">Section 2</a>.
6. If a current manifest contains entries for objects that are not
within the scope of the manifest, then the out-of-scope entries
<span class="grey">Austein, 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="./rfc6486">RFC 6486</a> RPKI Manifests February 2012</span>
SHOULD be disregarded in the context of this manifest. If there
is no other current manifest that describes these objects within
that other manifest's scope, then see <a href="#section-6.2">Section 6.2</a>.
For each signed object, if all of the following conditions hold:
* the manifest for its publication and the associated publication
point pass all of the above checks;
* the signed object is valid; and
* the manifests for every certificate on the certification path
used to validate the signed object and the associated
publication points pass all of the above checks;
then the RP can conclude that no attack against the repository system
has compromised the given signed object, and the signed object MUST
be treated as valid (relative to manifest checking).
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Missing Manifests</span>
The absence of a current manifest at a publication point could occur
due to an error by the publisher or due to (malicious or accidental)
deletion or corruption of all valid manifests.
When no valid manifest is available, there is no protection against
attacks that delete signed objects or replay old versions of signed
objects. All signed objects at the publication point, and all
descendant objects that are validated using a certificate at this
publication point, SHOULD be viewed as suspect, but MAY be used by
the RP, as per local policy.
The primary risk in using signed objects at this publication point is
that a superseded (but not stale) CRL would cause an RP to improperly
accept a revoked certificate as valid (and thus rely upon signed
objects that are validated using that certificate). This risk is
somewhat mitigated if the CRL for this publication point has a short
time between thisUpdate and nextUpdate (and the current time is
within this interval). The risk in discarding signed objects at this
publication point is that an RP may incorrectly discard a large
number of valid objects. This gives significant power to an
adversary that is able to delete a manifest at the publication point.
Regardless of whether signed objects from this publication are deemed
fit for use by an RP, this situation SHOULD result in a warning to
the effect that: "No manifest is available for <pub point name>, and
thus there may have been undetected deletions or replay substitutions
from the publication point."
<span class="grey">Austein, 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="./rfc6486">RFC 6486</a> RPKI Manifests February 2012</span>
In the case where an RP has access to a local cache of previously
issued manifests that are valid, the RP MAY use the most recently
previously issued valid manifests for this RPKI repository
publication collection for each entity that publishes at this
publication point.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Invalid Manifests</span>
The presence of an invalid manifest at a publication point could
occur due to an error by the publisher or due to (malicious or
accidental) corruption of a valid manifest. An invalid manifest MUST
never be used, even if the manifestNumber of the invalid manifest is
greater than that of other (valid) manifests.
There are no risks associated with using signed objects at a
publication point containing an invalid manifest, provided that valid
manifests that collectively cover all the signed objects are also
present.
If an invalid manifest is present at a publication point that also
contains one or more valid manifests, this situation SHOULD result in
a warning to the effect that: "An invalid manifest was found at <pub
point name>, this indicates an attack against the publication point
or an error by the publisher. Processing for this publication point
will continue using the most recent valid manifest(s)."
In the case where the RP has access to a local cache of previously
issued (valid) manifests, an RP MAY make use of that locally cached
data. Specifically, the RP MAY use the locally cached, most recent,
previously issued, valid manifest issued by the entity that (appears
to have) issued the invalid manifest.
<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. Stale Manifests</span>
A manifest is considered stale if the current time is after the
nextUpdate time for the manifest. This could be due to publisher
failure to promptly publish a new manifest, or due to (malicious or
accidental) corruption or suppression of a more recent manifest.
All signed objects at the publication point issued by the entity that
has published the stale manifest, and all descendant signed objects
that are validated using a certificate issued by the entity that has
published the stale manifest at this publication point, SHOULD be
viewed as somewhat suspect, but MAY be used by the RP as per local
policy.
The primary risk in using such signed objects is that a newer
manifest exists that, if present, would indicate that certain objects
<span class="grey">Austein, 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="./rfc6486">RFC 6486</a> RPKI Manifests February 2012</span>
have been removed or replaced. (For example, the new manifest might
show the existence of a newer CRL and the removal of one or more
revoked certificates). Thus, the use of objects from a stale
manifest may cause an RP to incorrectly treat invalid objects as
valid. The risk is that the CRL covered by the stale manifest has
been superseded, and thus an RP will improperly treat a revoked
certificate as valid. This risk is somewhat mitigated if the time
between the nextUpdate field of the manifest and the current time is
short. The risk in discarding signed objects at this publication
point is that the RP may incorrectly discard a large number of valid
objects. This gives significant power to an adversary that is able
to prevent the publication of a new manifest at a given publication
point.
Regardless of whether signed objects from this publication are deemed
fit for use by an RP, this situation SHOULD result in a warning to
the effect that: "A manifest found at <pub point name> is no longer
current. It is possible that undetected deletions have occurred at
this publication point."
Note that there is also the potential for the current time to be
before the thisUpdate time for the manifest. This case could be due
to publisher error or a local clock error; in such a case, this
situation SHOULD result in a warning to the effect that: "A manifest
found at <pub point name> has an incorrect thisUpdate field. This
could be due to publisher error, or a local clock error, and
processing for this publication point will continue using this
otherwise valid manifest."
<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>. Mismatch between Manifest and Publication Point</span>
If there exist valid signed objects that do not appear in any
manifest, then, provided the manifest is not stale (see <a href="#section-6.4">Section 6.4</a>),
it is likely that their omission is an error by the publisher. It is
also possible that this state could be the result of a (malicious or
accidental) replacement of a current manifest with an older, but
still valid, manifest. However, regarding the appropriate
interpretation of such objects, it remains the case that if the
objects were intended to be invalid, then they should have been
revoked using whatever revocation mechanism is appropriate for the
signed object in question. Therefore, there is little risk in using
such signed objects. If the publication point contains a stale
manifest, then there is a greater risk that the objects in question
were revoked, along with a missing Certificate Revocation List (CRL),
the absence of which is undetectable since the manifest is stale. In
any case, the use of signed objects not present on a manifest, or
descendant objects that are validated using such signed objects, is a
matter of local policy.
<span class="grey">Austein, 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="./rfc6486">RFC 6486</a> RPKI Manifests February 2012</span>
Regardless of whether objects not appearing on a manifest are deemed
fit for use by the RP, this situation SHOULD result in a warning to
the effect that: "The following files are present in the repository
at <pub point name>, but are not listed on any manifest <file list>
for <pub point name>."
If there exists files listed on the manifest that do not appear in
the repository, then these objects are likely to have been improperly
(via malice or accident) deleted from the repository. A primary
purpose of manifests is to detect such deletions. Therefore, in such
a case, this situation SHOULD result in a warning to the effect that:
"The following files that should have been present in the repository
at <pub point name> are missing <file list>. This indicates an
attack against this publication point, or the repository, or an error
by the publisher."
<span class="h3"><a class="selflink" id="section-6.6" href="#section-6.6">6.6</a>. Hash Values Not Matching Manifests</span>
A file appearing on a manifest with an incorrect hash value could
occur because of publisher error, but it also may indicate that an
attack has occurred.
If an object appeared on a previous valid manifest with a correct
hash value, and it now appears with an invalid hash value, then it is
likely that the object has been superseded by a new (unavailable)
version of the object. If the object is used, there is a risk that
the RP will be treating a stale object as valid. This risk is more
significant if the object in question is a CRL. If the object can be
validated using the RPKI, the use of these objects is a matter of
local policy.
If an object appears on a manifest with an invalid hash and has never
previously appeared on a manifest, then it is unclear whether the
available version of the object is more or less recent than the
version indicated by the manifest. If the manifest is stale (see
<a href="#section-6.4">Section 6.4</a>), then it becomes more likely that the available version
is more recent than the version indicated on the manifest, but this
is never certain. Whether to use such objects is a matter of local
policy. However, in general, it is better to use a possibly outdated
version of the object than to discard the object completely.
While it is a matter of local policy, in the case of CRLs, an RP
SHOULD endeavor to use the most recently issued valid CRL, even where
the hash value in the manifest matches an older CRL or does not match
any available CRL for a CA instance. The thisUpdate field of the CRL
can be used to establish the most recent CRL in the case where an RP
has more than one valid CRL for a CA instance.
<span class="grey">Austein, 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="./rfc6486">RFC 6486</a> RPKI Manifests February 2012</span>
Regardless of whether objects with incorrect hashes are deemed fit
for use by the RP, this situation SHOULD result in a warning to the
effect that: "The following files at the repository <pub point name>
appear on a manifest with incorrect hash values <file list>. It is
possible that these objects have been superseded by a more recent
version. It is very likely that this problem is due to an attack on
the publication point, although it also could be due to a publisher
error."
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Publication Repositories</span>
The RPKI publication system model requires that every publication
point be associated with one or more CAs, and be non-empty. Upon
creation of the publication point associated with a CA, the CA MUST
create and publish a manifest as well as a CRL. A CA's manifest will
always contain at least one entry, namely, the CRL issued by the CA
upon repository creation [<a href="./rfc6481" title=""A Profile for Resource Certificate Repository Structure"">RFC6481</a>].
Every published signed object in the RPKI [<a href="./rfc6488" title=""Signed Object Template for the Resource Public Key Infrastructure (RPKI)"">RFC6488</a>] is published in
the repository publication point of the CA that issued the EE
certificate, and is listed in the manifest associated with that CA
certificate.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
Manifests provide an additional level of protection for RPKI RPs.
Manifests can assist an RP to determine if a repository object has
been deleted, occluded, or otherwise removed from view, or if a
publication of a newer version of an object has been suppressed (and
an older version of the object has been substituted).
Manifests cannot repair the effects of such forms of corruption of
repository retrieval operations. However, a manifest enables an RP
to determine if a locally maintained copy of a repository is a
complete and up-to-date copy, even when the repository retrieval
operation is conducted over an insecure channel. In cases where the
manifest and the retrieved repository contents differ, the manifest
can assist in determining which repository objects form the
difference set in terms of missing, extraneous, or superseded
objects.
The signing structure of a manifest and the use of the nextUpdate
value allows an RP to determine if the manifest itself is the subject
of attempted alteration. The requirement for every repository
publication point to contain at least one manifest allows an RP to
determine if the manifest itself has been occluded from view. Such
attacks against the manifest are detectable within the time frame of
the regular schedule of manifest updates. Forms of replay attack
<span class="grey">Austein, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6486">RFC 6486</a> RPKI Manifests February 2012</span>
within finer-grained time frames are not necessarily detectable by
the manifest structure.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. IANA Considerations</span>
This document registers the following in the "RPKI Signed Object"
registry created by [<a href="./rfc6488" title=""Signed Object Template for the Resource Public Key Infrastructure (RPKI)"">RFC6488</a>]:
Name: Manifest
OID: 1.2.840.113549.1.9.16.1.26
Reference: [<a href="./rfc6486">RFC6486</a>] (this document)
This document registers the following three-letter filename extension
for "RPKI Repository Name Schemes" registry created by [<a href="./rfc6481" title=""A Profile for Resource Certificate Repository Structure"">RFC6481</a>]:
Filename extension: mft
RPKI Object: Manifest
Reference: [<a href="./rfc6481" title=""A Profile for Resource Certificate Repository Structure"">RFC6481</a>]
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgements</span>
The authors would like to acknowledge the contributions from George
Michelson and Randy Bush in the preparation of the manifest
specification. Additionally, the authors would like to thank Mark
Reynolds and Christopher Small for assistance in clarifying manifest
validation and RP behavior. The authors also wish to thank Sean
Turner for his helpful review of this document.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.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-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-RFC6481">RFC6481</a>] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", <a href="./rfc6481">RFC 6481</a>,
February 2012.
[<a id="ref-RFC6485">RFC6485</a>] Huston, G., "A Profile for Algorithms and Key Sizes for Use
in the Resource Public Key Infrastructure (RPKI)", <a href="./rfc6485">RFC</a>
<a href="./rfc6485">6485</a>, February 2012.
<span class="grey">Austein, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6486">RFC 6486</a> RPKI Manifests February 2012</span>
[<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-X.690">X.690</a>] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER).
<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Informative References</span>
[<a id="ref-RFC3370">RFC3370</a>] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", <a href="./rfc3370">RFC 3370</a>, August 2002.
[<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-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.
<span class="grey">Austein, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6486">RFC 6486</a> RPKI Manifests February 2012</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. ASN.1 Module</span>
RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) mod(0) 60 }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
-- IMPORTS NOTHING --
-- Manifest Content Type: OID
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }
-- Manifest Content Type: eContent
Manifest ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
manifestNumber INTEGER (0..MAX),
thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime,
fileHashAlg OBJECT IDENTIFIER,
fileList SEQUENCE SIZE (0..MAX) OF FileAndHash
}
FileAndHash ::= SEQUENCE {
file IA5String,
hash BIT STRING
}
END
<span class="grey">Austein, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6486">RFC 6486</a> RPKI Manifests February 2012</span>
Authors' Addresses
Rob Austein
Internet Systems Consortium
EMail: sra@hactrn.net
Geoff Huston
APNIC
6 Cordelia St
South Brisbane, QLD 4101
Australia
EMail: gih@apnic.net
URI: <a href="http://www.apnic.net">http://www.apnic.net</a>
Stephen Kent
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
USA
EMail: kent@bbn.com
Matt Lepinski
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
USA
EMail: mlepinski@bbn.com
Austein, et al. Standards Track [Page 19]
</pre>
|
