idnits 2.17.1 draft-ietf-sidr-rpki-manifests-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 794. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 805. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 812. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 818. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2, 2008) is 5956 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 174 == Unused Reference: 'RFC3280' is defined on line 729, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-02 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'ID.SIDR-ARCH') == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-09 -- No information found for draft-ietf-sidr-repository - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ID.SIDR-REPOSITORY' ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission R. Austein 3 Internet-Draft ISC 4 Intended status: Standards Track G. Huston 5 Expires: July 5, 2008 APNIC 6 S. Kent 7 M. Lepinski 8 BBN 9 January 2, 2008 11 Manifests for the Resource Public Key Infrastructure 12 draft-ietf-sidr-rpki-manifests-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on July 5, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document defines a "manifest" for use in the Resource Public Key 46 Infrastructure. A "manifest" is a signed object that contains a 47 listing of all the signed objects in the repository publication point 48 associated with an authority responsible for publishing in the 49 repository. For each certificate, or other forms of signed objects 50 issued by the authority that are published at this repository 51 publication point, the manifest contains both the name of the file 52 containing the object, and a hash of the file content. Manifests are 53 intended to expose potential threats to relying parties of the 54 results of a man-in-the middle withholding attack on repository 55 retrieval operations. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Manifests . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Manifest Syntax . . . . . . . . . . . . . . . . . . . . . 4 63 3. Manifest Signing and Verification . . . . . . . . . . . . . . 6 64 4. Using CMS SignedData to protect a Manifest . . . . . . . . . . 7 65 5. Manifest Generation . . . . . . . . . . . . . . . . . . . . . 7 66 6. Certificate Requests . . . . . . . . . . . . . . . . . . . . . 10 67 7. Publication Repositories . . . . . . . . . . . . . . . . . . . 11 68 8. Relying Parties . . . . . . . . . . . . . . . . . . . . . . . 11 69 8.1. Manifest Processing . . . . . . . . . . . . . . . . . . . 13 70 8.1.1. Warning List . . . . . . . . . . . . . . . . . . . . . 15 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 74 12. Normative References . . . . . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 76 Intellectual Property and Copyright Statements . . . . . . . . . . 19 78 1. Introduction 80 The Resource PKI (RPKI) [ID.SIDR-ARCH] makes use of a distributed 81 repository system [ID.SIDR-REPOSITORY] to make available a variety of 82 objects needed by relying parties (RPs) such as Internet service 83 providers (ISPs). Because all of the objects stored in the 84 repository system are digitally signed by the entities that created 85 them, attacks that modify these objects are detectable by RPs. 86 However, attacks that substitute "stale" versions of signed objects 87 (i.e., objects that were valid but have since been superceded) are 88 not automatically detected just by validation of digital signatures. 89 Attacks that remove an object also are not detectable by verification 90 of digital signatures, unless an RP is able to predict that the 91 object should be present. To help address these vulnerabilities, the 92 RPKI repository system will make use of a new data structure call a 93 "manifest." 95 A manifest is a signed object listing of all of the signed objects 96 issued by an authority responsible for a publication point in the 97 repository system. For each certificate, Certificate Revocation List 98 (CRL), or other signed object, such as a Route Origination Authority 99 (ROA), issued by the authority, the manifest contains both the name 100 of the file containing the object, and a hash of the file content. 101 Manifests are intended to allow an RP to obtain sufficient 102 information so as to be able to detect if the retrieval of objects 103 from an RPKI repository has been compromised by unauthorized removal, 104 or by substitution of "stale" versions of objects. Manifests are 105 designed to be used for Certification Authority (CA) publication 106 points in repositories, points that contain subordinate certificates, 107 CRLs and other signed objects, and End Entity (EE) publication points 108 in repositories (that contain signed objects). 110 [Note 1. This text assumes that CRLs are included in manifests. 111 As a signed product of an issuing authority that is published in 112 the authority's publication repository this would be consistent 113 with the definition of manifests in the text. However, if 114 manifests are intended to list all objects in a publication 115 repository that relying parties would otherwise not know to exist, 116 then is not logically necessary to include CRLs in a manifest, as 117 the CRL is already a requrement for CAs to publish. It is an 118 option to strike CRLs from the list of objects to inlude in a 119 manifest. This may reduce to some extent the amount of manifest 120 activity in a repository for an otherse largely static CA. On the 121 other hand listing the CRL in the manifest has some utility in 122 being able to detect some forms of substitution of a "stale" but 123 otherwise valid CRL. A later note highlights a similar issue over 124 inclusion of the manifest-signing EE certificate in the manifest. 126 It is suggested that the text be left as is and that CRLs be 127 included in manifests.] 129 [Note 2. This draft assumes that it is possible for an EE to sign 130 and publish multiple objects and, accordingly, a manifest for the 131 signed object publication repository is necessary. Accordingly, 132 the document implicitly refers to both CA and EE manifests. An 133 alternate option is to apply a restriction in the RPKI that an EE 134 can sign a single object, in which case the signed object can be 135 referenced directly in the SIA of the AA and no manifest of EE- 136 signed objects is necessary. It is suggested that the text be 137 left as is, leaving the option for CA and EE manifests to be 138 permitted within this specification.] 140 1.1. Terminology 142 It is assumed that the reader is familiar with the terms and concepts 143 described in "Internet X.509 Public Key Infrastructure Certificate 144 and Certificate Revocation List (CRL) Profile" [RFC3280]and "X.509 145 Extensions for IP Addresses and AS Identifiers" [RFC3779]. 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119. 151 2. Manifests 153 Manifests are modeled on CRLs, as the issues involved in detecting 154 stale manifests, and detection of potential attacks using manifest 155 replays, etc are similar to those for CRLs. The syntax of the 156 manifest payload differs from CRLs, since RPKI repositories can 157 contain objects not covered by CRLs, e.g. digitally signed objects, 158 such as ROAs. The Cryptographic Message Syntax (CMS) [RFC3852] 159 signature format is employed to encapsulate the manifest payload. It 160 also provides a vehicle to carry the EE certificate needed to verify 161 a manifest. 163 The scope of a manifest is the entire collection objects in a 164 publication point in a repository, where each object has been signed 165 by the same CA or EE that is the authority for this repository 166 publication point. 168 2.1. Manifest Syntax 170 A manifest is a CMS signed-data object whose content is defined as 171 follows: 173 Manifest ::= SEQUENCE { 174 version [0] INTEGER DEFAULT 0, 175 manifestNumber INTEGER, 176 thisUpdate GeneralizedTime, 177 nextUpdate GeneralizedTime, 178 fileHashAlg OBJECT IDENTIFIER, 179 fileList SEQUENCE OF (SIZE 0..MAX) FileAndHash 180 } 182 FileAndHash ::= SEQUENCE { 183 file IA5String 184 hash BIT STRING 185 } 187 The version of this Manifest format is 1, and the value of this field 188 is therefore 0. 190 The manifestNumber field is a sequence number that is incremented 191 each time a new manifest is issued for the repository. This field is 192 used to allow a RP to detect gaps in a sequence of published 193 manifest. 195 The thisUpdate field contains the time when the manifest was created 196 and the nextUpdate field contains the time at which the next 197 scheduled manifest will be issued. The value of nextUpdate MUST be 198 later than the value of thisUpdate. If the authority alters any of 199 the items in the repository publication point, then the authority 200 MUST issue a new manifest before nextUpdate. In such a case, when 201 the authority issues the new manifest, it MUST also issue a new CRL 202 that includes the EE certificate corresponding to the old manifest. 203 A manifest is nominally valid until the time specified in nextUpdate 204 or until a manifest is issued with a greater manifest number, 205 whichever comes first. The revoked EE certificate for the previous 206 manifest's signature will be removed from the CRL when it expires. 208 The fileHashAlg field contains the OID of the hash algorithm used to 209 hash the files that the authority has placed into the repository. 210 The mandatory to implement hash algorithm is SHA-256 and its OID is 211 2.16.840.1.101.3.4.2.1. [RFC4055]. 213 The fileList field contains a sequence of FileAndHash pairs, one for 214 each currently valid signed object that has been issued by the 215 authority. Each FileAndHash pair contains the name of the file in 216 the repository that contains the object in question, and a hash of 217 the file's contents. 219 3. Manifest Signing and Verification 221 A manifest for a CA's repository publication point is signed by a 222 private key, for which the corresponding public key appears in an EE 223 certificate signed by the CA in question. 225 A manifest for a EE's repository publication point is signed by a 226 private key, for which the corresponding public key appears in an EE 227 certificate signed by the same CA that signed the public key of the 228 publishing EE. This, for an EE-managed publication point, exactly 229 one level of indirection is allowed in validation of the manifest 230 certificate. 232 Validation of a manifest's CMS digital signature is performed in the 233 context of the RPKI, and is validated using the algorithm described 234 in [ID.SIDR-CERTPROFILE]. 236 [Note 3. This draft assumes that each EE uses a unique repository 237 publication point. This is not an explicit constraint of the 238 Resource PKI. For the sake of the efficiency of the relying 239 parties' repository synchronization operations it is possible that 240 a CA may choose to place all signed objects that are verified 241 using EE certificates that are subordinates to this CA in a common 242 single repository publication point. In this case the above 243 manifest signature description still holds, namely that the 244 manifest of this common repository publication point is a single 245 manifest that is signed by a private key, for which the 246 corresponding public key appears in an EE certificate signed by 247 this CA. It is suggested that the text note that this validation 248 method allows both the model that each EE uses a dedicated 249 repository publication point, or that all subordinate EEs of a 250 single CA share a common repository publication point, and note 251 that it CAs may elect to use a dedicated per-EE repository, or a 252 single shared EE repository.] 254 [Note 4. In the (possibly degenerate) case of a multi-signed 255 object it would appear that the simplest case is to apply a 256 restriction that the EE certificates used in this context be one- 257 off use EE certificates and each EE certificate reference the 258 common multi-signed object's repository publication point. The 259 collection of CAs that generated EE certificates to sign this 260 object would also need to agree on a common repository publication 261 point in this case. As the issue of a multi-signed object is 262 still unresolved for this RPKI no resolution is suggested here 263 (see draft-ietf-smime-multisig-03.txt for a multi-signing 264 approach).] 266 Two models for managing the EE certificates used to verify manifests 267 are permitted. A publication point authority may create an EE 268 certificate for manifest verification and use the corresponding 269 private key to sign a series of manifests over tiome. Alternatively, 270 an EE certificate may be used to verify a single instance of a 271 manifest and the private key corresponding to the certificate may be 272 deleted after it is used to sign that manifest instance. To avoid 273 needless CRL growth, the EE certificate used to validate a manifest 274 in this second case SHOULD expire at the same time that the manifest 275 expires, i.e., the notAfter value in the EE certificate should be the 276 same as the nextUpdate value in the manifest. In contrast, when an 277 EE certificate is used to verify a series of manifests, the validity 278 of that certificate has to encompass the validity intervals for all 279 corresponding manifests. 281 4. Using CMS SignedData to protect a Manifest 283 It is intended that the manifest will be processed by an RP in the 284 context of assembling a local copy of the entire RPKI repository. 285 Thus, the certificates and CRLs required to validate the certificate 286 path for the EE certificate used to varify the manifest's signature 287 will be at hand for the RP. AS a result, this specification 288 recommends that only the EE certificate needed to verify the 289 signature on the manifest be included in the CMS DignedData. CA 290 certificates and CRLs SHOULD NOT be included in the CMS SignedData. 291 The CMS timestamp field SHOULD NOT be included in the CMS Signed 292 Data. 294 [Note 5. This section needs to be expanded to precisely specify 295 which optional CMS fields MUST be present, which ones MUST be 296 omitted and which (if any) MAY be present at the discretion of 297 themanifest signed. It is also suggested that the default 298 algorithms to be used also be specified here.] 300 5. Manifest Generation 302 Each CA in the RPKI publishes the certificates and CRLs it issues at 303 a publication point in the RPKI repository system. To create a 304 manifest, each CA MUST: 306 1. Generate a key pair. 308 2. Issue an EE certificate for this key pair to enable relying 309 parties to verify the signature on the manifest. 311 * This EE certificate has an SIA extension access description 312 field with an accessMethod OID value of id-ad-signedobject 313 where the associated accessLocation references the publication 314 point of the manifest as an object URL. 316 * This EE certificate SHOULD describe its IP number resources 317 using the "inherit" attribute rather than explicit description 318 of a resource set. 320 * The validity times of the EE certificate MUST either exactly 321 match the thisUpdate and nextUpdate times of the manifest, or 322 encompass the validity intervals for the series of manifests 323 that are expected to be verified using the EE certificate. 325 3. Publish this certificate in the authority's repository 326 publication point. 328 [Note 6. This assumes that the EE certificate used to sign 329 manifests is published in the CA's repository publication 330 point in the same manner as all other subordinate certificates 331 issued by this CA. It is potentially an option to omit the 332 publication step on the basis that the EE certificate is also 333 contained in the CMS SignedData field of the manifest. It is 334 suggested that these EE certificates by treated in the same 335 manner as all other certificates in the RPKI and be published 336 in the appropriate repository as well as being reproduced in 337 the CMS SignedData section of the manifest, leaving the above 338 text as is.] 340 4. The manifest is then constructed. Note that the manifest does 341 not include a self reference (i.e., its own file name and hash), 342 since it would be impossible to compute the hash of the manifest 343 itself prior to it being signed. 345 5. The manifest is encapsulated using the CMS SignedData content 346 type and published in the publication point in the repository 347 system that is described by the manifest. 349 6. If a single use EE certificate is associated with a single use 350 key pair the private key may now be destroyed. 352 An authority MUST issue a new manifest on or before the nextUpdate 353 time. 355 An authority MUST issue a new manifest in conjunction with the 356 finalization of changes made to objects in the publication point. An 357 authority MAY perform a number of object operations on a publication 358 repository within the scope of a repository change before issuing a 359 single manifest that covers all the operations within the scope of 360 this change. Repository operators SHOULD implement some form of 361 synchronization function on the repository to ensure that replying 362 parties who are performing retrieval operations on the repository are 363 not exposed to intermediate states during changes to the repository 364 and the associated manifest. 366 Since the manifest object URL is included in the SIA of issued 367 certificates then a new manifest MUST NOT invalidate the manifest 368 object URL of previously issued certificates. This implies that the 369 manifest's publication name in the repository, in the form of an 370 object URL, is one that is unchanged across manifest generation 371 cycles. 373 As the manifest scope is all signed objects associated with an 374 authority responsible for a pubnlication point, the manifest must 375 persist across key rollover events. This implies that this 376 persistent repository publication name cannot be derived from the 377 authority's current public key value in any way. 379 In the case of a CA publication point manifest, when the CA is 380 performing a key rollover, the CA will use its new private key to 381 sign an EE certificate for a new manifest. It will sign the manifest 382 and publish it at the point in the key rollover sequence following 383 the publication of the new CA certificate by the superior CA (i.e. 384 the point at which objects signed with the new key may be validated 385 by relying parties). The previous EE certificate used to sign 386 manifests will be revoked by the CRL that is associated with the 387 retiring private key (as the scope of CRLs in the RPKI is that of CA 388 plus private key value). The new instance of the manifest, and 389 successive manifests, will describe all the files in the CA 390 publication point that were signed with both the retiring key and the 391 new key. The manifest number will continue to be incremented and 392 MUST NOT be reset. 394 In the case of a EE publication point manifest, when the EE 395 certificate is rekeyed, a new publication point is established. A 396 new EE certificate for manifest validation will be generated by the 397 CA that issues the new EE certificate assocaited with the new 398 publication point. In this case there is no manifest overlap, as the 399 new repository publication point will have a distinct manifest. 401 In the case of a common publication point for all subordinate EE 402 authorities of a CA the same still holds, and each batched update 403 operation on the shared repository would entail a new generation of 404 the manifest being produced. 406 6. Certificate Requests 408 A request for a CA certificate MUST include in the SIA of the request 409 an accessMethod OID of id-ad-rpkiManifest, where the associated 410 accessLocation refers to the subject's published manifest object as 411 an object URL. 413 When an EE certificate is intended for use in verifying multiple 414 objects, the certificate request for the EE certificate MUST include 415 in the SIA of the request an access method OID of id-ad-rpkiManifest, 416 where the associated access location refers to the publication point 417 of the objects that are verified using this EE certificate. 419 [Note 7. This draft assumes that it is possible for an EE to sign 420 and publish multiple objects as noted earlier. The above 421 constraint me be removed if this is not the case. It is suggested 422 that the multiple object provision be left in the text.] 424 When an EE certificate is used to sign a single object, the 425 certificate request for the EE certificate MUST include in the SIA of 426 the request an access method OID of id-ad-signedObject, where the 427 associated access location refers to the publication point of the 428 single object that is verified using this EE certificate. 430 In accordance with the provisions of [ID.SIDR-CERTPROFILE], all 431 certificate issuance requests for a CA certificate SHOULD include the 432 id-ad-caRepository access method, and also the id-ad-rpkiManifest 433 access method that references the intended publication point of the 434 manifest in the associated access location in the request. The 435 issuer SHOULD honor these values in the issued certificate or MUST 436 reject the Certificate Request. 438 Similarly, a request for an EE certificate SHOULD include either the 439 id-ad-signedObjectRepository and the id-ad-rpkiManifest access 440 method, or, in the case of single-use EE certificates, include the 441 id-ad-signedObject access method and omit the id-ad-rpkiManifest 442 access method. 444 7. Publication Repositories 446 The RPKI publication system model requires that every publication 447 point be associated with a CA or an EE, and be non-empty. Upon 448 creation of the publication point associated with a CA, the CA MUST 449 create and publish a manifest as well as a CRL. The manifest will 450 contain at least two entries, the CRL issued by the CA upon 451 repository creation and the EE certificate used to sign the manifest. 452 Upon the creation of the publication point associated with an AA, the 453 EE MUST create and puiblish a manifest. The manifest in an otherwise 454 empty repository publication point associated with an EE will contain 455 no entries in the manifest's fileList sequence (i.e. a sequence of 0 456 length). 458 [Note 8. This description of the initial state of a CA's 459 repository publication point assumes that the EE certificate used 460 to sign manifests is published in the CA's repository publication 461 point in the same manner as all other subordinate certificates 462 issued by this CA, as noted in a previous comment. It is 463 suggested that this remain the case and that this text be 464 retained.] 466 For signed objects EE certificate used in the verification of such 467 objects is either a single-use certificate, used to verify a single 468 signed object, or a multiple-use certificate. In the case of a 469 single-use EE certificate, the id-ad-signedObject SIA access method 470 is to refer to the signed object itself, and the signed object is not 471 covered by a manifest. In the case where the EE certificate is used 472 to verify multiple objects, the id-ad-signedObjectRepository SIA 473 access method points to the repository publication point where signed 474 objects that are verified using this EE certificate are published and 475 the id-ad-rpkiManifest SIA access methos points to the manifest for 476 this repository publication point. A CA MAY use a common repository 477 publication point for the collection of signed objects that are 478 verified using any of the CA's subordinate EE certificates. 480 8. Relying Parties 482 All RPKI repository publication points SHOULD should contain a valid 483 manifest. 485 A valid manifest is one where: 487 o the manifest conforms to the defined syntax for manifests 489 o the digital signature can be verified by using the public key 490 specified in the attached EE certificate 492 o the current time is no earlier than the thisUpdate time of the 493 manifest and no later than the nextUpdate time of the manifest 495 o the EE certificate conforms to the profile as specified in 496 [ID.SIDR-CERTPROFILE] 498 o the EE certificate has not been revoked 500 o the EE certificate has not expired 502 o the EE certificate can be validated according to the procedure 503 described in section 7 of [ID.SIDR-CERTPROFILE] 505 The absence of a manifest from a RPKI repository publication point 506 may indicate a possible attack on the repository retrieval function, 507 and this situation should generate some form of operational warning. 508 If the relying party has retained one or more previously retrieved 509 manifests then the relying party should use most recent (highest 510 manifestNumber value) verified manifest for the publication point in 511 question. If no prior manifest for this publication point is 512 available, there is no basis for detecting missing files, so the 513 relying party should just process the repository contents in any 514 case. All objects retrieved from a repository whose manifest is in 515 this state are still potentially useable by relying parties, and 516 validated objects should be regarded with the same level of trust 517 that is used for validated objects that have been retrieved from 518 repositories with valid manifests. 520 If the signature on a manifest cannot be verified, or the manifest 521 cannot be parsed according to the manifest syntax specification, it 522 must be disregarded by a relying party. Since this case entailed 523 retrieval of what purports to be a manifest, a warning SHOULD be 524 issued, but the RP should proceed with processing the publication 525 point objects. 527 Where a manifest is present, and the signature can be verified using 528 the attached EE certificate, but the EE certificate itself cannot be 529 validated, then it is possible that the manifest is bogus. In this 530 case the manifest should be disregarded by the RP and a warning 531 SHOULD be issued, but the RP should proceed with processing the 532 publication point objects as if no manifest had been provided. 534 Where a manifest is present, and the signature can be verified using 535 the attached EE certificate, but the EE certificate itself has been 536 revoked, then it is possible that the manifest is a replay. In this 537 case the manifest should be disregarded by the RP and a warning 538 SHOULD be issued, but the RP should proceed with processing the 539 publication point objects as if no manifest had been provided. 541 When processing a valid manifest, if an RP encounters a signed object 542 that is not listed in the manifest, or that has a different hash 543 value from the one specified in the manifest, then the object SHOULD 544 be ignored and a warning SHOULD be issued. The object should not be 545 trusted as it may be part of a replay attack. 547 [Note 9. An alternative approach is that such objects that are 548 not in the manifest or fail to match the hash algorithm but still 549 validate in the RPKI should still be used because they do indeed 550 validate within the scope of the RPKI. The issue here appears to 551 be one of judgment about what form of replay attack is occurring 552 in such a situation, assuming that the authority's manifest 553 generation process was correct and the discrepancy has arisen 554 during the repository synchronization operation. The default 555 approach, or ignoring everything not in the manifest and ignoring 556 everything that fails to match the manifest's hash value assumes 557 that the attack is one of replay of the object. The alternative 558 is that the replay attack is a replay of the manifest, in which 559 case the relying party has been forced to discard valid objects 560 because of the manifest replay. This requires further 561 consideration as to which scenario presents the lesser risk to 562 relying parties. No suggestion is made here, and further advice 563 is sought on this topic.] 565 If a valid manifest lists files that are not visible in the 566 publication point, then the RP should assume that these objects have 567 been deleted, potentially without authorization, and a warning SHOULD 568 be issued. 570 A semi-formal description of the recommended relying party manifest 571 processing algorithm follows. 573 8.1. Manifest Processing 575 The error-free case is: 577 A manifest is present in the repository, is current (i.e., the 578 current time is bounded by the manifest validity interval), and 579 its signature can be verified using a valid certificate 581 [ID.SIDR-CERTPROFILE]. All files found in the publication point 582 are listed in the manifest, all files listed in the manifest are 583 found in the publication point, and the hashes match. 585 The cases that SHOULD generate various manifest validation warnings 586 are: 588 1. No manifest is found in the repository at the publication point. 589 In this case, the relying party cannot use the manifest in 590 question. 592 A. If the relying party has a prior manifest for this 593 publication point, then the relying party should use most 594 recent, verified manifest for the publication point in 595 question and generate warning A. 597 B. If no prior manifest for this publication point is available 598 to the relying party, there is no basis for detecting missing 599 files, so just process certificate, CRL, and other signed 600 object files and generate warning B. 602 2. The signature on manifest fetched from the repository cannot be 603 verified (or the format of the manifest is bad). In this case, 604 the relying party cannot use the manifest in question. 606 A. If the relying party has a prior manifest for this 607 publication point, then the relying party should use most 608 recent, verified manifest for the publication point in 609 question and generate warning A. 611 B. If no prior manifest for this publication point is available 612 to the relying party, there is no basis for detecting missing 613 files, so just process certificate, CRL, and other signed 614 object files and generate warning B. 616 3. The manifest is present and current and its signature can be 617 verified using the CMS enclosed EE certificate. 619 A. If the EE certificate is valid (current and not revoked) and 620 all files in the repository are listed in the manifest, and 621 all files listed in the manifest are found in the repository, 622 and the hashes match, then the relying party should use the 623 manifest, as this is the validated case. 625 B. If the EE certificate is valid and one or more files listed 626 in the manifest have hashes that do not match the files in 627 the repository with the indicates names, then the 628 corresponding files are likely to be old and intended to be 629 replaced, and thus SHOULD NOT be used. The relying party 630 should generate Warning C. 632 C. If the EE certificate is valid and one or more files listed 633 in the manifest are missing, the relying party should 634 Generate Warning D. 636 D. If the EE certificate is expired, an indication that the EE 637 certificate valid times and the manifest times are not 638 aligned, then the relying party should generate warning E, 639 but proceed with processing. 641 E. If the EE certificate is revoked but not expired, then the 642 manifest SHOULD be ignored. The relying party should 643 generate warning F and proceed with processing as if no 644 manifest is available, as the CA has explicitly revoked the 645 certificate for the manifest. 647 4. The manifest is present but expired. If the signature cannot be 648 verified, then treat this in the same manner as case 1 or 2. If 649 the manifest signature can be verified using a matching EE 650 certificate: 652 A. If the EE certificate is valid (current and not revoked), 653 then generate warning A and proceed. 655 B. If the EE certificate is expired, then generate warning G and 656 proceed. 658 C. If EE certificate is revoked but not expired, the manifest 659 SHOULD be ignored. Generate warning F and proceed with 660 processing as if no manifest is available (since the CA 661 explicitly revoked the certificate for the manifest.) 663 8.1.1. Warning List 665 Warning A: A current manifest is not available for . 666 An older manifest for this publication point will be used, but 667 there may be undetected deletions from the publication point. 669 Warning B: No manifest is available for , and thus 670 there may have been undetected deletions from the publication 671 point. 673 Warning C: The following files at appear to be 674 superceded and are NOT being processed. 676 Warning D: The following files that should have been present in the 677 repository at , are missing . This 678 indicates an attack against this publication point, or the 679 repository, or an error by the publisher. 681 Warning E: EE certificate for manifest verification for is expired. This indicates an error by the publisher, but 683 processing for this publication point will proceed using the 684 current manifest. 686 Warning F: The EE certificate for has been revoked. 687 The manifest will be ignored and all files found at this 688 publication point will be processed. 690 Warning G: EE certificate for manifest verification for is expired. This indicates an error by the publisher, but 692 processing for this publication point will proceed using the the 693 most recent (but expired) manifest. 695 9. Security Considerations 697 [To be defined] 699 10. IANA Considerations 701 [Note to IANA, to be removed prior to publication: there are no IANA 702 considerations stated in this version of the document.] 704 11. Acknowledgements 706 The authors would like to acknowledge the contributions from George 707 Michaelson and Randy Bush in the preparation of the manifest 708 specification. 710 12. Normative References 712 [ID.SIDR-ARCH] 713 Lepinski, M., Kent, S., and R. Barnes, "An Infrastructure 714 to Support Secure Internet Routing", Work in progress: 715 Internet Drafts draft-ietf-sidr-arch-02.txt, 716 November 2007. 718 [ID.SIDR-CERTPROFILE] 719 Huston, G., Michaleson, G., and R. Loomans, "A Profile for 720 X.509 PKIX Resource Certificates", Work in progress: 721 Internet Drafts draft-ietf-sidr-res-certs-09.txt, 722 November 2007. 724 [ID.SIDR-REPOSITORY] 725 Huston, G. and G. Michaleson, "A Distributed Repository 726 System for the Resource PKI", Work in progress: Internet 727 Drafts draft-ietf-sidr-repository-00.txt, November 2007. 729 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 730 X.509 Public Key Infrastructure Certificate and 731 Certificate Revocation List (CRL) Profile", RFC 3280, 732 April 2002. 734 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 735 Addresses and AS Identifiers", RFC 3779, June 2004. 737 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 738 RFC 3852, July 2004. 740 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 741 Algorithms and Identifiers for RSA Cryptography for use in 742 the Internet X.509 Public Key Infrastructure Certificate 743 and Certificate Revocation List (CRL) Profile", RFC 4055, 744 June 2005. 746 Authors' Addresses 748 Rob Austein 749 Internet Systems Consortium 750 950 Charter St. 751 Redwood City, CA 94063 752 USA 754 Email: sra@isc.org 755 Geoff Huston 756 Asia Pacific Network Information Centre 757 33 park Rd. 758 Milton, QLD 4064 759 Australia 761 Email: gih@apnic.net 762 URI: http://www.apnic.net 764 Stephen Kent 765 BBN Technologies 766 10 Moulton St. 767 Cambridge, MA 02138 768 USA 770 Email: kent@bbn.com 772 Matt Lepinski 773 BBN Technologies 774 10 Moulton St. 775 Cambridge, MA 02138 776 USA 778 Email: mlepinski@bbn.com 780 Full Copyright Statement 782 Copyright (C) The IETF Trust (2008). 784 This document is subject to the rights, licenses and restrictions 785 contained in BCP 78, and except as set forth therein, the authors 786 retain all their rights. 788 This document and the information contained herein are provided on an 789 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 790 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 791 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 792 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 793 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 794 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 796 Intellectual Property 798 The IETF takes no position regarding the validity or scope of any 799 Intellectual Property Rights or other rights that might be claimed to 800 pertain to the implementation or use of the technology described in 801 this document or the extent to which any license under such rights 802 might or might not be available; nor does it represent that it has 803 made any independent effort to identify any such rights. Information 804 on the procedures with respect to rights in RFC documents can be 805 found in BCP 78 and BCP 79. 807 Copies of IPR disclosures made to the IETF Secretariat and any 808 assurances of licenses to be made available, or the result of an 809 attempt made to obtain a general license or permission for the use of 810 such proprietary rights by implementers or users of this 811 specification can be obtained from the IETF on-line IPR repository at 812 http://www.ietf.org/ipr. 814 The IETF invites any interested party to bring to its attention any 815 copyrights, patents or patent applications, or other proprietary 816 rights that may cover technology that may be required to implement 817 this standard. Please address the information to the IETF at 818 ietf-ipr@ietf.org. 820 Acknowledgment 822 Funding for the RFC Editor function is provided by the IETF 823 Administrative Support Activity (IASA).