idnits 2.17.1 draft-ietf-sidr-repos-struct-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 181: '... MUST maintain a manifest [I-D.sidr-rpki-manifests] of their published...' RFC 2119 keyword, line 325: '...ation repository MUST be available usi...' RFC 2119 keyword, line 362: '... Therefore, a CA SHOULD use a persiste...' 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 (August 4, 2009) is 5378 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-08 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'I-D.sidr-arch') == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-16 Summary: 3 errors (**), 0 flaws (~~), 3 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: February 5, 2010 APNIC 6 August 4, 2009 8 A Profile for Resource Certificate Repository Structure 9 draft-ietf-sidr-repos-struct-03.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on February 5, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document defines a profile for the structure of repository 48 publication points that contain X.509 / PKIX Resource Certificates, 49 Certificate Revocation Lists and signed objects. This profile 50 contains the proposed object naming scheme, the contents of 51 repository publication points, the contents of publication point 52 manifests and a suggested internal structure of a local repository 53 cache that is intended to facilitate synchronization across a 54 distributed collection of repository publication points and 55 facilitate certification path construction. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. RPKI Repository Publication Point Content and Structure . . . 3 62 2.1. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2. CA Repository Publication Point . . . . . . . . . . . . . 5 64 2.3. EE Repository Publication Point . . . . . . . . . . . . . 7 65 3. Resource Certificate Publication Repository Considerations . . 8 66 4. Certificate Reissuance and Repositories . . . . . . . . . . . 9 67 5. Synchronising Repositories . . . . . . . . . . . . . . . . . . 9 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 To validate attestations made in the context of the Resource Public 76 Key Infrastructure (RPKI) [I-D.sidr-arch] relying parties need access 77 to all the X.509 / PKIX Resource Certificates, Certificate Revocation 78 Lists (CRLs), and signed objects that collectively define the RPKI. 80 Each issuer of a certificate, CRL or a signed object makes it 81 available for download to replying parties through the publication of 82 the object in a RPKI repository. 84 The repository system is the central clearing-house for all signed 85 objects that must be globally accessible to relying parties. 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 relying parties. 90 This document defines a profile for the structure of RPKI 91 repositories. This profile contains the proposed object naming 92 scheme, the contents of repository publication points, the contents 93 of publication point manifests and a possible internal structure of a 94 Repository Cache that is intended to facilitate synchronization 95 across a distributed collection of repositories and facilitate 96 certificate path construction. 98 A Resource Certificate describes an action by an Issuer that binds a 99 list of IP address blocks and AS numbers to the Subject of a 100 certificate, identified by the unique association of the Subject's 101 private key with the public key contained in the Resource 102 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], "X.509 109 Extensions for IP Addresses and AS Identifiers" [RFC3779], and 110 related regional Internet registry address management policy 111 documents. 113 2. RPKI Repository Publication Point Content and Structure 115 The RPKI does not use a single repository publication point to 116 publish RPKI objects. Instead, the RPKI repository system is 117 comprised of multiple repository publication points. Each repository 118 publication point is associated with one or more RPKI certificates' 119 publication points, as defined in the certificate's Subject 120 Information Authority (SIA) extension. 122 This section describes the collection of objects (RPKI certificates, 123 CRLs, manifests and signed objects) held in repository publication 124 points. 126 For every certificate in the PKI, there will be a corresponding 127 repository publication point file system directory that is the 128 authoritative publication point for all objects signed by the private 129 key part of the key pair whose public key part is the subject of this 130 certificate, or all objects verifiable via this certificate. The 131 certificate's Subject Information Authority (SIA) extension provides 132 a URI that references this repository publication point and supported 133 repository access mechanisms. Additionally, a certificate's 134 Authority Information Authority (AIA) extension contains a URI that 135 references the authoritative location for the Certification Authority 136 (CA) certificate under which the given certificate was issued. That 137 is, if the subject of certificate A has issued certificate B, then 138 the AIA extension of certificate B points to certificate A, and the 139 SIA extension of certificate A points to a directory containing 140 certificate B (see Figure 1). 142 +--------+ 143 +--------->| Cert A |<----+ 144 | | CRLDP | | 145 | | AIA | | 146 | +--------- SIA | | 147 | | +--------+ | 148 | | | 149 | | | 150 | | | 151 | | +-------------------|------------------+ 152 | | | | | 153 | +->| +--------+ | +--------+ | 154 | | | Cert B | | | Cert C | | 155 | | | CRLDP ----+ | | CRLDP -+-+ | 156 +----------- AIA | | +----- AIA | | | 157 | | SIA | | | SIA | | | 158 | +--------+ | +--------+ | | 159 | V | | 160 | +---------+ | | 161 | | A's CRL |<-----------+ | 162 | +---------+ | 163 | A's Repository Publication Directory | 164 +--------------------------------------+ 166 Figure 1: In this example, certificates B and C are issued under 167 certificate A. Therefore, the AIA extensions of certificates B and C 168 point to A, and the SIA extension of certificate A points to the 169 repository publication point containing certificates B and C, as well 170 as A'a CRL. 172 The general intent of this profile is that an instance of a CA's 173 repository publication point contains all the signed products of the 174 CA, and an End Entity's (EE's) repository publication point contains 175 all the objects signed by the EE. 177 2.1. Manifests 179 All CA's and all EE's that have repository publication points 180 ("multi-use" EE certificates, as defined in [I-D.sidr-res-certs]) 181 MUST maintain a manifest [I-D.sidr-rpki-manifests] of their published 182 subordinate products. The manifest contains a list of the names of 183 all objects issued by that CA or signed by the EE certificate and 184 published in a repository publication point directory, as well as the 185 hash value of each object's contents. 187 The collection of manifests across the entire RPKI is "complete set", 188 in that all current valid published objects are described in 189 precisely one manifest. 191 2.2. CA Repository Publication Point 193 A CA Certificate has two accessMethods specified in its SIA field. 194 The id-ad-caRepository accessMethod has an associated accessLocation 195 that points to the the repository publication point of the products 196 of this CA, as specified in [I-D.sidr-res-certs]. The id-ad- 197 rpkiManifest accessMethod has an associated access location that 198 points to the manifest object, as an object URL, that is associated 199 with this CA. 201 In the case of a CA's publication repository in the scope of the 202 RPKI, the repository contains the current certificates issued by this 203 CA, the most recent CRLs that are associated with the CA's non- 204 revoked keypairs, the current manifest, and all objects that are 205 signed using a "single-use" EE certificate, where the EE certificate 206 was issued by this CA. 208 The CA's manifest describes all the objects that are to be found in 209 that publication point that were issued by this CA, and all published 210 objects signed by "single-use" EE certificates that have been issued 211 by this CA, and the hash value of each object (excluding the manifest 212 itself) [I-D.sidr-rpki-manifests]. 214 Becuase a CA is associated with a single key pair an entity performss 215 the equivalent of a key rollover operation by generating a new CA 216 instance as well as a new key pair. In such cases the entity may 217 chose to continue of use a single repository publication point for 218 both CA instances. In such cases the repository publication pooint 219 will contain the CRL, manifest and subordinate certificates of both 220 CA instances. 222 Some guidelines for naming objects in a CA's repository publication 223 point are as follows: 225 CRL: The scope of a CRL in the RPKI is all objects issued by a CA, 226 implying that publication of successive instances of a CA's CRL 227 may overwrite previous instances of CRLs signed by the same CA's 228 private key in the publication repository. It is consistent with 229 this objective that the name chosen for the CRL in the publication 230 repository be a value derived from the public key part of the CA's 231 key pair that was used to sign the CRL. One such method of 232 generating a CRL publication name is described in section 2.1 of 233 [RFC4387], converting the 160-bit hash of the CA's public key 234 value into a 27-character string using a modified form of Base64 235 encoding, with an additional modification as proposed in section 236 5, table 2, of [RFC4648]. 238 Manifest: When a new instance of a manifest is published by the CA, 239 there is no requirement within the RPKI for any relying party to 240 have continuing access to older instances of the CA's manifest. 241 Whn multiple CA's share a common repository publication point 242 their respective manifests must be distinct. It is consistent 243 with this objective that the name chosen for the manifest in the 244 publication repository be a value derived from the public key part 245 of the CA's key pair, using the algorithm described above for CRL 246 object names. 248 Certificates: Within the RPKI framework it is possible that a CA may 249 issue a series of certificates for the same subject name, the same 250 subject public key, and the same resource collection. Within the 251 context of each such series of certificates a relying party has an 252 interest only in the most recently published certificate. The 253 publication repository object name scheme for the CA may use a 254 unique name for each such series of certificates, thereby ensuring 255 that each successive issued certificate in such a series 256 effectively overwrites the previous instance of the certificate 257 series in the publication repository. If the CA adopts a local 258 policy that each subject uses a unique key pair for each unique 259 instance of a certified resource collection then the CA can use a 260 certificate object name scheme that is derived from the subject's 261 public key, applying the algorithm described above for CRL object 262 names to the subject's public key value. 264 Signed Objects: Within the RPKI framework there are two kinds of EE 265 certificates that are used in conjunction with digital 266 certificates: "single-use" EE certificates that are used to sign a 267 single object, and "multi-use" EE Certificates that may be used to 268 sign multiple objects. In the case of "single-use" EE 269 certificates, the single signed object is to be published in the 270 same repository publication point as the EE certificate that was 271 used to sign the object. The signed object name scheme for such 272 objects can be derived from the associated EE certificate's public 273 key, applying the algorithm described above. The signed object is 274 listed in the manifest associated with this repository publication 275 point. In the case of "multi-use" EE certificates the repository 276 publication point is described in the following section. 278 2.3. EE Repository Publication Point 280 EE repository publication points are used in conjunction with "multi- 281 use" EE Certificates. In this case the EE Certificate has two 282 accessMethods specified in its SIA field. The id-ad- 283 signedObjectRepository accessMethod has an associated accessLocation 284 that points to the the repository publication point of the objects 285 signed by this EE certificate, as specified in [I-D.sidr-res-certs]. 286 The id-ad-rpkiManifest accessMethod has an associated access location 287 that points to the manifest object as an object URL, that is 288 associated with this repository publication point. This manifest 289 describes all the signed objects that are to be found in that 290 publication point that have been signed by this EE certificate, and 291 the hash value of each product (excluding the manifest itself) 292 [I-D.sidr-rpki-manifests]. 294 In the case of a EE's publication repository in the scope of the 295 RPKI, the repository contains objects that have been signed by the 296 EE's key pair, and a manifest of all such signed objects. 298 The objects published in a EE repository publication point do not 299 form a logical sequence, and must be named uniquely in the context of 300 the publication repository. 302 It is consistent with this specification, but not recommended 303 practice, that all subordinate EE certificates of a given CA share a 304 common publication repository. In this case the repository 305 publication point would contain multiple manifest objects, one for 306 each EE certificate that has placed objects into this common 307 publication point. Each manifest is limited in scope to listing the 308 objects signed by the EE certificate. The implication is that all 309 objects signed by a single EE certificate, including the EE's 310 manifest, share a base name element that is generated from the public 311 key of the EE certificate. The choice of whether to use a common 312 single publication repository or a dedicated publication repository 313 for each EE certificate is an implementation choice. 315 3. Resource Certificate Publication Repository Considerations 317 Each issuer may publish their issued certificates and CRL in any 318 location of their choice. However, there are a number of 319 considerations which guide the choice of a suitable repository 320 publication structure. 322 o The publication repository should be hosted on a highly available 323 service and high capacity publication platform. 325 o The publication repository MUST be available using RSYNC 326 [rsync][I-D.sidr-res-certs] Support of additional retrieval 327 methods is the choice of the repository operator. The supported 328 access methods should be consistent with the access methods as 329 specified in the SIA of the associated CA or EE. 331 o Each CA publication directory in the publication repository should 332 contain the products of this CA, including those objects signed by 333 single-use EE certificates that have been issued by this CA. The 334 signed products of related CA's that are operated by the same 335 entity may share the CA publication directory. Aside from 336 subdirectories, no other objects should be placed in a publication 337 repository directory. 339 Any such subdirectory should be the repository publication point 340 of a CA or EE certificate that is contained in the CA directory. 341 There are no constraints on the name of a subdirectory. These 342 considerations also apply recursively to subdirectories of these 343 directories. 345 o Signed Objects are published in the location indicated by the SIA 346 field of the EE certificate that has certified the key pair that 347 was used to sign the object. The choice of the repository 348 publication point is determined by the nature of the signing EE 349 certificate. In the case of "multi-use" EE certificates the 350 signed object is published in an EE repository publication point 351 as referenced by the SIA extension of the EE certificate. In the 352 case of "single-use" EE certificates the signed object is 353 published in the repository publication point of the CA 354 certifificate that issued the EE certificate, and the SIA 355 extension of the single use EE certificate references this object 356 rather than the publication directory[I-D.sidr-res-certs]. 358 4. Certificate Reissuance and Repositories 360 If a CA certificate is reissued, it should not be necessary to 361 reissue all certificates signed by the certificate being reissued. 362 Therefore, a CA SHOULD use a persistent naming scheme for the 363 certificates's repository publication point that is persistent across 364 certificate reissuance events. That is, reissued certificates should 365 use the same repository publication point as previously issued 366 certificates having the same subject and subject public key, and 367 should overwrite previously issued certificates within the repository 368 publication point directory. 370 5. Synchronising Repositories 372 It is possible to perform the validation-related task of certificate 373 path construction using retrieval of individual certificates and 374 certificate revocation lists using online retrieval of individual 375 certificates, sets of candidate certificates and certificate 376 revocation lists based on the Authority Information Access, Subject 377 Information Access and CRL Distribution Points certificate fields. 378 This is not recommended in circumstances where speed and efficiency 379 are relevant considerations. Where an efficient validation function 380 is required, it is suggested that the relying party maintain a local 381 repository containing a synchronized copy of all valid certificates, 382 current certificate revocation lists, and all related signed objects 383 that are stored in the local instances of components of the overall 384 logical complete certificate repository. 386 The general approach to repository synchronization is one of a "top- 387 down" walk of the distributed repository structure, commencing with 388 the initial configured trust anchor certificates, and then populating 389 the the local repository cache will all valid certificates that have 390 been issued by these issuers, and then recursively applying the same 391 approach to each of these subordinate certificates. Such a 392 repository traveral process would need to support some locally 393 configured maximal chain length from the initial trust anchors to the 394 current working validation point in order to ensure that the process 395 does not follow a loop or a non-terminating certificate chain. 397 6. Security Considerations 399 Repositories are not "protected" structures, and repository retrieval 400 operations are vulnerable to various forms of "man-in-the-middle" 401 attacks. Corruption of retrieved objects is detectable by a relying 402 party through the RPKI validation of the retrieved object. Insertion 403 of older objects is detectable in part by the CRL. However, certain 404 forms of substitution and removal attacks are not directly 405 detectable. For this reason all published RPKI objects are described 406 in a manifest [I-D.sidr-rpki-manifests]. The manifest can improve 407 the level of assurance that a relying party is receiving an authentic 408 copy of the repository, and that the set of retrieved objects is 409 complete. 411 7. IANA Considerations 413 [There are no IANA considerations in this document.] 415 8. Normative References 417 [I-D.sidr-arch] 418 Lepinski, M. and S. Kent, "An Infrastructure to Support 419 Secure Internet Routing", draft-ietf-sidr-arch-08.txt 420 (work in progress), July 2009. 422 [I-D.sidr-res-certs] 423 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 424 X.509 PKIX Resource Certificates", 425 draft-ietf-sidr-res-certs-16.txt (work in progress), 426 February 2008. 428 [I-D.sidr-rpki-manifests] 429 Austein, R., Huston, G., Kent, S., and M. Lepinski, 430 "Manifests for the Resource Public Key Infrastructure", 431 draft-ietf-sidr-rpki-manifests (work in progress), 432 August 2009. 434 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 435 Addresses and AS Identifiers", RFC 3779, June 2004. 437 [RFC4387] Gutmann, P., "Internet X.509 Public Key Infrastructure 438 Operational Protocols: Certificate Store Access via HTTP", 439 RFC 4387, February 2006. 441 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 442 Encodings", RFC 4648, October 2006. 444 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 445 Housley, R., and W. Polk, "Internet X.509 Public Key 446 Infrastructure Certificate and Certificate Revocation List 447 (CRL) Profile", RFC 5280, May 2008. 449 [rsync] Tridgell, A., "rsync", April 2006, 450 . 452 Authors' Addresses 454 Geoff Huston 455 Asia Pacific Network Information Centre 457 Email: gih@apnic.net 458 URI: http://www.apnic.net 460 Robert Loomans 461 Asia Pacific Network Information Centre 463 Email: robertl@apnic.net 464 URI: http://www.apnic.net 466 George Michaelson 467 Asia Pacific Network Information Centre 469 Email: ggm@apnic.net 470 URI: http://www.apnic.net