idnits 2.17.1 draft-ietf-sidr-repos-struct-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (October 11, 2010) is 4940 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-11 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'I-D.ietf-sidr-arch') == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-18 == Outdated reference: A later version (-08) exists of draft-ietf-sidr-keyroll-02 == Outdated reference: A later version (-07) exists of draft-ietf-sidr-ta-04 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing G. Huston 3 Internet-Draft R. Loomans 4 Intended status: BCP G. Michaelson 5 Expires: April 14, 2011 APNIC 6 October 11, 2010 8 A Profile for Resource Certificate Repository Structure 9 draft-ietf-sidr-repos-struct-05.txt 11 Abstract 13 This document defines a profile for the structure of repository 14 publication points that contain X.509 / PKIX Resource Certificates, 15 Certificate Revocation Lists and signed objects. This profile 16 contains the proposed object naming scheme, the contents of 17 repository publication points, and a suggested internal structure of 18 a local repository cache that is intended to facilitate 19 synchronisation across a distributed collection of repository 20 publication points and facilitate certification path construction. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 14, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. RPKI Repository Publication Point Content and Structure . . . 4 59 2.1. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.2. CA Repository Publication Points . . . . . . . . . . . . . 6 61 2.3. Multi-Use EE Repository Publication Points . . . . . . . . 8 62 3. Resource Certificate Publication Repository Considerations . . 9 63 4. Certificate Reissuance and Repositories . . . . . . . . . . . 11 64 5. Synchronising Repositories with a Local Cache . . . . . . . . 11 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 To validate attestations made in the context of the Resource Public 75 Key Infrastructure (RPKI) [I-D.ietf-sidr-arch], relying parties (RPs) 76 need access to all the X.509 / PKIX Resource Certificates, 77 Certificate Revocation Lists (CRLs), and signed objects that 78 collectively define the RPKI. 80 Each issuer of a certificate, CRL or a signed object makes it 81 available for download to RPs through the publication of the object 82 in an RPKI repository. 84 The repository system is the central clearing-house for all signed 85 objects that MUST be globally accessible to all RPs. When 86 certificates, CRLs and signed objects are created, they are uploaded 87 to a repository publication point, from whence they can be downloaded 88 for use by RPs. 90 This document defines a profile for the structure of RPKI 91 repositories. This profile defines the proposed object naming 92 scheme, the contents of repository publication points and an internal 93 structure of a Repository Cache that is intended to facilitate 94 synchronisation across a distributed collection of repositories, in 95 support of certificate validation path construction. 97 A Resource Certificate attests to a binding of an entity's public key 98 to a set of IP address blocks and AS numbers. The Subject of a 99 Resource Certificate can demonstrate that it is the holder of the 100 resources enumerate in the certificate by using its private key to 101 generate a digital signature (that can be verified using the public 102 key from the certificate). 104 1.1. Terminology 106 It is assumed that the reader is familiar with the terms and concepts 107 described in "Internet X.509 Public Key Infrastructure Certificate 108 and Certificate Revocation List (CRL) Profile" [RFC5280], and "X.509 109 Extensions for IP Addresses and AS Identifiers" [RFC3779]. 111 In addition, the following terms are used in this document: 113 Repository Object (or Object): 114 This refers to a terminal object in a repository publication 115 point. A terminal object is conventionally implemented as a file 116 in a publicly accessible directory, where the file is not a 117 directory itself, although other forms of objects that have an 118 analogous public appearance to a file are encompassed by this 119 term. 121 Repository Publication Point: 122 This refers to a collection of Repository Objects that are 123 published at a common publication point. This is conventionally 124 implemented as a directory in a publicly accessible filesystem 125 that is identified by a URI [RFC3986], although other forms of 126 local storage that have an analogous public appearance to a simple 127 directory of files are also encompassed by this term. 129 Repository Instance: 130 This refers to a collection of one or more Repository Publication 131 Points that share a common publication instance. This 132 conventionally is implemented as a collection of filesystem 133 directories that share a common URI prefix, where each directory 134 is also identifiable by its own unique URI. 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119. 140 2. RPKI Repository Publication Point Content and Structure 142 The RPKI does not require that a single repository instance contain 143 all published RPKI objects. Instead, the RPKI repository system is 144 comprised of multiple repository instances. Each individual 145 repository instance is composed of one or more repository publication 146 points. Each repository publication point is used by one or more 147 entities referenced in RPKI certificates, as defined in the 148 certificate's Subject Information Authority (SIA) extension. 150 This section describes the collection of objects (RPKI certificates, 151 CRLs, manifests and signed objects) held in repository publication 152 points. 154 For every Certification Authority (CA) certificate in the RPKI there 155 is a corresponding repository publication point that is the 156 authoritative publication point for all current certificates and CRLs 157 issued by this CA. For every End-entity (EE) certificate in the RPKI 158 there is a repository publication point that holds all current signed 159 objects that can be verified via this EE certificate. In both cases 160 certificate's SIA extension contains a URI [RFC3986] that references 161 this repository publication point and identifies the repository 162 access mechanisms. Additionally, a certificate's Authority 163 Information Access (AIA) extension contains a URI that references the 164 authoritative location for the Certification Authority (CA) 165 certificate under which the given certificate was issued. 167 For example, if the subject of certificate A has issued certificates 168 B and C, then the AIA extensions of certificates B and C both point 169 to the publication point for the certificate A object, and the SIA 170 extension of certificate A points to a repository publication point 171 (directory) containing certificates B and C (see Figure 1). 173 +--------+ 174 +--------->| Cert A |<----+ 175 | | AIA | | 176 | +--------- SIA | | 177 | | +--------+ | 178 | | | 179 | | +-------------------|------------------+ 180 | | | | | 181 | +->| +--------+ | +--------+ | 182 | | | Cert B | | | Cert C | | 183 | | | CRLDP-------+ | | CRLDP-----+ | 184 +----------- AIA | | +----- AIA | | | 185 | | SIA------+ | | SIA------------+ 186 | +--------+ | | +--------+ | | | 187 | | V V | | 188 | | +-----------------+ | | 189 | | | CRL issued by A | | | 190 | A's Repository| +-----------------+ | | 191 | Directory | | | 192 +---------------|----------------------+ | 193 | | 194 +----------------+ | +----------------+ | 195 | B's Repository |<-------+ | C's Repository |<--+ 196 | Directory | | Directory | 197 +----------------+ +----------------+ 199 Figure 1. Use of AIA and SIA extensions in the RPKI. 201 In Figure 1, certificates B and C are issued by (CA) A. Therefore, 202 the AIA extensions of certificates B and C point to (certificate) A, 203 and the SIA extension of certificate A points to the repository 204 publication point of CA A's subordinate products, which includes 205 certificates B and C, as well as the CRL issued by A. The CRL 206 Distribution Points (CRLDP) extension in certificates B and C both 207 point to the Certificate Revocation List (CRL) issued by A. 209 In this distributed repository structure an instance of a CA's 210 repository publication point contains all published certificates 211 issued by that CA, and the CRL issued by that CA. An End Entity's 212 (EE's) repository publication point contains all the published 213 objects that are verified via the associated EE certificate. 215 2.1. Manifests 217 Every repository publication point MUST contain a manifest 218 [I-D.ietf-sidr-rpki-manifests]. The manifest contains a list of the 219 names of all objects, as well as the hash value of each object's 220 contents, that are currently published by a CA, or by an EE. 222 An authority MAY perform a number of object operations on a 223 publication repository within the scope of a repository change before 224 issuing a single manifest that covers all the operations within the 225 scope of this change. Repository operators SHOULD implement some 226 form of directory management regime function on the repository to 227 ensure that RPs who are performing retrieval operations on the 228 repository are not exposed to intermediate states during changes to 229 the repository and the associated manifest. 231 2.2. CA Repository Publication Points 233 A CA Certificate has two accessMethod elements specified in its SIA 234 field. The id-ad-caRepository accessMethod element has an associated 235 accessLocation element that points to the repository publication 236 point of the certificates issued by this CA, as specified in 237 [I-D.ietf-sidr-res-certs]. The id-ad-rpkiManifest accessMethod 238 element has an associated accessLocation element that points to the 239 manifest object, as an object URI (as distinct to a directory URI), 240 that is associated with this CA. 242 A CA's publication repository contains the current (non-expired and 243 non-revoked) certificates issued by this CA, the most recent CRL 244 issued by this CA, the current manifest, and all other current signed 245 objects that can be verified using a "single-use" EE certificate 246 [I-D.ietf-sidr-res-certs] issued by this CA. 248 The CA's manifest contains the names of this collection of objects, 249 together with the hash value of each object's contents, with the 250 single exception of the manifest itself. 252 The RPKI design requires that a CA be uniquely associated with a 253 single key pair. Thus, the administrative entity that is a CA 254 performs key rollover by generating a new CA certificate with a new 255 Subject name, as well as a new key pair [I-D.ietf-sidr-keyroll]. 256 (The reason for the new Subject name is that in the context of the 257 RPKI the Subject names in all certificates issued by a CA are 258 intended to be unique, and because the RPKI key rollover procedure 259 creates a new instance of a CA with the new key, the name constraint 260 implies the need for a new Subject name for the CA with the new key.) 261 In such cases the entity SHOULD continue to use the same repository 262 publication point for both CA instances during the key rollover, 263 ensuring that the value of the AIA extension in indirect subordinate 264 objects that refer to the certificates issued by this CA remain valid 265 across the key rollover, and that the re-issuance of subordinate 266 certificates in a key rollover is limited to the collection of 267 immediate subordinate products of this CA. In such cases the 268 repository publication point will contain the CRL, manifest and 269 subordinate certificates of both CA instances. 271 The following paragraphs provide guidelines for naming objects in a 272 CA's repository publication point: 274 CRL: 275 When a CA issues a new CRL, it replaces the previous CRL (issued 276 under the same CA key pair) in the repository publication point. 277 CAs MUST NOT continue to publish previous CRLs in the repository 278 publication point. Thus, it SHOULD replace (overwrite) previous 279 CRLs signed by the same CA (instance). A non-normative guideline 280 for naming such objects is that the file name chosen for the CRL 281 in the repository be a value derived from the public key of the CA 282 One such method of generating a CRL publication name is described 283 in section 2.1 of [RFC4387]; convert the 160-bit hash of a CA's 284 public key value into a 27-character string using a modified form 285 of Base64 encoding, with an additional modification as proposed in 286 section 5, table 2, of [RFC4648]. The filename extension of 287 ".crl" MUST be used, to denote the file as a CRL. 289 Manifest: 290 When a new instance of a manifest is published, it SHOULD replace 291 the previous manifest, to avoid confusion. CAs MUST NOT continue 292 to publish previous CA manifests in the repository publication 293 point. A non-normative guideline for naming such objects is that 294 the filename chosen for the manifest in the publication repository 295 be a value derived from the public key part of the entity's key 296 pair, using the algorithm described for CRLs above for generation 297 of filenames. The filename extension of ".mft" MUST be used, to 298 denote the object as a manifest. 300 Certificates: 301 Within the RPKI framework it is possible that a CA MAY issue a 302 series of certificates to the same subject name, the same subject 303 public key, and the same resource collection. However, a relying 304 party requires access only to the most recently published 305 certificate in such a series. Thus, the such a series of 306 certificates SHOULD share the same filename. This ensures that 307 each successive issued certificate in such a series effectively 308 overwrites the previous instance of the certificate. A non- 309 normative guideline for naming such objects is for the CA to adopt 310 a (local) policy requiring a subject to use a unique key pair for 311 each unique instance of a certificate series issued to the same 312 subject, thereby the CA to use a file name generation scheme based 313 on the subject's public key, e.g., using the algorithm described 314 above for CRLs above. Published certificates MUST use a filename 315 extension of ".cer" to denote the object as a certificate. 317 Signed Objects: 318 Within the RPKI framework there are two kinds of EE certificates: 319 "single-use" EE certificates (that are used to verify a single 320 object), and "multi-use" EE certificates (that may be used to 321 verify multiple objects). In the case of "multi-use" EE 322 certificates the repository publication point is described in the 323 following section. In the case of a "single-use" EE certificate, 324 the single signed object is published in the repository 325 publication point referenced by the SIA of the CA certificate that 326 issued the "single-use" EE certificate. A non-normative guideline 327 for naming such objects is for the filename of such objects to be 328 derived from the associated EE certificate's public key, applying 329 the algorithm described above. Published objects MUST NOT use the 330 filename extensions ".crl", ".mft", or ".cer". 332 2.3. Multi-Use EE Repository Publication Points 334 EE repository publication points are used only in conjunction with 335 "multi-use" EE Certificates. In this case the EE Certificate has two 336 accessMethods specified in its SIA field. The id- 337 adsignedObjectRepository accessMethod has an associated 338 accessLocation that points to the repository publication point of the 339 objects verified by this EE certificate, as specified in 340 [I-D.ietf-sidr-res-certs]. The id-ad-rpkiManifest accessMethod has 341 an associated access location that points to the manifest, as an 342 object URI (as distinct from a directory URI), associated with this 343 repository publication point. This manifest describes all the signed 344 objects that are to be found in that publication point that can be 345 verified by this EE certificate, and the hash value of each product 346 (excluding the manifest itself) [I-D.ietf-sidr-rpki-manifests]. 348 In the case of multi-use EE, the repository publication point 349 contains all published objects that can be verified using the EE's 350 public key, and a manifest of all such signed objects. A multi-use 351 EE's manifest is limited in scope to listing the objects verified by 352 this multi-use EE certificate. 354 The objects published in a multi-use EE repository publication point 355 do not form a logical, temporal sequence, and thus the filenames 356 associated with each instance of these objects MUST be unique per 357 multi-use EE. 359 It is consistent with this specification, but NOT recommended 360 practice, that all subordinate multi-use EE certificates of a given 361 CA share a common repository publication point. This common 362 repository publication point MAY be shared with that of the given CA, 363 bit this, too, is NOT recommended practice. In this case, the 364 repository publication point would contain multiple manifest objects, 365 one for each (multi-use) EE certificate associated with this common 366 publication point (and, potentially, additional manifests generated 367 by the CA's that also share this common repository publication 368 point). In such a scenario it is necessary to ensure that the set of 369 filenames used by each multi-use EE are unique. A non-normative 370 guideline is for a multi-use EE to use a common base name component 371 that is generated from the public key of the multi-use EE 372 certificate, in the manner described above for CRL names. The choice 373 of whether to use a common single publication repository or a 374 dedicated publication repository for each multi-use EE and CA is an 375 implementation choice. 377 3. Resource Certificate Publication Repository Considerations 379 Each issuer MAY publish its issued certificates and CRL in any 380 repository. However, there are a number of considerations that guide 381 the choice of a suitable repository publication structure: 383 * The publication repository SHOULD be hosted on a highly 384 available service and high capacity publication platform. 386 * The publication repository MUST be available using RSYNC 387 [RFC5781]. Support of additional retrieval mechanisms is the 388 choice of the repository operator. The supported retrieval 389 mechanisms MUST be consistent with the accessMethod element 390 value(s) specified in the SIA of the associated CA or EE. 392 * Each CA repository publication point SHOULD contain the 393 products of this CA, including those objects that can be 394 verified by single-use EE certificates that have been issued by 395 this CA. The signed products of related CA's that are operated 396 by the same entity MAY share this CA repository publication 397 point. Aside from subdirectories, any other objects SHOULD NOT 398 be placed in a repository publication point. 400 Any such subdirectory SHOULD be the repository publication 401 point of a CA or EE certificate that is contained in the CA 402 directory. These considerations also apply recursively to 403 subdirectories of these directories. 405 * Signed Objects are published in the location indicated by the 406 SIA field of the EE certificate used to verify the signature of 407 each object. The choice of the repository publication point is 408 determined by the nature of the corresponding EE certificate. 409 In the case of a "multi-use" EE certificate signed objects are 410 published in the EE repository publication point referenced by 411 the SIA extension of the EE certificate in question. In the 412 case of a "single-use" EE certificate the signed object is 413 published in the repository publication point of the CA 414 certificate that issued the EE certificate. The SIA extension 415 of the single use EE certificate references this object rather 416 than the repository publication 417 directory[I-D.ietf-sidr-res-certs]. 419 * It is recommended in Section 2.1 that repository operators 420 SHOULD implement some form of directory management regime 421 function on the repository to ensure that RPs who are 422 performing retrieval operations on the repository are not 423 exposed to intermediate states during changes to the repository 424 and the associated manifest. Notwithstanding the following 425 commentary, RPs SHOULD NOT assume that a consistent repository 426 and manifest state is assured, and organise their retrieval 427 operations accordingly (see Section 5). 429 The manner in which a repository operator can implement a 430 directory update regime that mitigates the risk of the manifest 431 and directory contents being inconsistent, to some extent, is 432 dependant on the operational characteristics of the filesystem 433 that hosts the repository, so the following comments are non- 434 normative in terms of any implicit guidelines for repository 435 operators. 437 A commonly used technique to avoid exposure to inconsistent 438 retrieval states during updates to a large directory, is to 439 batch a set of changes to be made, create a working copy of the 440 directory's contents, and then perform the batch of changes to 441 this local copy of the directory. On completion, rename the 442 filesystem symbolic link of the repository directory name to 443 point to this working copy of the directory. The old 444 repository directory contents can be purged at a slightly later 445 time. However, it is noted that the outcomes of this technique 446 in terms of ensuring the integrity of client synchronization 447 functions performed over the directory depend on the 448 interaction between the supported access mechanisms and the 449 local filesystem behaviour. It is probable that this technique 450 will not remove all possibilities for RPs to see inconsistent 451 states between the manifest and the repository. 453 4. Certificate Reissuance and Repositories 455 If a CA certificate is reissued, e.g., due to changes in the set of 456 resources contained in the number resource extensions, it should not 457 be necessary to reissue all certificates issued under it. Because 458 these certificates contains AIA extensions that point to the 459 publication point for the CA certificate, a CA SHOULD use a name for 460 its repository publication point that persists across certificate 461 reissuance events. That is, reissued CA certificates SHOULD use the 462 same repository publication point as previously issued CA 463 certificates having the same subject and subject public key, such 464 that certificate reissuance SHOULD intentionally overwrite the 465 previously issued certificate within the repository publication 466 point. 468 It is noted in section Section 2.2 that when a CA performs a key 469 rollover the entity SHOULD use a name for its repository publication 470 point that persists across key rollover. In such cases the 471 repository publication point will contain the CRLs, and manifests of 472 both CA instances as a transient state in the key rollover procedure. 473 The RPKI key rollover procedure [I-D.ietf-sidr-keyroll] requires that 474 the subordinate products of the old CA are overwritten in the common 475 repository publication point by subordinate products issued by the 476 new CA. 478 5. Synchronising Repositories with a Local Cache 480 It is possible to perform the validation-related task of certificate 481 path construction using retrieval of individual certificates and 482 certificate revocation lists using online retrieval of individual 483 certificates, sets of candidate certificates and certificate 484 revocation lists based on the AIA, SIA and CRLDP certificate fields. 485 This is NOT recommended in circumstances where speed and efficiency 486 are relevant considerations. 488 To enable efficient validation of RPKI certificates, CRLs, and signed 489 objects, it is recommended that each relying party maintain a local 490 repository containing a synchronized copy of all valid certificates, 491 current certificate revocation lists, and all related signed objects. 493 The general approach to repository synchronisation is one of a "top- 494 down" walk of the distributed repository structure. This commences 495 with the collection of locally selected trust anchor material 496 corresponding to the local choice of Trust Anchors, which can be used 497 to load the initial set of self-signed resource certificate(s) that 498 form the "seed" of this process [I-D.ietf-sidr-ta]. The process then 499 populates the local repository cache will all valid certificates that 500 have been issued by these issuers. This procedure can be recursively 501 applied to each of these subordinate certificates. Such a repository 502 traversal process SHOULD support a locally configured maximal chain 503 length from the initial trust anchors to the current working 504 validation point in order to ensure that the process does not follow 505 a loop or a non-terminating certificate chain. 507 RPs SHOULD ensure that this local synchronisation uses the retrieved 508 manifests [I-D.ietf-sidr-rpki-manifests] to ensure that they are 509 synchronising against a current consistent state of each repository 510 publication point. It is noted in Section 3 that a repository 511 operator cannot assure RPs that when the repository publication point 512 contents are updated that the manifest contents and the repository 513 contents will be precisely aligned at all times. RPs SHOULD use a 514 retrieval algorithm that takes this potential for transient 515 inconsistency into account. Possible algorithms for the RP to 516 mitigate this situation include performing the synchronisation across 517 the repository twice in succession, or performing a manifest 518 retrieval both before and after the synchronisation of the directory 519 contents, and repeating the synchronization function if the second 520 copy of the manifest differs from the first. 522 6. Security Considerations 524 Repositories are not assumed to be integrity-protected databases, and 525 repository retrieval operations MAY be vulnerable to various forms of 526 "man-in-the-middle" attacks. Corruption of retrieved objects is 527 detectable by a relying party through the validation of the signature 528 associated with each retrieved object. Replacement of newer 529 instances of an object with an older instance of the same object is 530 detectable through the use of manifests. Insertion of revoked, 531 deleted certificates is detected through the retrieval and processing 532 of CRLs at scheduled intervals. However, even the use of manifests 533 and CRLs will not allow a relying party to detect all forms of 534 substitution attacks based on older (but not expired) valid objects. 536 7. IANA Considerations 538 [There are no IANA considerations in this document.] 540 8. References 541 8.1. Normative References 543 [I-D.ietf-sidr-arch] 544 Lepinski, M. and S. Kent, "An Infrastructure to Support 545 Secure Internet Routing", draft-ietf-sidr-arch-11.txt 546 (work in progress), September 2010. 548 [I-D.ietf-sidr-res-certs] 549 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 550 X.509 PKIX Resource Certificates", 551 draft-ietf-sidr-res-certs-18.txt (work in progress), 552 May 2010. 554 [I-D.ietf-sidr-rpki-manifests] 555 Austein, R., Huston, G., Kent, S., and M. Lepinski, 556 "Manifests for the Resource Public Key Infrastructure", 557 draft-ietf-sidr-rpki-manifests (work in progress), 558 May 2010. 560 8.2. Informative References 562 [I-D.ietf-sidr-keyroll] 563 Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover 564 in the RPKI", draft-ietf-sidr-keyroll-02.txt (work in 565 progress), October 2010. 567 [I-D.ietf-sidr-ta] 568 Michaelson, G., Kent, S., and G. Huston, "A Profile for 569 Trust Anchor Material for the Resource Certificate PKI", 570 draft-ietf-sidr-ta-04.txt (work in progress), May 2010. 572 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 573 Addresses and AS Identifiers", RFC 3779, June 2004. 575 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 576 Resource Identifier (URI): Generic Syntax", STD 66, 577 RFC 3986, January 2005. 579 [RFC4387] Gutmann, P., "Internet X.509 Public Key Infrastructure 580 Operational Protocols: Certificate Store Access via HTTP", 581 RFC 4387, February 2006. 583 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 584 Encodings", RFC 4648, October 2006. 586 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 587 Housley, R., and W. Polk, "Internet X.509 Public Key 588 Infrastructure Certificate and Certificate Revocation List 589 (CRL) Profile", RFC 5280, May 2008. 591 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 592 Scheme", RFC 5781, February 2010. 594 Authors' Addresses 596 Geoff Huston 597 APNIC 599 Email: gih@apnic.net 600 URI: http://www.apnic.net 602 Robert Loomans 603 APNIC 605 Email: robertl@apnic.net 606 URI: http://www.apnic.net 608 George Michaelson 609 APNIC 611 Email: ggm@apnic.net 612 URI: http://www.apnic.net