idnits 2.17.1 draft-ietf-sidr-repos-struct-09.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 10 characters in excess of 72. 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 (July 28, 2011) is 4650 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) == Missing Reference: 'RFC-to-be' is mentioned on line 588, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-21 == Outdated reference: A later version (-16) exists of draft-ietf-sidr-rpki-manifests-13 == Outdated reference: A later version (-04) exists of draft-ietf-sidr-signed-object-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'RSYNC' == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-12 == Outdated reference: A later version (-08) exists of draft-ietf-sidr-keyroll-07 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 4 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: Standards Track G. Michaelson 5 Expires: January 29, 2012 APNIC 6 July 28, 2011 8 A Profile for Resource Certificate Repository Structure 9 draft-ietf-sidr-repos-struct-09.txt 11 Abstract 13 This document defines a profile for the structure of the Resource PKI 14 distributed repository. Each individual repository publication point 15 is a directory that contains files that correspond to X.509 / PKIX 16 Resource Certificates, Certificate Revocation Lists and signed 17 objects. This profile defines the object (file) naming scheme, the 18 contents of repository publication points (directories), and a 19 suggested internal structure of a local repository cache that is 20 intended to facilitate synchronization across a distributed 21 collection of repository publication points and to facilitate 22 certification path construction. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 29, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. RPKI Repository Publication Point Content and Structure . . . 4 61 2.1. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.2. CA Repository Publication Points . . . . . . . . . . . . . 6 63 3. Resource Certificate Publication Repository Considerations . . 8 64 4. Certificate Re-issuance and Repositories . . . . . . . . . . . 10 65 5. Synchronising Repositories with a Local Cache . . . . . . . . 11 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 7.1. Media Types . . . . . . . . . . . . . . . . . . . . . . . 12 69 7.1.1. application/rpki-manifest . . . . . . . . . . . . . . 12 70 7.1.2. application/rpki-roa . . . . . . . . . . . . . . . . . 13 71 7.2. RPKI Repository Name Scheme Registry . . . . . . . . . . . 13 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 To validate attestations made in the context of the Resource Public 81 Key Infrastructure (RPKI) [I-D.ietf-sidr-arch], relying parties (RPs) 82 need access to all the X.509 / PKIX Resource Certificates, 83 Certificate Revocation Lists (CRLs), and signed objects that 84 collectively define the RPKI. 86 Each issuer of a certificate, CRL or a signed object makes it 87 available for download to RPs through the publication of the object 88 in an RPKI repository. 90 The repository system is a collection of all signed objects that MUST 91 be globally accessible to all RPs. When certificates, CRLs and 92 signed objects are created, they are uploaded to a repository 93 publication point, from whence they can be downloaded for use by RPs. 95 This profile defines the recommended object (file) naming scheme, the 96 recommended contents of repository publication points (directories), 97 and a suggested internal structure of a local repository cache that 98 is intended to facilitate synchronization across a distributed 99 collection of repository publication points and facilitate 100 certification path construction. 102 A Resource Certificate attests to a binding of an entity's public key 103 to a set of IP address blocks and AS numbers. The Subject of a 104 Resource Certificate can demonstrate that it is the holder of the 105 resources enumerated in the certificate by using its private key to 106 generate a digital signature (that can be verified using the public 107 key from the certificate). 109 1.1. Terminology 111 It is assumed that the reader is familiar with the terms and concepts 112 described in "Internet X.509 Public Key Infrastructure Certificate 113 and Certificate Revocation List (CRL) Profile" [RFC5280], and "X.509 114 Extensions for IP Addresses and AS Identifiers" [RFC3779]. 116 In addition, the following terms are used in this document: 118 Repository Object (or Object): 119 This refers to a terminal object in a repository publication 120 point. A terminal object is conventionally implemented as a file 121 in a publicly accessible directory, where the file is not a 122 directory itself, although other forms of objects that have an 123 analogous public appearance to a file are encompassed by this 124 term. 126 Repository Publication Point: 127 This refers to a collection of Repository Objects that are 128 published at a common publication point. This is conventionally 129 implemented as a directory in a publicly accessible filesystem 130 that is identified by a URI [RFC3986], although other forms of 131 local storage that have an analogous public appearance to a simple 132 directory of files are also encompassed by this term. 134 Repository Instance: 135 This refers to a collection of one or more Repository Publication 136 Points that share a common publication instance. This 137 conventionally is implemented as a collection of filesystem 138 directories that share a common URI prefix, where each directory 139 is also identifiable by its own unique URI. 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 2. RPKI Repository Publication Point Content and Structure 147 The RPKI does not require that a single repository instance contain 148 all published RPKI objects. Instead, the RPKI repository system is 149 comprised of multiple repository instances. Each individual 150 repository instance is composed of one or more repository publication 151 points. Each repository publication point is used by one or more 152 entities referenced in RPKI certificates, as defined in the 153 certificate's Subject Information Authority (SIA) extension. 155 This section describes the collection of objects (RPKI certificates, 156 CRLs, manifests and signed objects) held in repository publication 157 points. 159 For every Certification Authority (CA) certificate in the RPKI there 160 is a corresponding repository publication point that is the 161 authoritative publication point for all current certificates and CRLs 162 issued by this CA. The certificate's SIA extension contains a URI 163 [RFC3986] that references this repository publication point and 164 identifies the repository access mechanisms. Additionally, a 165 certificate's Authority Information Access (AIA) extension contains a 166 URI that references the authoritative location for the Certification 167 Authority (CA) certificate under which the given certificate was 168 issued. 170 For example, if the subject of certificate A has issued certificates 171 B and C, then the AIA extensions of certificates B and C both point 172 to the publication point for the certificate A object, and the SIA 173 extension of certificate A points to a repository publication point 174 (directory) containing certificates B and C (see Figure 1). 176 +--------+ 177 +--------->| Cert A |<----+ 178 | | AIA | | 179 | +--------- SIA | | 180 | | +--------+ | 181 | | | 182 | | +-------------------|------------------+ 183 | | | | | 184 | +->| +--------+ | +--------+ | 185 | | | Cert B | | | Cert C | | 186 | | | CRLDP-------+ | | CRLDP-----+ | 187 +----------- AIA | | +----- AIA | | | 188 | | SIA------+ | | SIA------------+ 189 | +--------+ | | +--------+ | | | 190 | | V V | | 191 | | +-----------------+ | | 192 | | | CRL issued by A | | | 193 | A's Repository| +-----------------+ | | 194 | Directory | | | 195 +---------------|----------------------+ | 196 | | 197 +----------------+ | +----------------+ | 198 | B's Repository |<-------+ | C's Repository |<--+ 199 | Directory | | Directory | 200 +----------------+ +----------------+ 202 Figure 1. Use of AIA and SIA extensions in the RPKI. 204 In Figure 1, certificates B and C are issued by (CA) A. Therefore, 205 the AIA extensions of certificates B and C point to (certificate) A, 206 and the SIA extension of certificate A points to the repository 207 publication point of CA A's subordinate products, which includes 208 certificates B and C, as well as the CRL issued by A. The CRL 209 Distribution Points (CRLDP) extension in certificates B and C both 210 point to the Certificate Revocation List (CRL) issued by A. 212 In this distributed repository structure an instance of a CA's 213 repository publication point contains all published certificates 214 issued by that CA, and the CRL issued by that CA. This repository 215 also contains all published digitally signed objects that are 216 verified by an EE certificate issued by this CA. 218 2.1. Manifests 220 Every repository publication point MUST contain a manifest 221 [I-D.ietf-sidr-rpki-manifests]. The manifest contains a list of the 222 names of all objects, as well as the hash value of each object's 223 contents, that are currently published by a CA, or by an EE. 225 An authority MAY perform a number of object operations on a 226 publication repository within the scope of a repository change before 227 issuing a single manifest that covers all the operations within the 228 scope of this change. Repository operators SHOULD implement some 229 form of directory management regime function on the repository to 230 ensure that RPs who are performing retrieval operations on the 231 repository are not exposed to intermediate states during changes to 232 the repository and the associated manifest. (It is noted that if no 233 such access regime is in place then RPs MAY be exposed to 234 intermediate repository states where the manifest and the repository 235 contents may not be precisely aligned. Specific cases and actions in 236 such situation of mis-alignment of the manifest and the repository 237 contents are considered in [I-D.ietf-sidr-rpki-manifests]) 239 2.2. CA Repository Publication Points 241 A CA Certificate has two accessMethod elements specified in its SIA 242 field. The id-ad-caRepository accessMethod element has an associated 243 accessLocation element that points to the repository publication 244 point of the certificates issued by this CA, as specified in 245 [I-D.ietf-sidr-res-certs]. The id-ad-rpkiManifest accessMethod 246 element has an associated accessLocation element that points to the 247 manifest object, as an object URI (as distinct to a directory URI), 248 that is associated with this CA. 250 A CA's publication repository contains the current (non-expired and 251 non-revoked) certificates issued by this CA, the most recent CRL 252 issued by this CA, the current manifest, and all other current signed 253 objects that can be verified using an EE certificate 254 [I-D.ietf-sidr-res-certs] issued by this CA. 256 The CA's manifest contains the names of this collection of objects, 257 together with the hash value of each object's contents, with the 258 single exception of the manifest itself. 260 The RPKI design requires that a CA be uniquely associated with a 261 single key pair. Thus, the administrative entity that is a CA 262 performs key rollover by generating a new CA certificate with a new 263 Subject name, as well as a new key pair [I-D.ietf-sidr-keyroll]. 264 (The reason for the new Subject name is that in the context of the 265 RPKI the Subject names in all certificates issued by a CA are 266 intended to be unique, and because the RPKI key rollover procedure 267 creates a new instance of a CA with the new key, the name constraint 268 implies the need for a new Subject name for the CA with the new key.) 269 In such cases the entity SHOULD continue to use the same repository 270 publication point for both CA instances during the key rollover, 271 ensuring that the value of the AIA extension in indirect subordinate 272 objects that refer to the certificates issued by this CA remain valid 273 across the key rollover, and that the re-issuance of subordinate 274 certificates in a key rollover is limited to the collection of 275 immediate subordinate products of this CA [I-D.ietf-sidr-keyroll]. 276 In such cases the repository publication point will contain the CRL, 277 manifest and subordinate certificates of both CA instances. (It is 278 feasible for the entity to use distinct repository publication points 279 for the old and new CA keys, but in such a case very careful 280 coordination would be required with subordinate CAs and EEs to ensure 281 that the AIA pointers in the indirect subordinate levels of the RPKI 282 hierarchy are correctly aligned to the subordinate products of the 283 new CA.) 285 The following paragraphs provide guidelines for naming objects in a 286 CA's repository publication point: 288 CRL: 289 When a CA issues a new CRL, it replaces the previous CRL (issued 290 under the same CA key pair) in the repository publication point. 291 CAs MUST NOT continue to publish previous CRLs in the repository 292 publication point. Thus, it MUST replace (overwrite) previous 293 CRLs signed by the same CA (instance). A non-normative guideline 294 for naming such objects is that the file name chosen for the CRL 295 in the repository be a value derived from the public key of the 296 CA. One such method of generating a CRL publication name is 297 described in section 2.1 of [RFC4387]; convert the 160-bit hash of 298 a CA's public key value into a 27-character string using a 299 modified form of Base64 encoding, with an additional modification 300 as proposed in section 5, table 2, of [RFC4648]. The filename 301 extension of ".crl" MUST be used, to denote the file as a CRL. 302 Each ".crl" file contains exactly one CRL, encoded in DER format. 304 Manifest: 305 When a new instance of a manifest is published, it MUST replace 306 the previous manifest, to avoid confusion. CAs MUST NOT continue 307 to publish previous CA manifests in the repository publication 308 point. A non-normative guideline for naming such objects is that 309 the filename chosen for the manifest in the publication repository 310 be a value derived from the public key part of the entity's key 311 pair, using the algorithm described for CRLs above for generation 312 of filenames. The filename extension of ".mft" MUST be used, to 313 denote the object as a manifest. 315 Certificates: 316 Within the RPKI framework it is possible that a CA MAY issue a 317 series of certificates to the same subject name, the same subject 318 public key, and the same resource collection. However, a relying 319 party requires access only to the most recently published 320 certificate in such a series. Thus, such a series of certificates 321 SHOULD share the same filename. This ensures that each successive 322 issued certificate in such a series effectively overwrites the 323 previous instance of the certificate. It is feasible to use 324 different filenames, but this imposes a burden on the validating 325 user. A non-normative guideline for naming such objects is for 326 the CA to adopt a (local) policy requiring a subject to use a 327 unique key pair for each unique instance of a certificate series 328 issued to the same subject, thereby allowing the CA to use a file 329 name generation scheme based on the subject's public key, e.g., 330 using the algorithm described above for CRLs above. Published 331 certificates MUST use a filename extension of ".cer" to denote the 332 object as a certificate. Each ".cer" file contains exactly one 333 certificate, encoded in DER format. 335 Signed Objects: 336 RPKI Signed objects [I-D.ietf-sidr-signed-object] are published in 337 the repository publication point referenced by the SIA of the CA 338 certificate that issued the EE certificate used to validate the 339 digital signature of the signed object (and are directly 340 referenced by the SIA of that EE certificate). A general non- 341 normative guideline for naming such RPKI Signed Objects is for the 342 filename of such objects to be derived from the associated EE 343 certificate's public key, applying the algorithm described above. 344 Published RPKI Signed Objects MUST NOT use the filename extensions 345 ".crl", ".mft", or ".cer". 347 One form of signed object defined at the time of publication of 348 this document is a Route Origination Authorization (ROA) 349 [I-D.ietf-sidr-roa-format]. Published ROAs MUST use a filename 350 extension of ".roa" to denote the object as a ROA. 352 3. Resource Certificate Publication Repository Considerations 354 Each issuer MAY publish its issued certificates and CRL in any 355 repository. However, there are a number of considerations that guide 356 the choice of a suitable repository publication structure: 358 * The publication repository SHOULD be hosted on a highly 359 available service and high capacity publication platform. 361 * The publication repository MUST be available using RSYNC 362 [RFC5781] [RSYNC]. Support of additional retrieval mechanisms 363 is the choice of the repository operator. The supported 364 retrieval mechanisms MUST be consistent with the accessMethod 365 element value(s) specified in the SIA of the associated CA or 366 EE certificate. 368 * Each CA repository publication point SHOULD contain the 369 products of this CA, including those objects that can be 370 verified by EE certificates that have been issued by this CA. 371 The signed products of related CA's that are operated by the 372 same entity MAY share this CA repository publication point. 373 Aside from subdirectories, any other objects SHOULD NOT be 374 placed in a repository publication point. 376 Any such subdirectory SHOULD be the repository publication 377 point of a CA or EE certificate that is contained in the CA 378 directory. These considerations also apply recursively to 379 subdirectories of these directories. Detection of content 380 which is not a CA product has the potential to cause confusion 381 to RPs, and in such a case RPs should exercise caution in such 382 cases not invalidate the valid CA products found at the CA's 383 repository publication point. 385 * Signed Objects are published in the location indicated by the 386 SIA field of the EE certificate used to verify the signature of 387 each object. Signed objects are published in the repository 388 publication point of the CA certificate that issued the EE 389 certificate. The SIA extension of the EE certificate 390 references this object rather than the repository publication 391 directory[I-D.ietf-sidr-res-certs]. 393 * Section 2.1 states that repository operators SHOULD implement 394 some form of directory management regime function on the 395 repository to ensure that RPs who are performing retrieval 396 operations on the repository are not exposed to intermediate 397 states during changes to the repository and the associated 398 manifest. Notwithstanding the following commentary, RPs SHOULD 399 NOT assume that a consistent repository and manifest state is 400 assured, and organise their retrieval operations accordingly 401 (see Section 5). 403 The manner in which a repository operator can implement a 404 directory update regime that mitigates the risk of the manifest 405 and directory contents being inconsistent, to some extent, is 406 dependent on the operational characteristics of the filesystem 407 that hosts the repository, so the following comments are non- 408 normative in terms of any implicit guidelines for repository 409 operators. 411 A commonly used technique to avoid exposure to inconsistent 412 retrieval states during updates to a large directory, is to 413 batch a set of changes to be made, create a working copy of the 414 directory's contents, and then perform the batch of changes to 415 this local copy of the directory. On completion, rename the 416 filesystem symbolic link of the repository directory name to 417 point to this working copy of the directory. The old 418 repository directory contents can be purged at a slightly later 419 time. However, it is noted that the outcomes of this technique 420 in terms of ensuring the integrity of client synchronization 421 functions performed over the directory depend on the 422 interaction between the supported access mechanisms and the 423 local filesystem behaviour. It is probable that this technique 424 will not remove all possibilities for RPs to see inconsistent 425 states between the manifest and the repository. Because a 426 repository has the potential to be in an partially updated 427 state it cannot be guaranteed to be internally self consistent 428 all the time. 430 4. Certificate Re-issuance and Repositories 432 If a CA certificate is re-issued, e.g., due to changes in the set of 433 resources contained in the number resource extensions, it should not 434 be necessary to re-issue all certificates issued under it. Because 435 these certificates contain AIA extensions that point to the 436 publication point for the CA certificate, a CA SHOULD use a name for 437 its repository publication point that persists across certificate re- 438 issuance events. That is, re-issued CA certificates SHOULD use the 439 same repository publication point as previously issued CA 440 certificates having the same subject and subject public key, such 441 that certificate re-issuance SHOULD intentionally overwrite the 442 previously issued certificate within the repository publication 443 point. 445 It is noted in section Section 2.2 that when a CA performs a key 446 rollover the entity SHOULD use a name for its repository publication 447 point that persists across key rollover. In such cases the 448 repository publication point will contain the CRLs, and manifests of 449 both CA instances as a transient state in the key rollover procedure. 450 The RPKI key rollover procedure [I-D.ietf-sidr-keyroll] requires that 451 the subordinate products of the old CA are overwritten in the common 452 repository publication point by subordinate products issued by the 453 new CA. 455 5. Synchronising Repositories with a Local Cache 457 It is possible to perform the validation-related task of certificate 458 path construction using retrieval of individual certificates and 459 certificate revocation lists using online retrieval of individual 460 certificates, sets of candidate certificates and certificate 461 revocation lists based on the AIA, SIA and CRLDP certificate fields. 462 This is NOT recommended in circumstances where speed and efficiency 463 are relevant considerations. 465 To enable efficient validation of RPKI certificates, CRLs, and signed 466 objects, it is recommended that each relying party maintain a local 467 repository containing a synchronized copy of all valid certificates, 468 current certificate revocation lists, and all related signed objects. 470 The general approach to repository synchronization is one of a "top- 471 down" walk of the distributed repository structure. This commences 472 with the collection of locally selected trust anchor material 473 corresponding to the local choice of Trust Anchors, which can be used 474 to load the initial set of self-signed resource certificate(s) that 475 form the "seed" of this process [I-D.ietf-sidr-ta]. The process then 476 populates the local repository cache will all valid certificates that 477 have been issued by these issuers. This procedure can be recursively 478 applied to each of these subordinate certificates. Such a repository 479 traversal process SHOULD support a locally configured maximal chain 480 length from the initial trust anchors. If this is not done then 481 there might be a SIA pointer loop, or other degnerate forms of the 482 logical RPKI hierarchy that would cause an RP to malfunction when 483 performing a repository synchronization operation with the RP's local 484 RPKI cache. 486 RPs SHOULD ensure that this local synchronization uses the retrieved 487 manifests [I-D.ietf-sidr-rpki-manifests] to ensure that they are 488 synchronizing against a current consistent state of each repository 489 publication point. It is noted in Section 3 that a repository 490 operator cannot assure RPs that when the repository publication point 491 contents are updated that the manifest contents and the repository 492 contents will be precisely aligned at all times. RPs SHOULD use a 493 retrieval algorithm that takes this potential for transient 494 inconsistency into account. Possible algorithms for the RP to 495 mitigate this situation include performing the synchronization across 496 the repository twice in succession, or performing a manifest 497 retrieval both before and after the synchronization of the directory 498 contents, and repeating the synchronization function if the second 499 copy of the manifest differs from the first. 501 6. Security Considerations 503 Repositories are not assumed to be integrity-protected databases, and 504 repository retrieval operations might be vulnerable to various forms 505 of "man-in-the-middle" attacks. Corruption of retrieved objects is 506 detectable by a relying party through the validation of the signature 507 associated with each retrieved object. Replacement of newer 508 instances of an object with an older instance of the same object is 509 detectable through the use of manifests. Insertion of revoked, 510 deleted certificates is detected through the retrieval and processing 511 of CRLs at scheduled intervals. However, even the use of manifests 512 and CRLs will not allow a relying party to detect all forms of 513 substitution attacks based on older (but not expired) valid objects. 515 Confidentiality is not provided by the repository, or by the signed 516 objects published in the repository. Data that is subject to 517 controlled access should not be included in signed objects in the 518 repository unless there is some specified mechanism used to ensure 519 the confidentiality of the data contained in the signed object. 521 7. IANA Considerations 523 7.1. Media Types 525 IANA is requested to register the following two media types: 527 application/rpki-manifest 528 application/rpki-roa 530 This document also uses the .cer and .crl file extensions from 531 application/pkix-cert and application/pkix-crl media registries 532 defined in [RFC2585]. 534 7.1.1. application/rpki-manifest 536 MIME media type name: application 537 MIME subtype name: rpki-manifest 538 Required parameters: None 539 Optional parameters: None 540 Encoding considerations: binary 541 Security considerations: Carries a RPKI Manifest 542 [I-D.ietf-sidr-rpki-manifests]. 543 Interoperability considerations: None 544 Published specification: This document 545 Applications which use this media type: Any MIME-complaint transport 546 Additional information: 547 Magic number(s): None 548 File extension(s): .mft 549 Macintosh File Type Code(s): 550 Person & email address to contact for further information: Geoff 551 Huston 552 Intended usage: COMMON 553 Author/Change controller: Geoff Huston 555 7.1.2. application/rpki-roa 557 MIME media type name: application> 558 MIME subtype name: rpki-roa 559 Required parameters: None 560 Optional parameters: None 561 Encoding considerations: binary 562 Security considerations: Carries a RPKI ROA 563 [I-D.ietf-sidr-roa-format] 564 Interoperability considerations: None 565 Published specification: This document 566 Applications which use this media type: Any MIME-complaint transport 567 Additional information: 568 Magic number(s): None 569 File extension(s): .roa 570 Macintosh File Type Code(s): 571 Person & email address to contact for further information: Geoff 572 Huston 573 Intended usage: COMMON 574 Author/Change controller: Geoff Huston 576 7.2. RPKI Repository Name Scheme Registry 578 IANA is requested to create the "RPKI Repository Name Scheme" 579 registry. The registry will contain three-letter filename extensions 580 for RPKI repository objects. The registry's contents is to be 581 managed by IETF Review [RFC5226]. The initial contents of this 582 register will include the following: 584 Filename extension RPKI Object Reference 585 .cer Certificate [RFC-to-be] 586 .crl Certificate Revocation List [RFC-to-be] 587 .mft Manifest [RFC-to-be] 588 .roa Route Origination Authorization [RFC-to-be] 590 8. Acknowledgements 592 This document has benefitted from helpful review comments and input 593 from Stephen Kent, Matt Lepenski, Michael Elkins, Russ Housley and 594 Sean Turner. 596 9. References 598 9.1. Normative References 600 [I-D.ietf-sidr-res-certs] 601 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 602 X.509 PKIX Resource Certificates", 603 draft-ietf-sidr-res-certs-21.txt (work in progress), 604 December 2010. 606 [I-D.ietf-sidr-roa-format] 607 Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 608 Origin Authorizations (ROAs)", draft-ietf-sidr-roa-format 609 (work in progress), October 2009. 611 [I-D.ietf-sidr-rpki-manifests] 612 Austein, R., Huston, G., Kent, S., and M. Lepinski, 613 "Manifests for the Resource Public Key Infrastructure", 614 draft-ietf-sidr-rpki-manifests-13.txt (work in progress), 615 June 2011. 617 [I-D.ietf-sidr-signed-object] 618 Lepinski, M., Chi, A., and S. Kent, "Signed Object 619 Template for the Resource Public Key Infrastructure", 620 draft-ietf-sidr-signed-object-01.txt (work in progress), 621 October 2010. 623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", BCP 14, RFC 2119, March 1997. 626 [RSYNC] Tridgell, A., "rsync", March 2008, 627 . 629 9.2. Informative References 631 [I-D.ietf-sidr-arch] 632 Lepinski, M. and S. Kent, "An Infrastructure to Support 633 Secure Internet Routing", draft-ietf-sidr-arch-12.txt 634 (work in progress), February 2010. 636 [I-D.ietf-sidr-keyroll] 637 Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover 638 in the RPKI", draft-ietf-sidr-keyroll-07.txt (work in 639 progress), June 2011. 641 [I-D.ietf-sidr-ta] 642 Huston, G., Weiler, S., Michaelson, G., and S. Kent, "A 643 Profile for Trust Anchor Material for the Resource 644 Certificate PKI", draft-ietf-sidr-ta-07.txt (work in 645 progress), Aprril 2011. 647 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 648 Infrastructure Operational Protocols: FTP and HTTP", 649 RFC 2585, May 1999. 651 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 652 Addresses and AS Identifiers", RFC 3779, June 2004. 654 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 655 Resource Identifier (URI): Generic Syntax", STD 66, 656 RFC 3986, January 2005. 658 [RFC4387] Gutmann, P., "Internet X.509 Public Key Infrastructure 659 Operational Protocols: Certificate Store Access via HTTP", 660 RFC 4387, February 2006. 662 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 663 Encodings", RFC 4648, October 2006. 665 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 666 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 667 May 2008. 669 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 670 Housley, R., and W. Polk, "Internet X.509 Public Key 671 Infrastructure Certificate and Certificate Revocation List 672 (CRL) Profile", RFC 5280, May 2008. 674 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 675 Scheme", RFC 5781, February 2010. 677 Authors' Addresses 679 Geoff Huston 680 APNIC 682 Email: gih@apnic.net 683 URI: http://www.apnic.net 685 Robert Loomans 686 APNIC 688 Email: robertl@apnic.net 689 URI: http://www.apnic.net 691 George Michaelson 692 APNIC 694 Email: ggm@apnic.net 695 URI: http://www.apnic.net