idnits 2.17.00 (12 Aug 2021) /tmp/idnits39509/draft-ietf-sidr-repos-struct-04.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 : ---------------------------------------------------------------------------- ** 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 193: '... MUST maintain a manifest [I-D.sidr-rpki-manifests] of their published...' RFC 2119 keyword, line 201: '... An authority MAY perform a number o...' RFC 2119 keyword, line 204: '...sitory operators SHOULD implement some...' RFC 2119 keyword, line 259: '... proposed in section 5, table 2, of [RFC4648]. A CRL MAY use a...' RFC 2119 keyword, line 270: '...mes. A manifest MAY use a filesystem ...' (7 more instances...) 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 (May 15, 2010) is 4388 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: draft-ietf-sidr-arch has been published as RFC 6480 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'I-D.sidr-arch') == Outdated reference: draft-ietf-sidr-res-certs has been published as RFC 6487 == Outdated reference: draft-ietf-sidr-rpki-manifests has been published as RFC 6486 ** Downref: Normative reference to an Informational RFC: RFC 5781 Summary: 3 errors (**), 0 flaws (~~), 4 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: November 16, 2010 APNIC 6 May 15, 2010 8 A Profile for Resource Certificate Repository Structure 9 draft-ietf-sidr-repos-struct-04.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, the contents of publication point 18 manifests and a suggested internal structure of a local repository 19 cache that is intended to facilitate synchronisation across a 20 distributed collection of repository publication points and 21 facilitate certification path construction. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 16, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. RPKI Repository Publication Point Content and Structure . . . 3 60 2.1. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.2. CA Repository Publication Point . . . . . . . . . . . . . 6 62 2.3. EE Repository Publication Point . . . . . . . . . . . . . 8 63 3. Resource Certificate Publication Repository Considerations . . 9 64 4. Certificate Reissuance and Repositories . . . . . . . . . . . 10 65 5. Synchronising Repositories . . . . . . . . . . . . . . . . . . 10 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 71 1. Introduction 73 To validate attestations made in the context of the Resource Public 74 Key Infrastructure (RPKI) [I-D.sidr-arch] Relying Parties (RPs) need 75 access to all the X.509 / PKIX Resource Certificates, Certificate 76 Revocation Lists (CRLs), and signed objects that collectively define 77 the RPKI. 79 Each issuer of a certificate, CRL or a signed object makes it 80 available for download to RPs through the publication of the object 81 in a RPKI repository. 83 The repository system is the central clearing-house for all signed 84 objects that must be globally accessible to all RPs. When 85 certificates, CRLs and signed objects are created, they are uploaded 86 to a repository publication point, from whence they can be downloaded 87 for use by RPs. 89 This document defines a profile for the structure of RPKI 90 repositories. This profile contains the proposed object naming 91 scheme, the contents of repository publication points, the contents 92 of publication point manifests and a possible internal structure of a 93 Repository Cache that is intended to facilitate synchronisation 94 across a distributed collection of repositories and facilitate 95 certificate path construction. 97 A Resource Certificate describes an attestation by an Issuer that 98 binds a list of IP address blocks and AS numbers to the Subject of a 99 certificate, identified by the unique association of the Subject's 100 private key with the public key contained in the Resource 101 Certificate. 103 1.1. Terminology 105 It is assumed that the reader is familiar with the terms and concepts 106 described in "Internet X.509 Public Key Infrastructure Certificate 107 and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509 108 Extensions for IP Addresses and AS Identifiers" [RFC3779], and 109 related regional Internet registry address management policy 110 documents. 112 2. RPKI Repository Publication Point Content and Structure 114 The RPKI does not use a single repository publication point to 115 publish RPKI objects. Instead, the RPKI repository system is 116 comprised of multiple repository publication points. Each repository 117 publication point is associated with one or more RPKI certificates' 118 publication points, as defined in the certificate's Subject 119 Information Authority (SIA) extension. 121 This section describes the collection of objects (RPKI certificates, 122 CRLs, manifests and signed objects) held in repository publication 123 points. 125 For every certificate in the PKI, there will be a corresponding 126 repository publication point file system directory that is the 127 authoritative publication point for all objects signed by the private 128 key part of the key pair whose public key part is the subject public 129 key of this certificate. 131 Objects are added to the publication point when issued by the 132 associated CA, or when signed by the private key part of a key pair 133 whose subject public key is described in an EE certificate that is 134 associated with the repository publication point, and are removed 135 when expired or revoked. 137 The certificate's Subject Information Authority (SIA) extension 138 provides a URI that references this repository publication point and 139 supported repository access mechanisms. Additionally, a 140 certificate's Authority Information Authority (AIA) extension 141 contains a URI that references the authoritative location for the 142 Certification Authority (CA) certificate under which the given 143 certificate was issued. That is, if the subject of certificate A has 144 issued certificate B, then the AIA extension of certificate B points 145 to certificate A, and the SIA extension of certificate A points to a 146 repository publication point file system directory containing 147 certificate B (see Figure 1). 149 +--------+ 150 +--------->| Cert A |<----+ 151 | | CRLDP | | 152 | | AIA | | 153 | +--------- SIA | | 154 | | +--------+ | 155 | | | 156 | | | 157 | | | 158 | | +-------------------|------------------+ 159 | | | | | 160 | +->| +--------+ | +--------+ | 161 | | | Cert B | | | Cert C | | 162 | | | CRLDP ----+ | | CRLDP -+-+ | 163 +----------- AIA | | +----- AIA | | | 164 | | SIA | | | SIA | | | 165 | +--------+ | +--------+ | | 166 | V | | 167 | +---------+ | | 168 | | A's CRL |<-----------+ | 169 | +---------+ | 170 | A's Repository Publication Directory | 171 +--------------------------------------+ 173 Figure 1: Example Repository Structure. 175 In the example shown in Figure 1, certificates B and C are issued by 176 CA A. Therefore, the AIA extensions of certificates B and C point to 177 the object publication point where Certificate A is published, and 178 the SIA extension of certificate A points to the repository 179 publication point of CA A's subordinate products, including 180 certificates B and C, as well as A's CRL. 182 The general intent of this distributed repository structure is that 183 an instance of a CA's repository publication point contains all the 184 signed products of that CA, and an End Entity's (EE's) repository 185 publication point contains all the objects that have been signed by 186 the private key part of a key pair whose public key is described in 187 the subject public key of the associated EE certificate. 189 2.1. Manifests 191 All CA's and all EE's that have repository publication points 192 ("multi-use" EE certificates, as defined in [I-D.sidr-res-certs]) 193 MUST maintain a manifest [I-D.sidr-rpki-manifests] of their published 194 subordinate products. The manifest contains a list of the names of 195 all objects issued by that CA, or signed by the private key part of a 196 key pair whose public key is the subject public key of the associated 197 EE certificate, and published in a repository publication point file 198 system directory, as well as the hash value of each object's 199 contents. 201 An authority MAY perform a number of object operations on a 202 publication repository within the scope of a repository change before 203 issuing a single manifest that covers all the operations within the 204 scope of this change. Repository operators SHOULD implement some 205 form of synchronisation function on the repository to ensure that 206 relying parties who are performing retrieval operations on the 207 repository are not exposed to intermediate states during changes to 208 the repository and the associated manifest. 210 2.2. CA Repository Publication Point 212 A CA Certificate has two accessMethod elements specified in its SIA 213 field. The id-ad-caRepository accessMethod element has an associated 214 accessLocation element that points to the repository publication 215 point of the products of this CA, as specified in 216 [I-D.sidr-res-certs]. The id-ad-rpkiManifest accessMethod element 217 has an associated accessLocation element that points to the manifest 218 object, as an object URL, that is associated with this CA. 220 In the case of a CA's publication repository in the scope of the 221 RPKI, the repository contains the current unrevoked certificates 222 issued by this CA, the most recent CRL that is associated with the 223 CA's non-revoked key pairs, the current unrevoked manifest, and all 224 current objects that are signed using the private key of a key pair 225 whose public key is the subject public key of a current unrevoked 226 "single-use" EE certificate, where the EE certificate was issued by 227 this CA. 229 The CA's manifest describes all the current unrevoked objects that 230 are to be found in that publication point that were issued by this 231 CA, and all published objects signed using the private key of a key 232 pair whose public key is the subject public key of a current 233 unrevoked "single-use" EE certificate that has been issued by this 234 CA, and the hash value of each object (excluding the manifest itself) 235 [I-D.sidr-rpki-manifests]. 237 Because an instance of a CA is associated with a single key pair, an 238 entity performs the equivalent of a key rollover operation by 239 generating a new CA instance as well as a new key pair. In such 240 cases the entity may chose to continue the use of a single repository 241 publication point for both CA instances. In such cases the 242 repository publication point will contain the CRL, manifest, 243 subordinate certificates and signed objects of both CA instances. 245 Some guidelines for naming objects in a CA's repository publication 246 point are as follows: 248 CRL: The scope of a CRL in the RPKI is all objects issued by a CA, 249 implying that publication of successive instances of a CA's CRL 250 should overwrite previous instances of CRLs signed by the same 251 CA's private key in the publication repository. It is consistent 252 with this objective that the name chosen for the CRL in the 253 publication repository be a value derived from the public key part 254 of the CA's key pair whose private key was used to sign the CRL. 255 One such method of generating a CRL publication name is described 256 in section 2.1 of [RFC4387], converting the 160-bit hash of the 257 CA's public key value into a 27-character string using a modified 258 form of Base64 encoding, with an additional modification as 259 proposed in section 5, table 2, of [RFC4648]. A CRL MAY use a 260 filesystem name extension of ".crl" to denote the object as a CRL. 262 Manifest: When a new instance of a manifest is published by the CA, 263 there is no requirement within the RPKI for any RP to have 264 continuing access to older instances of the CA's manifest. When 265 multiple CA's share a common repository publication point their 266 respective manifests must be distinct. It is consistent with this 267 objective that the name chosen for the manifest in the publication 268 repository be a value derived from the public key part of the CA's 269 key pair, using the algorithm described above for CRL object 270 names. A manifest MAY use a filesystem name extension of ".mft" 271 to denote the object as a manifest. 273 Certificates: Within the RPKI framework it is possible that a CA may 274 issue a series of certificates for the same subject name, the same 275 subject public key, and the same resource collection. Within the 276 context of each such series of certificates a RP has an interest 277 only in the most recently published current certificate. The 278 publication repository object name scheme for the CA may use a 279 unique name for each such series of certificates, thereby ensuring 280 that each successive issued certificate in such a series 281 effectively overwrites the previous instance of the certificate in 282 the publication repository. If the CA adopts a local policy that 283 each subject uses a unique key pair for each unique instance of a 284 certified resource collection then the CA can use a certificate 285 object name scheme that is derived from the subject's public key, 286 applying the algorithm described above for CRL object names to the 287 subject's public key value. A certificate MAY use a filesystem 288 name extension of ".cer" to denote the object as a certificate. 290 Signed Objects: Within the RPKI framework there are two kinds of EE 291 certificates that are used in conjunction with digital 292 certificates: "single-use" EE certificates, where the private key 293 of the key pair whose public key is the subject public key of the 294 EE certificate is used to sign a single object, and "multi-use" EE 295 Certificates, whose private key of the key pair whose public key 296 is the subject public key of the EE certificate may be used to 297 sign multiple objects. In the case of "single-use" EE 298 certificates, the single signed object is to be published in the 299 same repository publication point as the associated EE 300 certificate. The signed object name scheme for such objects can 301 be derived from the associated EE certificate's subject public 302 key, applying the algorithm described above for CRL object names 303 to the EE certificates's subject public key value. The signed 304 object is listed in the manifest associated with this repository 305 publication point. In the case of "multi-use" EE certificates the 306 repository publication point is described in the following 307 section. 309 2.3. EE Repository Publication Point 311 EE repository publication points are used in conjunction with "multi- 312 use" EE Certificates. In this case the EE Certificate has two 313 accessMethod elements specified in its SIA field. The id-ad- 314 signedObjectRepository accessMethod element has an associated 315 accessLocation element that points to the repository publication 316 point of the objects signed by the private key of a key pair whose 317 public key is the subject public key of this EE certificate, as 318 specified in [I-D.sidr-res-certs]. The id-ad-rpkiManifest 319 accessMethod element has an associated accessLocation element that 320 points to the manifest object as an object URL, that is associated 321 with this repository publication point. This manifest describes all 322 the signed objects that are to be found in that publication point 323 that have been signed by the private key of a key pair whose public 324 key is the subject public key of this EE certificate, and the hash 325 value of each product (excluding the manifest itself) 326 [I-D.sidr-rpki-manifests]. 328 In the case of an EE's publication repository in the scope of the 329 RPKI, the repository contains objects that have been signed by the 330 private key of the key pair whose public key is the subject public 331 key of the EE certificate, and a manifest of all such signed objects. 333 The objects published in a EE repository publication point do not 334 form a logical sequence, and must be named uniquely in the context of 335 the publication repository. 337 It is consistent with this specification, but not recommended 338 practice, that all subordinate EE's of a given CA share a common 339 publication repository. In this case the repository publication 340 point would contain multiple manifest objects, one for each EE that 341 has placed objects into this common publication point. Each manifest 342 is limited in scope to listing the objects signed by the EE 343 certificate. The implication is that all objects signed by the 344 private key of a key pair whose public key is the subject key of a 345 single EE certificate, including the EE's manifest, share a base name 346 element that is generated from the public key of the EE certificate. 347 The choice of whether to use a common single publication repository 348 or a dedicated publication repository for each EE certificate is an 349 implementation choice. 351 3. Resource Certificate Publication Repository Considerations 353 Each issuer may publish their issued certificates and CRL in any 354 location of their choice. However, there are a number of 355 considerations which guide the choice of a suitable repository 356 publication structure. 358 o The publication repository SHOULD be hosted on a highly available 359 service and high capacity publication platform. 361 o The publication repository MUST be available using RSYNC 362 [RFC5781][I-D.sidr-res-certs] Support of additional retrieval 363 mechanisms is the choice of the repository operator. The 364 supported retrieval mechanisms should be consistent with the 365 accessMethod element value(s) specified in the SIA of the 366 associated CA or EE. 368 o Each CA repository publication point file system directory in the 369 publication repository should contain the products of this CA, 370 including those objects signed by single-use EE certificates that 371 have been issued by this CA. The signed products of related CA's 372 that are operated by the same entity may share the CA repository 373 publication point file system directory. Aside from 374 subdirectories, no other objects should be placed in a repository 375 publication point file system directory. 377 Any such subdirectory should be the repository publication point 378 file system directory of a CA or EE certificate that is contained 379 in the CA's repository publication point file system directory. 380 There are no constraints on the name of a repository publication 381 point file system subdirectory. These considerations also apply 382 recursively to subdirectories of these repository publication 383 point file system subdirectories directories. 385 o Signed Objects are published in the location indicated by the SIA 386 field of the EE certificate that has certified the public key part 387 of the key pair whose private key part was used to sign the 388 object. The choice of the repository publication point is 389 determined by the nature of the signing EE certificate. In the 390 case of "multi-use" EE certificates the signed object is published 391 in an EE repository publication point as referenced by the SIA 392 extension of the EE certificate. In the case of "single-use" EE 393 certificates the signed object is published in the repository 394 publication point of the CA certificate that issued the EE 395 certificate, and the SIA extension of the single use EE 396 certificate references this object rather than the repository 397 publication point file system directory[I-D.sidr-res-certs]. 399 4. Certificate Reissuance and Repositories 401 If a CA certificate is reissued, it should not be necessary to 402 reissue all certificates signed by the certificate being reissued. 403 Therefore, a CA SHOULD use a persistent naming scheme for the 404 certificate's repository publication point that is persistent across 405 certificate re-issuance events. That is, reissued certificates 406 SHOULD use the same repository publication point as previously issued 407 certificates having the same subject and subject public key, and 408 SHOULD overwrite previously issued certificates within the repository 409 publication point file system directory. 411 5. Synchronising Repositories 413 It is possible to perform the validation-related task of certificate 414 path construction using retrieval of individual certificates and 415 certificate revocation lists using online retrieval of individual 416 certificates, sets of candidate certificates and certificate 417 revocation lists based on the Authority Information Access, Subject 418 Information Access and CRL Distribution Points certificate fields. 419 This is not recommended in circumstances where speed and efficiency 420 are relevant considerations. Where an efficient validation operation 421 is required, it is RP MAY maintain a local repository containing a 422 synchronised copy of all current valid certificates, current 423 certificate revocation lists, and all related signed objects, 424 maintained as a local current copy of the complete distributed RPKI 425 repository collection. 427 The general approach to repository synchronisation is one of a "top- 428 down" walk of the distributed repository structure, commencing with 429 the initial configured trust anchor certificates, and then populating 430 the local repository cache will all valid certificates that have been 431 issued by these issuers, and then recursively applying the same 432 approach to each of these subordinate certificates. Such a 433 repository traversal process would need to support some locally 434 configured maximal chain length from the initial trust anchors to the 435 current working validation point in order to ensure that the process 436 does not follow a loop or a non-terminating certificate chain. 438 6. Security Considerations 440 Repositories are not "protected" structures, and repository retrieval 441 operations are vulnerable to various forms of "man-in-the-middle" 442 attacks. Corruption of retrieved objects is detectable by a RP 443 through the RPKI validation of the retrieved object. Insertion of 444 older objects is detectable by the CRL, assuming that the older 445 object has been revoked by the issuer. However, certain forms of 446 substitution and removal attacks are not directly detectable. For 447 this reason all published RPKI objects are described in a manifest 448 [I-D.sidr-rpki-manifests]. The manifest can improve the level of 449 assurance that a RP is receiving an authentic copy of the repository, 450 and that the set of retrieved objects is complete. 452 7. IANA Considerations 454 [There are no IANA considerations in this document.] 456 8. Normative References 458 [I-D.sidr-arch] 459 Lepinski, M. and S. Kent, "An Infrastructure to Support 460 Secure Internet Routing", draft-ietf-sidr-arch-08.txt 461 (work in progress), July 2009. 463 [I-D.sidr-res-certs] 464 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 465 X.509 PKIX Resource Certificates", 466 draft-ietf-sidr-res-certs-16.txt (work in progress), 467 February 2008. 469 [I-D.sidr-rpki-manifests] 470 Austein, R., Huston, G., Kent, S., and M. Lepinski, 471 "Manifests for the Resource Public Key Infrastructure", 472 draft-ietf-sidr-rpki-manifests (work in progress), 473 August 2009. 475 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 476 Addresses and AS Identifiers", RFC 3779, June 2004. 478 [RFC4387] Gutmann, P., "Internet X.509 Public Key Infrastructure 479 Operational Protocols: Certificate Store Access via HTTP", 480 RFC 4387, February 2006. 482 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 483 Encodings", RFC 4648, October 2006. 485 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 486 Housley, R., and W. Polk, "Internet X.509 Public Key 487 Infrastructure Certificate and Certificate Revocation List 488 (CRL) Profile", RFC 5280, May 2008. 490 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 491 Scheme", RFC 5781, February 2010. 493 Authors' Addresses 495 Geoff Huston 496 Asia Pacific Network Information Centre 498 Email: gih@apnic.net 499 URI: http://www.apnic.net 501 Robert Loomans 502 Asia Pacific Network Information Centre 504 Email: robertl@apnic.net 505 URI: http://www.apnic.net 507 George Michaelson 508 Asia Pacific Network Information Centre 510 Email: ggm@apnic.net 511 URI: http://www.apnic.net