idnits 2.17.1 draft-ietf-sidr-repos-struct-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 484. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 491. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 497. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 173: '... [I-D.ietf-sidr-res-certs]) MUST maintain a manifest...' RFC 2119 keyword, line 318: '...ation repository MUST be available usi...' RFC 2119 keyword, line 355: '... Therefore, a CA SHOULD use a persiste...' 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 (October 5, 2008) is 5682 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 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 8, 2009 APNIC 6 October 5, 2008 8 A Profile for Resource Certificate Repository Structure 9 draft-ietf-sidr-repos-struct-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 8, 2009. 36 Abstract 38 This document defines a profile for the structure of repository 39 publication points that contain X.509 / PKIX Resource Certificates, 40 Certificate Revocation Lists and signed objects. This profile 41 contains the proposed object naming scheme, the contents of 42 repository publication points, the contents of publication point 43 manifests and a suggested internal structure of a local repository 44 cache that is intended to facilitate synchronization across a 45 distributed collection of repository publication points and 46 facilitate certification path construction. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. RPKI Repository Publication Point Content and Structure . . . 3 53 2.1. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 5 54 2.2. CA Repository Publication Point . . . . . . . . . . . . . 5 55 2.3. EE Repository Publication Point . . . . . . . . . . . . . 7 56 3. Resource Certificate Publication Repository Considerations . . 8 57 4. Certificate Reissuance and Repositories . . . . . . . . . . . 9 58 5. Synchronising Repositories . . . . . . . . . . . . . . . . . . 9 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 61 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 63 Intellectual Property and Copyright Statements . . . . . . . . . . 12 65 1. Introduction 67 To validate attestations made in the context of the Resource Public 68 Key Infrastructure (RPKI) relying parties need access to all the 69 X.509 / PKIX Resource Certificates, Certificate Revocation Lists 70 (CRLs), and signed objects that collectively define the RPKI. 72 Each issuer of a certificate, CRL or a signed object makes it 73 available for download to replying parties through the publication of 74 the object in a RPKI repository. 76 The repository system is the central clearing-house for all signed 77 objects that must be globally accessible to relying parties. When 78 certificates, CRLs and signed objects are created, they are uploaded 79 to a repository publication point, from whence they can be downloaded 80 for use by relying parties. 82 This document defines a profile for the structure of RPKI 83 repositories. This profile contains the proposed object naming 84 scheme, the contents of repository publication points, the contents 85 of publication point manifests and a possible internal structure of a 86 Repository Cache that is intended to facilitate synchronization 87 across a distributed collection of repositories and facilitate 88 certificate path construction. 90 A Resource Certificate describes an action by an Issuer that binds a 91 list of IP address blocks and AS numbers to the Subject of a 92 certificate, identified by the unique association of the Subject's 93 private key with the public key contained in the Resource 94 Certificate. 96 1.1. Terminology 98 It is assumed that the reader is familiar with the terms and concepts 99 described in "Internet X.509 Public Key Infrastructure Certificate 100 and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509 101 Extensions for IP Addresses and AS Identifiers" [RFC3779], and 102 related regional Internet registry address management policy 103 documents. 105 2. RPKI Repository Publication Point Content and Structure 107 RPKI does not use a single repository publication point to publish 108 RPKI objects. Instead, the RPKI repository system is comprised of 109 multiple repository publication points. Each repository publication 110 point is associated with one or more RPKI certificates' publication 111 points, as defined in the certificate's Subject Information Authority 112 (SIA) extension. 114 This section describes the collection of objects (RPKI certificates, 115 CRLs, manifests and signed objects) held in repository publication 116 points. 118 For every certificate in the PKI, there will be a corresponding 119 repository publication point file system directory that is the 120 authoritative publication point for all objects signed by the private 121 key part of the key pair whose public key part is the subject of this 122 certificate, or all objects verifiable via this certificate. The 123 certificate's Subject Information Authority (SIA) extension provides 124 a URI that references this repository publication point and supported 125 repository access mechanisms. Additionally, a certificate's 126 Authority Information Authority (AIA) extension contains a URI that 127 references the authoritative location for the Certification Authority 128 (CA) certificate under which the given certificate was issued. That 129 is, if the subject of certificate A has issued certificate B, then 130 the AIA extension of certificate B points to certificate A, and the 131 SIA extension of certificate A points to a directory containing 132 certificate B (see Figure 1). 134 +--------+ 135 +--------->| Cert A |<----+ 136 | | CRLDP | | 137 | | AIA | | 138 | +--------- SIA | | 139 | | +--------+ | 140 | | | 141 | | | 142 | | | 143 | | +-------------------|------------------+ 144 | | | | | 145 | +->| +--------+ | +--------+ | 146 | | | Cert B | | | Cert C | | 147 | | | CRLDP ----+ | | CRLDP -+-+ | 148 +----------- AIA | | +----- AIA | | | 149 | | SIA | | | SIA | | | 150 | +--------+ | +--------+ | | 151 | V | | 152 | +---------+ | | 153 | | A's CRL |<-----------+ | 154 | +---------+ | 155 | A's Repository Publication Directory | 156 +--------------------------------------+ 158 Figure 1: In this example, certificates B and C are issued under 159 certificate A. Therefore, the AIA extensions of certificates B and C 160 point to A, and the SIA extension of certificate A points to the 161 repository publication point containing certificates B and C, as well 162 as A'a CRL. 164 The general intent of this profile is that an instance of a CA's 165 repository publication point contains all the signed products of the 166 CA, and an End Entity's (EE's) repository publication point contains 167 all the objects signed by the EE. 169 2.1. Manifests 171 All CA's and all EE's that have repository publication points 172 ("multi-use" EE certificates, as defined in 173 [I-D.ietf-sidr-res-certs]) MUST maintain a manifest 174 [I-D.ietf-sidr-rpki-manifests] of their published subordinate 175 products. The manifest contains a list of the names of all objects 176 issued by that CA or signed by the EE certificate and published in a 177 repository publication point directory, as well as the hash value of 178 each object's contents. 180 The collection of manifests across the entire RPKI is "complete set", 181 in that all current valid published objects are described in 182 precisely one manifest. 184 2.2. CA Repository Publication Point 186 A CA Certificate has two accessMethods specified in its SIA field. 187 The id-ad-caRepository accessMethod has an associated accessLocation 188 that points to the the repository publication point of the products 189 of this CA, as specified in [I-D.ietf-sidr-res-certs]. The id-ad- 190 rpkiManifest accessMethod has an associated access location that 191 points to the manifest object, as an object URL, that is associated 192 with this CA. 194 In the case of a CA's publication repository in the scope of the 195 RPKI, the repository contains the current certificates issued by this 196 CA, the most recent CRLs that are associated with the CA's non- 197 revoked keypairs, the current manifest, and all objects that are 198 signed using a "single-use" EE certificate, where the EE certificate 199 was issued by this CA. 201 The CA's manifest describes all the objects that are to be found in 202 that publication point that were issued by this CA, and all published 203 objects signed by "single-use" EE certificates that have been issued 204 by this CA, and the hash value of each object (excluding the manifest 205 itself) [I-D.ietf-sidr-rpki-manifests]. 207 Becuase a CA is associated with a single key pair an entity performss 208 the equivalent of a key rollover operation by generating a new CA 209 instance as well as a new key pair. In such cases the entity may 210 chose to continue of use a single repository publication point for 211 both CA instances. In such cases the repository publication pooint 212 will contain the CRL, manifest and subordinate certificates of both 213 CA instances. 215 Some guidelines for naming objects in a CA's repository publication 216 point are as follows: 218 CRL: The scope of a CRL in the RPKI is all objects issued by a CA, 219 implying that publication of successive instances of a CA's CRL 220 may overwrite previous instances of CRLs signed by the same CA's 221 private key in the publication repository. It is consistent with 222 this objective that the name chosen for the CRL in the publication 223 repository be a value derived from the public key part of the CA's 224 key pair that was used to sign the CRL. One such method of 225 generating a CRL publication name is described in section 2.1 of 226 [RFC4387], converting the 160-bit hash of the CA's public key 227 value into a 27-character string using a modified form of Base64 228 encoding, with an additional modification as proposed in section 229 5, table 2, of [RFC4648]. 231 Manifest: When a new instance of a manifest is published by the CA, 232 there is no requirement within the RPKI for any relying party to 233 have continuing access to older instances of the CA's manifest. 234 Whn multiple CA's share a common repository publication point 235 their respective manifests must be distinct. It is consistent 236 with this objective that the name chosen for the manifest in the 237 publication repository be a value derived from the public key part 238 of the CA's key pair, using the algorithm described above for CRL 239 object names. 241 Certificates: Within the RPKI framework it is possible that a CA may 242 issue a series of certificates for the same subject name, the same 243 subject public key, and the same resource collection. Within the 244 context of each such series of certificates a relying party has an 245 interest only in the most recently published certificate. The 246 publication repository object name scheme for the CA may use a 247 unique name for each such series of certificates, thereby ensuring 248 that each successive issued certificate in such a series 249 effectively overwrites the previous instance of the certificate 250 series in the publication repository. If the CA adopts a local 251 policy that each subject uses a unique key pair for each unique 252 instance of a certified resource collection then the CA can use a 253 certificate object name scheme that is derived from the subject's 254 public key, applying the algorithm described above for CRL object 255 names to the subject's public key value. 257 Signed Objects: Within the RPKI framework there are two kinds of EE 258 certificates that are used in conjunction with digital 259 certificates: "single-use" EE certificates that are used to sign a 260 single object, and "multi-use" EE Certificates that may be used to 261 sign multiple objects. In the case of "single-use" EE 262 certificates, the single signed object is to be published in the 263 same repository publication point as the EE certificate that was 264 used to sign the object. The signed object name scheme for such 265 objects can be derived from the associated EE certificate's public 266 key, applying the algorithm described above. The signed object is 267 listed in the manifest associated with this repository publication 268 point. In the case of "multi-use" EE certificates the repository 269 publication point is described in the following section. 271 2.3. EE Repository Publication Point 273 EE repository publication points are used in conjunction with "multi- 274 use" EE Certificates. In this case the EE Certificate has two 275 accessMethods specified in its SIA field. The id-ad- 276 signedObjectRepository accessMethod has an associated accessLocation 277 that points to the the repository publication point of the objects 278 signed by this EE certificate, as specified in 279 [I-D.ietf-sidr-res-certs]. The id-ad-rpkiManifest accessMethod has 280 an associated access location that points to the manifest object as 281 an object URL, that is associated with this repository publication 282 point. This manifest describes all the signed objects that are to be 283 found in that publication point that have been signed by this EE 284 certificate, and the hash value of each product (excluding the 285 manifest itself) [I-D.ietf-sidr-rpki-manifests]. 287 In the case of a EE's publication repository in the scope of the 288 RPKI, the repository contains objects that have been signed by the 289 EE's key pair, and a manifest of all such signed objects. 291 The objects published in a EE repository publication point do not 292 form a logical sequence, and must be named uniquely in the context of 293 the publication repository. 295 It is consistent with this specification, but not recommended 296 practice, that all subordinate EE certificates of a given CA share a 297 common publication repository. In this case the repository 298 publication point would contain multiple manifest objects, one for 299 each EE certificate that has placed objects into this common 300 publication point. Each manifest is limited in scope to listing the 301 objects signed by the EE certificate. The implication is that all 302 objects signed by a single EE certificate, including the EE's 303 manifest, share a base name element that is generated from the public 304 key of the EE certificate. The choice of whether to use a common 305 single publication repository or a dedicated publication repository 306 for each EE certificate is an implementation choice. 308 3. Resource Certificate Publication Repository Considerations 310 Each issuer may publish their issued certificates and CRL in any 311 location of their choice. However, there are a number of 312 considerations which guide the choice of a suitable repository 313 publication structure. 315 o The publication repository should be hosted on a highly available 316 service and high capacity publication platform. 318 o The publication repository MUST be available using RSYNC 319 [rsync][I-D.ietf-sidr-res-certs] Support of additional retrieval 320 methods is the choice of the repository operator. The supported 321 access methods should be consistent with the access methods as 322 specified in the SIA of the associated CA or EE. 324 o Each CA publication directory in the publication repository should 325 contain the products of this CA, including those objects signed by 326 single-use EE certificates that have been issued by this CA. The 327 signed products of related CA's that are operated by the same 328 entity may share the CA publication directory. Aside from 329 subdirectories, no other objects should be placed in a publication 330 repository directory. 332 Any such subdirectory should be the repository publication point 333 of a CA or EE certificate that is contained in the CA directory. 334 There are no constraints on the name of a subdirectory. These 335 considerations also apply recursively to subdirectories of these 336 directories. 338 o Signed Objects are published in the location indicated by the SIA 339 field of the EE certificate that has certified the key pair that 340 was used to sign the object. The choice of the repository 341 publication point is determined by the nature of the signing EE 342 certificate. In the case of "multi-use" EE certificates the 343 signed object is published in an EE repository publication point 344 as referenced by the SIA extension of the EE certificate. In the 345 case of "single-use" EE certificates the signed object is 346 published in the repository publication point of the CA 347 certifificate that issued the EE certificate, and the SIA 348 extension of the single use EE certificate references this object 349 rather than the publication directory[I-D.ietf-sidr-res-certs]. 351 4. Certificate Reissuance and Repositories 353 If a CA certificate is reissued, it should not be necessary to 354 reissue all certificates signed by the certificate being reissued. 355 Therefore, a CA SHOULD use a persistent naming scheme for the 356 certificates's repository publication point that is persistent across 357 certificate reissuance events. That is, reissued certificates should 358 use the same repository publication point as previously issued 359 certificates having the same subject and subject public key, and 360 should overwrite previously issued certificates within the repository 361 publication point directory. 363 5. Synchronising Repositories 365 It is possible to perform the validation-related task of certificate 366 path construction using retrieval of individual certificates and 367 certificate revocation lists using online retrieval of individual 368 certificates, sets of candidate certificates and certificate 369 revocation lists based on the Authority Information Access, Subject 370 Information Access and CRL Distribution Points certificate fields. 371 This is not recommended in circumstances where speed and efficiency 372 are relevant considerations. Where an efficient validation function 373 is required, it is suggested that the relying party maintain a local 374 repository containing a synchronized copy of all valid certificates, 375 current certificate revocation lists, and all related signed objects 376 that are stored in the local instances of components of the overall 377 logical complete certificate repository. 379 The general approach to repository synchronization is one of a "top- 380 down" walk of the distributed repository structure, commencing with 381 the initial configured trust anchor certificates, and then populating 382 the the local repository cache will all valid certificates that have 383 been issued by these issuers, and then recursively applying the same 384 approach to each of these subordinate certificates. Such a 385 repository traveral process would need to support some locally 386 configured maximal chain length from the initial trust anchors to the 387 current working validation point in order to ensure that the process 388 does not follow a loop or a non-terminating certificate chain. 390 6. Security Considerations 392 Repositories are not "protected" structures, and repository retrieval 393 operations are vulnerable to various forms of "man-in-the-middle" 394 attacks. Corruption of retrieved objects is detectable by a relying 395 party through the RPKI validation of the retrieved object. Insertion 396 of older objects is detectable in part by the CRL. However, certain 397 forms of substitution and removal attacks are not directly 398 detectable. For this reason all published RPKI objects are described 399 in a manifest [I-D.ietf-sidr-rpki-manifests]. The manifest can 400 improve the level of assurance that a relying party is receiving an 401 authentic copy of the repository, and that the set of retrieved 402 objects is complete. 404 7. IANA Considerations 406 [There are no IANA considerations in this document.] 408 8. Normative References 410 [I-D.ietf-sidr-res-certs] 411 Huston, G., Loomans, R., and G. Michaelson, "A Profile for 412 X.509 PKIX Resource Certificates", 413 draft-ietf-sidr-res-certs (work in progress), August 2008. 415 [I-D.ietf-sidr-rpki-manifests] 416 Austein, R., Huston, G., Kent, S., and M. Lepinski, 417 "Manifests for the Resource Public Key Infrastructure", 418 draft-ietf-sidr-rpki-manifests (work in progress), 419 August 2008. 421 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 422 Addresses and AS Identifiers", RFC 3779, June 2004. 424 [RFC4387] Gutmann, P., "Internet X.509 Public Key Infrastructure 425 Operational Protocols: Certificate Store Access via HTTP", 426 RFC 4387, February 2006. 428 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 429 Encodings", RFC 4648, October 2006. 431 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 432 Housley, R., and W. Polk, "Internet X.509 Public Key 433 Infrastructure Certificate and Certificate Revocation List 434 (CRL) Profile", RFC 5280, May 2008. 436 [rsync] Tridgell, A., "rsync", April 2006, 437 . 439 Authors' Addresses 441 Geoff Huston 442 Asia Pacific Network Information Centre 444 Email: gih@apnic.net 445 URI: http://www.apnic.net 447 Robert Loomans 448 Asia Pacific Network Information Centre 450 Email: robertl@apnic.net 451 URI: http://www.apnic.net 453 George Michaelson 454 Asia Pacific Network Information Centre 456 Email: ggm@apnic.net 457 URI: http://www.apnic.net 459 Full Copyright Statement 461 Copyright (C) The IETF Trust (2008). 463 This document is subject to the rights, licenses and restrictions 464 contained in BCP 78, and except as set forth therein, the authors 465 retain all their rights. 467 This document and the information contained herein are provided on an 468 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 469 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 470 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 471 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 472 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 473 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 475 Intellectual Property 477 The IETF takes no position regarding the validity or scope of any 478 Intellectual Property Rights or other rights that might be claimed to 479 pertain to the implementation or use of the technology described in 480 this document or the extent to which any license under such rights 481 might or might not be available; nor does it represent that it has 482 made any independent effort to identify any such rights. Information 483 on the procedures with respect to rights in RFC documents can be 484 found in BCP 78 and BCP 79. 486 Copies of IPR disclosures made to the IETF Secretariat and any 487 assurances of licenses to be made available, or the result of an 488 attempt made to obtain a general license or permission for the use of 489 such proprietary rights by implementers or users of this 490 specification can be obtained from the IETF on-line IPR repository at 491 http://www.ietf.org/ipr. 493 The IETF invites any interested party to bring to its attention any 494 copyrights, patents or patent applications, or other proprietary 495 rights that may cover technology that may be required to implement 496 this standard. Please address the information to the IETF at 497 ietf-ipr@ietf.org.