idnits 2.17.1 draft-ietf-sidr-cp-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 3, 2010) is 4891 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) == Missing Reference: 'RFC5736' is mentioned on line 316, but not defined ** Obsolete undefined reference: RFC 5736 (Obsoleted by RFC 6890) -- Possible downref: Non-RFC (?) normative reference: ref. 'ARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCwwww' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCxxxx' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCyyyy' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCzzzz' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Secure Inter-Domain Routing (sidr) Kent, S. 2 Internet Draft Kong, D. 3 Expires: June 2011 Seo, K. 4 Intended Status: Best Current Practice Watro, R. 5 BBN Technologies 6 December 3, 2010 8 Certificate Policy (CP) 9 for the Resource PKI (RPKI 10 draft-ietf-sidr-cp-16.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on June 30, 2011. 35 Abstract 37 This document describes the certificate policy for a Public Key 38 Infrastructure (PKI) used to support attestations about Internet 39 resource holdings. Each organization that distributes IP addresses 40 or Autonomous System (AS) numbers to an organization will, in 41 parallel, issue a certificate reflecting this distribution. These 42 certificates will enable verification that the resources indicated 43 in the certificate have been distributed to the holder of the 44 associated private key and that this organization is the current, 45 unique holder of these resources. 47 Table of Contents 49 1. Introduction...................................................7 50 1.1. Overview..................................................8 51 1.2. Document name and identification..........................8 52 1.3. PKI participants..........................................8 53 1.3.1. Certification authorities............................9 54 1.3.2. Registration authorities.............................9 55 1.3.3. Subscribers..........................................9 56 1.3.4. Relying parties......................................9 57 1.3.5. Other participants...................................9 58 1.4. Certificate usage........................................10 59 1.4.1. Appropriate certificate uses........................10 60 1.4.2. Prohibited certificate uses.........................10 61 1.5. Policy administration....................................10 62 1.5.1. Organization administering the document.............10 63 1.5.2. Contact person......................................10 64 1.5.4. CP approval procedures..............................10 65 1.6. Definitions and acronyms.................................11 67 2. Publication And Repository Responsibilities...................13 68 2.1. Repositories.............................................13 69 2.2. Publication of certification information.................13 70 2.3. Time or frequency of publication.........................13 71 2.4. Access controls on repositories..........................14 73 3. Identification and Authentication.............................15 74 3.1. Naming...................................................15 75 3.1.1. Types of names......................................15 76 3.1.2. Need for names to be meaningful.....................15 77 3.1.3. Anonymity or pseudonymity of subscribers............15 78 3.1.4. Rules for interpreting various name forms...........15 79 3.1.5. Uniqueness of names.................................15 80 3.2. Initial identity validation..............................16 81 3.2.1. Method to prove possession of private key...........16 82 3.2.2. Authentication of organization identity.............16 83 3.2.3. Authentication of individual identity...............16 84 3.2.4. Non-verified subscriber information.................16 85 3.2.5. Validation of authority.............................16 86 3.2.6. Criteria for interoperation.........................17 88 3.3. Identification and authentication for re-key requests....17 89 3.3.1. Identification and authentication for routine 90 re-key.............................................17 91 3.3.2. Identification and authentication for re-key 92 after revocation...................................17 93 3.4. Identification and authentication for revocation 94 request.................................................17 96 4. Certificate Life-Cycle Operational Requirements...............19 97 4.1. Certificate Application..................................19 98 4.1.1. Who can submit a certificate application............19 99 4.1.2. Enrollment process and responsibilities.............19 100 4.2. Certificate application processing.......................19 101 4.2.1. Performing identification and authentication 102 functions..........................................19 103 4.2.2. Approval or rejection of certificate 104 applications.......................................19 105 4.2.3. Time to process certificate applications............20 106 4.3. Certificate issuance.....................................20 107 4.3.1. CA actions during certificate issuance..............20 108 4.3.2. Notification to subscriber by the CA of issuance 109 of certificate.....................................20 110 4.4. Certificate acceptance...................................20 111 4.4.1. Conduct constituting certificate acceptance.........20 112 4.4.2. Publication of the certificate by the CA............20 113 4.4.3. Notification of certificate issuance by the CA 114 to other entities..................................20 115 4.5. Key pair and certificate usage...........................21 116 4.5.1. Subscriber private key and certificate usage........21 117 4.5.2. Relying party public key and certificate usage......21 118 4.6. Certificate renewal......................................21 119 4.6.1. Circumstance for certificate renewal................22 120 4.6.2. Who may request renewal.............................22 121 4.6.3. Processing certificate renewal requests.............22 122 4.6.4. Notification of new certificate issuance to 123 subscriber.........................................22 124 4.6.5. Conduct constituting acceptance of a renewal 125 certificate........................................22 126 4.6.6. Publication of the renewal certificate by the CA....23 127 4.6.7. Notification of certificate issuance by the CA 128 to other entities..................................23 129 4.7. Certificate re-key.......................................23 130 4.7.1. Circumstance for certificate re-key.................23 131 4.7.2. Who may request certification of a new public 132 key................................................23 133 4.7.3. Processing certificate re-keying requests...........24 134 4.7.4. Notification of new certificate issuance to 135 subscriber.........................................24 136 4.7.5. Conduct constituting acceptance of a re-keyed 137 certificate........................................24 138 4.7.6. Publication of the re-keyed certificate by the 139 CA.................................................24 140 4.7.7. Notification of certificate issuance by the CA 141 to other entities..................................24 142 4.8. Certificate modification.................................24 143 4.8.1. Circumstance for certificate modification...........24 144 4.8.2. Who may request certificate modification............24 145 4.8.3. Processing certificate modification requests........25 146 4.8.4. Notification of new certificate issuance to 147 subscriber.........................................25 148 4.8.5. Conduct constituting acceptance of modified 149 certificate........................................25 150 4.8.6. Publication of the modified certificate by the 151 CA.................................................25 152 4.8.7. Notification of certificate issuance by the CA 153 to other entities..................................25 154 4.9. Certificate revocation and suspension....................25 155 4.9.1. Circumstances for revocation........................25 156 4.9.2. Who can request revocation..........................25 157 4.9.3. Procedure for revocation request....................25 158 4.9.4. Revocation request grace period.....................26 159 4.9.5. Time within which CA must process the revocation 160 request............................................26 161 4.9.6. Revocation checking requirement for relying 162 parties............................................26 163 4.9.7. CRL issuance frequency..............................26 164 4.9.8. Maximum latency for CRLs............................26 165 4.10. Certificate status services.............................26 167 5. Facility, Management, And Operational Controls................28 168 5.1. Physical controls........................................28 169 5.1.1. Site location and construction......................28 170 5.1.2. Physical access.....................................28 171 5.1.3. Power and air conditioning..........................28 172 5.1.4. Water exposures.....................................28 173 5.1.5. Fire prevention and protection......................28 174 5.1.6. Media storage.......................................28 175 5.1.7. Waste disposal......................................28 176 5.1.8. Off-site backup.....................................28 177 5.2. Procedural controls......................................28 178 5.2.1. Trusted roles.......................................29 179 5.2.2. Number of persons required per task.................29 180 5.2.3. Identification and authentication for each role.....29 181 5.2.4. Roles requiring separation of duties................29 182 5.3. Personnel controls.......................................29 183 5.4. Audit logging procedures.................................29 184 5.4.1. Types of events recorded............................29 185 5.4.2. Frequency of processing log.........................29 186 5.4.3. Retention period for audit log......................30 187 5.4.4. Protection of audit log.............................30 188 5.4.5. Audit log backup procedures.........................30 189 5.4.8. Vulnerability assessments...........................30 190 5.6. Key changeover...........................................30 191 5.8. CA or RA termination.....................................30 193 6. Technical Security Controls...................................31 194 6.1. Key pair generation and installation.....................31 195 6.1.1. Key pair generation.................................31 196 6.1.2. Private key delivery to subscriber..................31 197 6.1.3. Public key delivery to certificate issuer...........31 198 6.1.4. CA public key delivery to relying parties...........31 199 6.1.5. Key sizes...........................................32 200 6.1.6. Public key parameters generation and quality 201 checking...........................................32 202 6.1.7. Key usage purposes (as per X.509 v3 key usage 203 field).............................................32 204 6.2. Private Key Protection and Cryptographic Module 205 Engineering Controls....................................32 206 6.2.1. Cryptographic module standards and controls.........32 207 6.2.2. Private key (n out of m) multi-person control.......32 208 6.2.3. Private key escrow..................................32 209 6.2.4. Private key backup..................................32 210 6.2.5. Private key archival................................33 211 6.2.6. Private key transfer into or from a 212 cryptographic module...............................33 213 6.2.7. Private key storage on cryptographic module.........33 214 6.2.8. Method of activating private key....................33 215 6.2.9. Method of deactivating private key..................33 216 6.2.10. Method of destroying private key...................33 217 6.2.11. Cryptographic Module Rating........................33 218 6.3. Other aspects of key pair management.....................33 219 6.3.1. Public key archival.................................33 220 6.3.2. Certificate operational periods and key pair 221 usage periods......................................34 222 6.4. Activation data..........................................34 223 6.5. Computer security controls...............................34 224 6.6. Life cycle technical controls............................34 225 6.6.1. System development controls.........................34 226 6.6.2. Security management controls........................34 227 6.6.3. Life cycle security controls........................34 228 6.7. Network security controls................................34 229 6.8. Time-stamping............................................35 231 7. Certificate and CRL Profiles..................................36 233 8. Compliance Audit And Other Assessments........................37 235 9. Other Business And Legal Matters..............................38 236 9.12. Amendments..............................................38 237 9.12.1. Procedure for amendment............................38 238 9.12.2. Notification mechanism and period..................38 239 9.12.3. Circumstances under which OID must be changed......38 241 10. Security Considerations......................................39 243 11. IANA Considerations..........................................39 245 12. Acknowledgments..............................................39 247 13. References...................................................40 248 13.1. Normative References....................................40 249 13.2. Informative References..................................40 251 Authors' Addresses:..............................................41 253 Pre-5378 Material Disclaimer.....................................42 255 Copyright Statement..............................................42 257 1. Introduction 259 This document describes the certificate policy for a Public Key 260 Infrastructure (PKI) used to attest to Internet number resource 261 holdings (INRs) (IP addresses or Autonomous System (AS) numbers). An 262 organization that distributes INRs to another organization MAY, in 263 parallel, issue a certificate reflecting this distribution. These 264 certificates will enable verification that the resources indicated 265 in the certificate have been distributed to the holder of the 266 associated private key and that this organization is the current 267 holder of these resources. 269 The most important and distinguishing aspect of the PKI for which 270 this policy was created is that it does not purport to identify an 271 INR holder via the subject name contained in the certificate issued 272 to that entity. Rather, each certificate issued under this policy is 273 intended to enable an entity to assert, in a verifiable fashion, 274 that it is the current holder of an INR based on the current records 275 of the entity responsible for the resources in question. 276 Verification of the assertion is based on two criteria: the ability 277 of the entity to digitally sign data that is verifiable using the 278 public key contained in the corresponding certificate, and 279 validation of that certificate in the context of this PKI. 281 This PKI is designed exclusively for use in support of validation of 282 claims related to current INR holdings. This includes any 283 certificates issued in support of operation of this infrastructure, 284 e.g., for integrity or access control of the repository system 285 described in section 2.4. Such transitive uses of certificates also 286 are permitted under this policy. Use of the certificates and 287 certificate revocation lists (CRLs) managed under this PKI for any 288 other purpose is a violation of this CP, and relying parties (RPs) 289 SHOULD reject certificates presented for such uses. 291 Note: This document is based on the template specified in the 292 Internet Engineering Task Force (IETF) standards document RFC 3647 293 [RFC3647]. In the interest of keeping the document as short as 294 reasonable, a number of sections contained in the template are 295 omitted from this policy because they did not apply to this PKI. 296 However, we have retained the section numbering scheme employed in 297 the RFC to facilitate comparison with the outline in Section 6 of 298 the RFC. Each of these omitted sections should be read as "No 299 stipulation" in CP/CPS parlance. 301 Conventions used in this document 302 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 303 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 304 document are to be interpreted as described in RFC-2119 [RFC2119]. 306 1.1. Overview 308 This PKI is designed to support validation of claims by current 309 holders of INRs, in accordance with the records of the organizations 310 that act as Certification Authorities (CAs) in this PKI. The ability 311 to verify such claims is essential to ensuring the unambiguous 312 distribution of these resources. 314 The structure of the RPKI is congruent with the number resource 315 allocation framework of the Internet. The IANA allocates number 316 resources for special purposes [RFC5736], to Regional Internet 317 Registries (RIRs), and to others. The RIRs, in turn, manage the 318 allocation of number resources to end users, Internet Service 319 Providers, and others. 321 This PKI encompasses several types of certificates (see IETF 322 document draft-ietf-sidr-arch-xx [ARCH] for more details): 324 . CA certificates for each organization distributing INRs, and for 325 INR holder 327 . End-entity (EE) certificates for organizations to validate digital 328 signatures on RPKI-signed objects 330 1.2. Document name and identification 332 The name of this document is "Certificate Policy (CP) for the 333 Resource PKI (RPKI)". 335 This policy has been assigned the following OID: 337 id-cp-ipAddr-asNumber OBJECT IDENTIFIER ::= { iso(1) 339 identified-organization(3) dod(6) internet(1) 341 security(5) mechanisms(5) pkix(7) cp(14) 2 } 343 1.3. PKI participants 345 Note: In a PKI, the term "subscriber" refers to an individual or 346 organization that is a Subject of a certificate issued by a CA. The 347 term is used in this fashion throughout this document, without 348 qualification, and should not be confused with the networking use of 349 the term to refer to an individual or organization that receives 350 service from an ISP. In such cases the term "network subscriber" 351 will be used. Also note that, for brevity, this document always 352 refers to PKI participants as organizations or entities, even though 353 some of them are individuals. 355 1.3.1. Certification authorities 357 The organizations that distribute IP addresses and AS numbers (IANA, 358 RIRs, NIRs, ISPs) act as CAs in this PKI. 360 Organizations that do not distribute INRs, but hold such resources 361 also act as CAs when they create EE certificates. 363 1.3.2. Registration authorities 365 This PKI does not require establishment or use of a separate 366 registration authority (RA) in conjunction with the CA function. The 367 RA function MUST be provided by the same entity operating as a CA, 368 e.g., entities listed in Section 1.4.1. An entity acting as a CA in 369 this PKI already has a formal relationship with each organization to 370 which it distributes INRs. These organizations already perform the 371 RA function implicitly since they already assume responsibility for 372 distributing INRs. 374 1.3.3. Subscribers 376 These are the organizations receiving distributions of INRs - RIRs, 377 NIRs, ISPs, and other organizations. 379 Note that any of these organizations may have received distributions 380 from more than one source, over time. This is true even for RIRs, 381 which participate in inter-registry exchanges of address space. This 382 PKI accommodates such relationships. 384 1.3.4. Relying parties 386 Entities or individuals that act in reliance on certificates or 387 RPKI-signed objects issued under this PKI are relying parties. 388 Relying parties may or may not be subscribers within this PKI. (See 389 section 1.7 for the definition of an RPKI-signed object.) 391 1.3.5. Other participants 393 Every organization that undertakes a role as a CA in this PKI is 394 responsible for populating the RPKI distributed repository system 395 with the certificates, CRLs, and RPKI-signed objects that it issues. 396 The organization MAY operate its own publication point or it MAY 397 outsource this function (See sections 2.1 and 2.2.) 399 1.4. Certificate usage 401 1.4.1. Appropriate certificate uses 403 The certificates issued under this hierarchy are for authorization 404 in support of validation of claims of current holdings of INRs. 406 Additional uses of the certificates, consistent with the basic goal 407 cited above, also are permitted under this policy. For example, 408 certificates may be issued in support of integrity and access 409 control for the repository system described in 2.4. Such transitive 410 uses are permitted under this policy. 412 Some of the certificates that may be issued under this PKI could be 413 used to support operation of this infrastructure, e.g., access 414 control for the repository system as described in 2.4. Such uses 415 also are permitted under this policy. 417 1.4.2. Prohibited certificate uses 419 Any uses other than those described in Section 1.4.1 are prohibited 420 under this policy. 422 1.5. Policy administration 424 1.5.1. Organization administering the document 426 This CP is administered by 428 Internet Engineering Steering Group 429 c/o Internet Society 430 1775 Wiehle Avenue, Suite 201 431 Reston, VA 20190-5108 432 U.S.A. 434 1.5.2. Contact person 436 The contact information is 438 iesg@ietf.org 440 +1-703-439-2120 (Internet Society) 442 1.5.4. CP approval procedures 444 The IESG MUST approve a replacement BCP that either updates or 445 obsoletes this BCP, following the procedures of the IETF Standards 446 Process as defined in RFC 2026 [RFC2026]. 448 1.6. Definitions and acronyms 450 CPS - Certification Practice Statement. A CPS is a document that 451 specifies the practices that a Certification Authority employs 452 in issuing certificates in this PKI. 454 Distribution of INRs - A process of distribution of the INRs along the 455 respective number hierarchy. IANA distributes blocks of IP 456 addresses and AS Numbers to the five Regional Internet 457 Registries (RIRs). RIRs distribute smaller address blocks and AS 458 Numbers to organizations within their service regions, who in 459 turn distribute IP addresses to their customers. 461 IANA - Internet Assigned Numbers Authority. IANA is responsible for 462 global coordination of the IP addressing systems and AS numbers 463 used for routing internet traffic. IANA distributes INRs to 464 Regional Internet Registries (RIRs). 466 INRs - Internet Number Resources. INRs are number values for three 467 protocol parameter sets, namely: 469 . IP Version 4 addresses, 471 . IP version 6 addresses, and 473 . Identifiers used in Internet inter-domain routing, currently 474 Border Gateway Protocol-4 AS numbers. 476 ISP - Internet Service Provider. This is an organization managing and 477 selling Internet services to other organizations. 479 LIR - In some regions, the term Local Internet Registry (LIR) is used 480 to refer to what is called an ISP in other regions. 482 NIR - National Internet Registry. This is an organization that manages 483 the distribution of INRs for a portion of the geopolitical area 484 covered by a Regional Registry. NIRs form an optional second 485 tier in the tree scheme used to manage INRs. 487 RIR - Regional Internet Registry. This is an organization that 488 manages the distribution of INRs for a geopolitical area. 490 RPKI-signed object - An RPKI-signed object is a digitally signed data 491 object (other than a certificate or CRL) declared to be such by 492 a standards track RFC, and that can be validated using 493 certificates issued under this PKI. The content and format of 494 these data constructs depend on the context in which validation 495 of claims of current holdings of INRs takes place. Examples of 496 these objects are repository manifests and CRLs. 498 2. Publication And Repository Responsibilities 500 2.1. Repositories 502 Certificates, CRLs, and RPKI-signed objects (intended for public 503 consumption) MUST be made available for downloading by all relying 504 parties, to enable them to validate this data. This motivates use of 505 a robust, distributed repository system. Each CA MUST maintain a 506 publicly accessible online repository and publish all RPKI-signed 507 objects (intended for public consumption) via this repository in a 508 manner that conforms with RFCwwww [RFCwwww] (This function MAY be 509 outsourced, as noted in Section 2.2 below.) The collection of 510 repositories forms the RPKI distributed repository system. 512 2.2. Publication of certification information 514 Each CA MUST publish the certificates (intended for public 515 consumption) that it issues via the repository system. 517 Each CA MUST publish the CRLs (intended for public consumption) that 518 it issues via the repository system. 520 Each CA MUST publish its RPKI-signed objects (intended for public 521 consumption) via the repository system. 523 Each CA that issues certificates to entities outside of its 524 administrative domain SHOULD create and publish a CPS that meets the 525 requirements set forth in this CP. Publication means that the 526 entities to which the CA issues certificates MUST be able to acquire 527 a copy of the CPS, and MUST be able to ascertain when the CPS 528 changes. (An organization that does not allocate or assign INRs does 529 not need to create or publish a CPS.) 531 An organization MAY choose to outsource publication of RPKI data - 532 certificates, CRLs, and other RPKI-signed objects. 534 The CP will be published as an IETF RFC and will be available from 535 the IETF RFC repository. 537 2.3. Time or frequency of publication 539 The CPS for each CA MUST specify the following information: 541 The period of time within which a certificate will be published 542 after the CA issues the certificate. 544 The period of time within which a CA will publish a CRL with an 545 entry for a revoked certificate after it revokes that certificate. 547 Expired and revoked certificates SHOULD be removed from the RPKI 548 repository system, upon expiration or revocation, respectively. 549 Also, please note that each CA MUST publish its CRL prior to the 550 nextUpdate value in the scheduled CRL previously issued by the CA. 552 2.4. Access controls on repositories 554 Each CA or repository operator MUST implement access controls to 555 prevent unauthorized persons from adding, modifying or deleting 556 repository entries. A CA or repository operator MUST NOT 557 intentionally use technical means of limiting read access to its 558 CPS, certificates, CRLs or RPKI-signed objects. This data is 559 supposed to be accessible to the public. 561 3. Identification and Authentication 563 3.1. Naming 565 3.1.1. Types of names 567 The distinguished name for every CA and end-entity consists of a 568 single Common Name (CN) attribute with a value generated by the 569 issuer of the certificate. Optionally, the serialNumber attribute 570 MAY be included along with the common name (to form a terminal 571 relative distinguished name set), to distinguish among successive 572 instances of certificates associated with the same entity. 574 3.1.2. Need for names to be meaningful 576 The Subject name in each certificate SHOULD NOT be "meaningful", 577 i.e., the name is NOT intended to convey the identity of the Subject 578 to relying parties. The rationale here is that certificates issued 579 under this PKI are used for authorization in support of applications 580 that make use of attestations of INR holdings. They are not used to 581 identify Subjects. 583 3.1.3. Anonymity or pseudonymity of subscribers 585 Although Subject (and Issuer) names need not be meaningful, and may 586 appear "random," anonymity is not a function of this PKI, and thus 587 no explicit support for this feature is provided. 589 3.1.4. Rules for interpreting various name forms 591 None 593 3.1.5. Uniqueness of names 595 There is no guarantee that subject names are globally unique in this 596 PKI. Each CA certifies Subject names that MUST be unique among the 597 certificates that it issues. Although it is desirable that these 598 Subject names be unique throughout the PKI, name uniqueness within 599 the RPKI cannot be guaranteed. 601 However, Subject names in certificates SHOULD be constructed in a 602 way that minimizes the chances that two entities in the RPKI will be 603 assigned the same name. The RPKI certificate profile [RFCwwww] 604 provides an example of how to generate (meaningless) subject names 605 in a way that minimizes the likelihood of collisions. 607 3.2. Initial identity validation 609 3.2.1. Method to prove possession of private key 611 Each CA operating within the context of this PKI MUST require each 612 Subject to demonstrate proof-of-possession (PoP) of the private key 613 corresponding to the public key in the certificate, prior to issuing 614 the certificate. The means by which PoP is achieved is determined by 615 each CA and MUST be declared in the CPS of that CA. 617 3.2.2. Authentication of organization identity 619 Each CA operating within the context of this PKI MUST employ 620 procedures to ensure that each certificate it issues accurately 621 reflects its records with regard to the organization to which the CA 622 has distributed the INRs identified in the certificate. The specific 623 procedures employed for this purpose MUST bedescribed by the CPS for 624 each CA. Relying parties can expect each CA to employ procedures 625 commensurate with those it already employs as a registry or ISP, in 626 the management of the INRs. This authentication is solely for use by 627 each CA in dealing with the organizations to which it distributes 628 INRs, and thus should not be relied upon outside of this CA- 629 subscriber relationship. 631 3.2.3. Authentication of individual identity 633 Each CA operating within the context of this PKI MUST employ 634 procedures to identify at least one individual as a representative 635 of each organization that is an INR holder. The specific means by 636 which each CA authenticates individuals as representatives for an 637 organization MUST be described by the CPS for each CA. Relying 638 parties can expect each CA to employ procedures commensurate with 639 those it already employs as a registry or ISP, in authenticating 640 individuals as representatives for INR holders. 642 3.2.4. Non-verified subscriber information 644 A CA MUST NOT include any non-verified subscriber data in 645 certificates issued under this certificate policy except for SIA 646 extensions. 648 3.2.5. Validation of authority 650 Each CA operating within the context of this PKI MUST employ 651 procedures to verify that an individual claiming to represent an 652 organization to which a certificate is issued, is authorized to 653 represent that organization in this context. The procedures MUST be 654 described by the CPS for the CA. Relying parties can expect each CA 655 to employ procedures commensurate with those it already employs as a 656 registry or ISP, in authenticating individuals as representatives 657 for INR holders. 659 3.2.6. Criteria for interoperation 661 This PKI is neither intended nor designed to interoperate with any 662 other PKI. 664 3.3. Identification and authentication for re-key requests 666 3.3.1. Identification and authentication for routine re-key 668 Each CA operating within the context of this PKI MUST employ 669 procedures to ensure that an organization requesting a re-key is the 670 legitimate holder of the certificate to be re-keyed and associated 671 INRs and MUST require PoP of the private key corresponding to the 672 new public key. The procedures employed for these purposes MUST be 673 described in the CPS for the CA. With respect to authentication of 674 the holder of the INRs, relying parties can expect each CA to employ 675 procedures commensurate with those it already employs as a registry 676 or ISP, in the management of INRs. 678 Note: An issuer MAY choose to require periodic re-keying consistent 679 with contractual agreements with the recipient. If so, this MUST be 680 described by the CPS for the CA. 682 3.3.2. Identification and authentication for re-key after revocation 684 Each CA operating within the context of this PKI MUST employ 685 procedures to ensure that an organization requesting a re-key after 686 revocation is the same entity to which the revoked certificate was 687 issued and is the legitimate holder of the associated INR. The CA 688 MUST require PoP of the private key corresponding to the new public 689 key. The specific procedures employed for these purposes MUST be 690 described by the CPS for the CA. With respect to authentication of 691 the holder of the INRs, relying parties can expect each CA to employ 692 procedures commensurate with those it already employs as a registry 693 or ISP, in the management of INRs. Note that there MAY be different 694 procedures for the case where the legitimate subject still possesses 695 the original private key as opposed to the case when it no longer 696 has access to that key. 698 3.4. Identification and authentication for revocation request 700 Each CA operating within the context of this PKI MUST employ 701 procedures to ensure that: 703 . an organization requesting revocation is the legitimate holder 704 of the certificate to be revoked. 706 . each certificate it revokes accurately reflects its records 707 with regard to the organization to which the CA has distributed 708 the INRs identified in the certificate. 710 . an individual claiming to represent an organization for which 711 a certificate is to be revoked, is authorized to represent that 712 organization in this context. 714 The specific procedures employed for these purposes MUST be 715 described by the CPS for the CA. Relying parties can expect each CA 716 to employ procedures commensurate with those it already employs as a 717 registry or ISP, in the management of INRs. 719 4. Certificate Life-Cycle Operational Requirements 721 4.1. Certificate Application 723 4.1.1. Who can submit a certificate application 725 Any entity that distributes INRs SHOULD acquire a certificate. This 726 includes Internet Registries and ISPs. Additionally, entities that 727 hold INRs from an Internet Registry, or that are multi-homed, MAY 728 acquire a certificate under this PKI. The (CA) certificates issued 729 to these entities MUST include one or both of the extensions defined 730 by RFC 3779 [RFC3779], X.509 Extensions for IP Addresses and AS 731 Identifiers, as appropriate. 733 The application procedure MUST be described in the CPS for each CA. 735 4.1.2. Enrollment process and responsibilities 737 The enrollment process and procedures MUST be described by the CPS 738 for each CA. An entity that desires one or more certificates should 739 contact the organization from which it receives its INRs. 741 4.2. Certificate application processing 743 CAs SHOULD make use of existing standards for certificate 744 application processing. Section 6 of the resource certificate 745 profile [RFCyyyy] defines the standard certificate request formats 746 that MUST be supported 748 Each CA MUST define the certificate request/response standards that 749 it employs, via its CPS. 751 4.2.1. Performing identification and authentication functions 753 Existing practices employed by registries and ISPs to identify and 754 authenticate organizations that receive INRs form the basis for 755 issuance of certificates to these subscribers. It is important to 756 note that the Resource PKI SHOULD never be used to authenticate the 757 identity of an organization, but rather to bind subscribers to the 758 INRs they hold. Because identity is not being vouched for by this 759 PKI, certificate application procedures need not verify legal 760 organization names, etc. 762 4.2.2. Approval or rejection of certificate applications 764 Certificate applications MUST be approved based on the normal 765 business practices of the entity operating the CA, based on the CA's 766 records of INR holders. Each CA MUST follow the procedures specified 767 in 3.2.1 to verify that the requester holds the private key 768 corresponding to the public key that will be bound to the 769 certificate the CA issues to the requestor. The details of how 770 certificate applications are approved MUST be described in the CPS 771 for the CA in question. 773 4.2.3. Time to process certificate applications 775 No stipulation. Each CA MUST declare its expected time frame to 776 process (approve, issue and publish) a certificate application as 777 part of its CPS. 779 4.3. Certificate issuance 781 4.3.1. CA actions during certificate issuance 783 If a CA determines that the request is acceptable, it MUST issue the 784 corresponding certificate and publish it in the RPKI distributed 785 repository system via publication of the certificate at the CA's 786 repository publication point. 788 4.3.2. Notification to subscriber by the CA of issuance of certificate 790 The CA MUST notify the subscriber when the certificate is published. 791 The means by which a subscriber is notified is defined by each CA in 792 its CPS. 794 4.4. Certificate acceptance 796 4.4.1. Conduct constituting certificate acceptance 798 Within the timeframe specified in its CPS, the CA MUST place the 799 certificate in the repository and notify the subscriber. This MAY 800 be done without subscriber review and acceptance. Each CA MUST state 801 in its CPS the procedures it follows for publishing of the 802 certificate and notification to the subscriber. 804 4.4.2. Publication of the certificate by the CA 806 Certificates MUST be published in the RPKI distributed repository 807 system via publication of the certificate at the CA's repository 808 publication point as per the conduct described in 4.4.1. The 809 procedures for publication MUST be defined by each CA in its CPS. 811 4.4.3. Notification of certificate issuance by the CA to other entities 813 The CPS of each CA MUST indicate whether any other entities will be 814 notified when a certificate is issued. 816 4.5. Key pair and certificate usage 818 A summary of the use model for the RPKI is provided below. 820 4.5.1. Subscriber private key and certificate usage 822 Each holder of an INR is eligible to request an X.509 CA certificate 823 containing appropriate RFC 3779 extensions. Holders of CA resource 824 certificates also MAY issue EE certificates to themselves to enable 825 verification of RPKI-signed objects that they generate. 827 4.5.2. Relying party public key and certificate usage 829 Reliance on a certificate must be reasonable under the 830 circumstances. If the circumstances indicate a need for additional 831 assurances, the relying party must obtain such assurances in order 832 for such reliance to be deemed reasonable. 834 Before any act of reliance, relying parties MUST independently (1) 835 verify that the certificate will be used for an appropriate purpose 836 that is not prohibited or otherwise restricted by this CP (see 837 section 1.5), and (2) assess the status of the certificate and all 838 the CAs in the chain (terminating at a TA accepted by the RP) that 839 issued the certificates relevant to the certificate in question. If 840 any of the certificates in the certificate chain have been revoked, 841 the relying party is solely responsible to determine whether 842 reliance on a digital signature to be verified by the certificate in 843 question is acceptable. Any such reliance is made solely at the risk 844 of the relying party. 846 If a relying party determines that use of the certificate is 847 appropriate, the relying party must utilize appropriate software 848 and/or hardware to perform digital signature verification as a 849 condition of relying on the certificate. Moreover the relying party 850 MUST validate the certificate in a manner consistent with the RPKI 851 certificate profile [RFCyyyy], which specifies the extended 852 validation algorithm for RPKI certificates. 854 4.6. Certificate renewal 856 This section describes the procedures for certificate renewal. 857 Certificate renewal is the issuance of a new certificate to replace 858 an old one prior to its expiration. Only the validity dates and the 859 serial number are changed. The public key and all other information 860 remain the same. 862 4.6.1. Circumstance for certificate renewal 864 A certificate MUST be processed for renewal based on its expiration 865 date or a renewal request from the subscriber. Prior to the 866 expiration of an existing subscriber's certificate, it is the 867 responsibility of the subscriber to renew the certificate to 868 maintain continuity of certificate usage. If the issuing CA 869 initiates the renewal process based on the certificate expiration 870 date, then that CA MUST notify the holder in advance of the renewal 871 process. The validity interval of the new (renewed) certificate 872 SHOULD overlap that of the previous certificate, to ensure 873 continuity of certificate usage. It is RECOMMENDED that the renewed 874 certificate be issued and published at least 1 week prior to the 875 expiration of the certificate it replaces. 877 Certificate renewal SHOULD incorporate the same public key as the 878 previous certificate, unless the private key has been reported as 879 compromised. If a new key pair is being used, the stipulations of 880 Section 4.7 apply. 882 4.6.2. Who may request renewal 884 Only the certificate holder or the issuing CA may initiate the 885 renewal process. The certificate holder MAY request an early 886 renewal, for example, if it wishes to change the public key, or if 887 it expects to be unavailable to support the renewal process during 888 the normal expiration period. An issuing CA MAY initiate the renewal 889 process based on the certificate expiration date. 891 4.6.3. Processing certificate renewal requests 893 Renewal procedures MUST ensure that the person or organization 894 seeking to renew a certificate is in fact the subscriber (or 895 authorized by the subscriber) of the certificate and the legitimate 896 holder of the INR associated with the renewed certificate. Renewal 897 processing MUST verify that the certificate in question has not been 898 revoked. 900 4.6.4. Notification of new certificate issuance to subscriber 902 No additional stipulations beyond those of section 4.3.2. 904 4.6.5. Conduct constituting acceptance of a renewal certificate 906 No additional stipulations beyond those of section 4.4.1. 908 4.6.6. Publication of the renewal certificate by the CA 910 No additional stipulations beyond those of section 4.4.2. 912 4.6.7. Notification of certificate issuance by the CA to other entities 914 No additional stipulations beyond those of section 4.3.3. 916 4.7. Certificate re-key 918 This section describes the procedures for certificate re-key. 919 Certificate re-key is the issuance of a new certificate to replace 920 an old one because the key needs to be replaced. Unlike with 921 certificate renewal, the public key is changed. 923 4.7.1. Circumstance for certificate re-key 925 Re-key of a certificate SHOULD be performed only when required, 926 based on: 928 1. knowledge or suspicion of compromise or loss of the associated 929 private key, or 931 2. the expiration of the cryptographic lifetime of the associated 932 key pair 934 A CA re-key operation has dramatic consequences, requiring the re- 935 issuance of all certificates issued by the re-keyed entity. So it 936 should be performed only when necessary and in a way that preserves 937 the ability of relying parties to validate certificates whose 938 validation path includes the re-keyed entity. CA key rollover MUST 939 follow the procedures defined in RFCxxxx [RFCxxxx]. 941 Note that if a certificate is revoked to replace the RFC 3779 942 extensions, the replacement certificate MUST incorporate the same 943 public key rather than a new key. This applies to when one is 944 adding INRs (revocation not required) and to when one is removing 945 INRs (revocation required (see Section 4.8.1). 947 If the re-key is based on a suspected compromise, then the previous 948 certificate MUST be revoked. 950 4.7.2. Who may request certification of a new public key 952 The holder of the certificate may request a re-key. In addition, 953 the CA that issued the certificate MAY chose to initiate a rekey 954 based on a verified compromise report. 956 4.7.3. Processing certificate re-keying requests 958 The re-key process follows the general procedures of certificate 959 generation as defined in section 4.3. 961 4.7.4. Notification of new certificate issuance to subscriber 963 No additional stipulations beyond those of section 4.3.2. 965 4.7.5. Conduct constituting acceptance of a re-keyed certificate 967 No additional stipulations beyond those of section 4.4.1. 969 4.7.6. Publication of the re-keyed certificate by the CA 971 No additional stipulations beyond those of section 4.4.2. 973 4.7.7. Notification of certificate issuance by the CA to other entities 975 No additional stipulations beyond those of section 4.3.3. 977 4.8. Certificate modification 979 4.8.1. Circumstance for certificate modification 981 Modification of a certificate occurs to implement changes to 982 selected attribute values in a certificate. In the context of the 983 RPKI, the only changes that are accommodated by certificate 984 modification are changes to the INR holdings described by the RFC 985 3779 extension and changes to the SIA extension. 987 When a certificate modification is approved, a new certificate is 988 issued. If no INR holdings are removed from the certificate, the new 989 certificate MUST contain the same public key and the same expiration 990 date as the original certificate, (but with the SIA extension and/or 991 the INR set expanded). In this case, revocation of the previous 992 certificate is not required. 994 When previously distributed INRs are removed from a certificate, 995 then the old certificate MUST be revoked and a new certificate MUST 996 be issued, reflecting the changed INR holdings. (The SIA extension 997 in the new certificate will be unchanged, unless the affected INR 998 holder supplies a new SIA value.) 1000 4.8.2. Who may request certificate modification 1002 Either the certificate holder or the issuer may initiate the 1003 certificate modification process. 1005 4.8.3. Processing certificate modification requests 1007 The CA MUST determine that the requested modification is appropriate 1008 and that the procedures for the issuance of a new certificate are 1009 followed (see Section 4.3). 1011 4.8.4. Notification of new certificate issuance to subscriber 1013 No additional stipulations beyond those of section 4.3.2. 1015 4.8.5. Conduct constituting acceptance of modified certificate 1017 No additional stipulations beyond those of section 4.4.1. 1019 4.8.6. Publication of the modified certificate by the CA 1021 No additional stipulations beyond those of section 4.4.2. 1023 4.8.7. Notification of certificate issuance by the CA to other entities 1025 No additional stipulations beyond those of section 4.3.3. 1027 4.9. Certificate revocation and suspension 1029 4.9.1. Circumstances for revocation 1031 A certificate MUST be revoked (and published on a CRL) if there is 1032 reason to believe that there has been a compromise of a subscriber's 1033 private key. A certificate also MAY be revoked to invalidate a data 1034 object signed by the private key associated with that certificate. 1035 Other circumstances that justify revocation of a certificate MAY be 1036 specified in a CA's CPS. 1038 Note: If new INRs are being added to an organization's existing 1039 distribution, the old certificate need not be revoked. Instead, a 1040 new certificate MAY be issued with both the old and the new 1041 resources and the old key. If INRs are being removed or if there has 1042 been a key compromise, then the old certificate MUST be revoked (and 1043 a re-key MUST be performed in the event of key compromise). 1045 4.9.2. Who can request revocation 1047 This MUST be defined in the CPS of the relevant organization. 1049 4.9.3. Procedure for revocation request 1051 A subscriber MAY submit a request to the certificate issuer for a 1052 revocation. This request MUST identify the certificate to be revoked 1053 and MUST be authenticated. The procedures for making the request 1054 MUST be described in the CPS for each CA. The RPKI provisioning 1055 document [PROV] describes a protocol that MAY be used to make 1056 revocation requests. 1058 A certificate issuer MUST notify the subscriber when revoking a 1059 certificate. The notification requirement is satisfied by CRL 1060 publication. The CPS for a CA MUST indicate the means by which the 1061 CA will inform a subscriber of certificate revocation. 1063 4.9.4. Revocation request grace period 1065 A subscriber SHOULD request revocation as soon as possible after the 1066 need for revocation has been identified. There is no specified grace 1067 period for the subscriber in this process. 1069 4.9.5. Time within which CA must process the revocation request 1071 No stipulation. Each CA SHOULD specify its expected revocation 1072 processing time in its CPS. 1074 4.9.6. Revocation checking requirement for relying parties 1076 A relying party MUST acquire and check the most recent, scheduled 1077 CRL from the issuer of the certificate, whenever the relying party 1078 validates a certificate. 1080 4.9.7. CRL issuance frequency 1082 The CRL issuance frequency MUST be determined by each CA and stated 1083 in its CPS. Each CRL carries a nextScheduledUpdate value and a new 1084 CRL MUST be published at or before that time. A CA MUST set the 1085 nextUpdate value when it issues a CRL, to signal when the next 1086 scheduled CRL will be issued. 1088 4.9.8. Maximum latency for CRLs 1090 The CPS for each CA MUST specify the maximum latency associated with 1091 posting its CRL to the repository system. 1093 4.10. Certificate status services 1095 This PKI does not make provision for use of OCSP or SCVP, because it 1096 is anticipated that the primary RPs (ISPs) will acquire and validate 1097 certificates for all participating resource holders. These protocols 1098 are not designed for such large-scale, bulk certificate status 1099 checking. RPs MUST check for new CRLs at least daily. It is 1100 RECOMMENDED that RPs perform this check several times per day, but 1101 no more than 8-12 times per day (to avoid excessive repository 1102 accesses). 1104 5. Facility, Management, And Operational Controls 1106 5.1. Physical controls 1108 Each CA MUST maintain physical security controls for its operation 1109 that are commensurate with those employed by the organization in the 1110 management of INR distribution. The physical controls employed for 1111 CA operation MUST be specified in its CPS. Possible topics to be 1112 covered in the CPS are shown below. (These sections are taken from 1113 [RFC3647].) 1115 5.1.1. Site location and construction 1117 5.1.2. Physical access 1119 5.1.3. Power and air conditioning 1121 5.1.4. Water exposures 1123 5.1.5. Fire prevention and protection 1125 5.1.6. Media storage 1127 5.1.7. Waste disposal 1129 5.1.8. Off-site backup 1131 5.2. Procedural controls 1133 Each CA MUST maintain procedural security controls that are 1134 commensurate with those employed by the organization in the 1135 management of INR distribution. The procedural security controls 1136 employed for CA operation MUST be specified in its CPS. Possible 1137 topics to be covered in the CPS are shown below. (These sections are 1138 taken from [RFC3647].) 1140 5.2.1. Trusted roles 1142 5.2.2. Number of persons required per task 1144 5.2.3. Identification and authentication for each role 1146 5.2.4. Roles requiring separation of duties 1148 5.3. Personnel controls 1150 Each CA MUST maintain personnel security controls that are 1151 commensurate with those employed by the organization in the 1152 management of INR distribution. The details for each CA MUST be 1153 specified in its CPS. 1155 5.4. Audit logging procedures 1157 Details of how a CA implements the audit logging described in this 1158 section (5.4.1 to 5.4.8) MUST be addressed in its CPS. 1160 5.4.1. Types of events recorded 1162 Audit records MUST be generated for the basic operations of the 1163 certification authority computing equipment. Audit records MUST 1164 include the date, time, responsible user or process, and summary 1165 content data relating to the event. Auditable events include: 1167 . Access to CA computing equipment (e.g., logon, logout) 1169 . Messages received requesting CA actions (e.g., certificate 1170 requests, certificate revocation requests, compromise 1171 notifications) 1173 . Certificate creation, modification, revocation, or renewal actions 1175 . Posting of any material to a repository 1177 . Any attempts to change or delete audit data 1179 . Key generation 1181 . Software and/or configuration updates to the CA 1183 . Clock adjustments 1185 5.4.2. Frequency of processing log 1187 Each CA MUST establish its own procedures for review of audit logs. 1189 5.4.3. Retention period for audit log 1191 Each CA MUST establish its own polices for retention of audit logs. 1193 5.4.4. Protection of audit log 1195 The audit log SHOULD be protected based on current industry 1196 standards. 1198 5.4.5. Audit log backup procedures 1200 The audit log SHOULD be backed up based on current industry 1201 standards. 1203 5.4.8. Vulnerability assessments 1205 The RPKI subsystems of a registry or ISP SHOULD participate in any 1206 vulnerability assessments that these organizations run as part of 1207 their normal business practice. 1209 5.6. Key changeover 1211 When a CA wishes to change keys, it MUST acquire a new certificate 1212 containing its new public key. See [RFCxxxx] for a description of 1213 how key changeover is effected in the RPKI. 1215 5.8. CA or RA termination 1217 In the RPKI, each subscriber acts as a CA authoritative for the 1218 specified INRs that were distributed to that entity. Procedures 1219 associated with the termination of a CA MUST be described in the CPS 1220 for that CA. These procedures MUST include a provision to notify 1221 each entity that issued a certificate to the organization that is 1222 operating the CA that is terminating. 1224 Since the RA function MUST be provided by the same entity operating 1225 as the CA (see Section 1.4.2), there are no separate stipulations 1226 for RAs. 1228 6. Technical Security Controls 1230 The organizations that distribute INRs to network subscribers are 1231 authoritative for these distributions. This PKI is designed to 1232 enable ISPs and network subscribers to demonstrate that they are the 1233 holders of the INRs that have been distributed to them. Accordingly, 1234 the security controls used by CAs and subscribers for this PKI need 1235 only to be as secure as those that apply to the procedures for 1236 administering the distribution of INR data by the extant 1237 organizations. Details of each CA's security controls MUST be 1238 described in the CPS issued by the CA. 1240 6.1. Key pair generation and installation 1242 6.1.1. Key pair generation 1244 In most instances, public-key pairs will be generated by the 1245 subject, i.e., the organization receiving the distribution of INRs. 1246 However, some CAs MAY offer to generate key pairs on behalf of their 1247 subjects at the request of the subjects, e.g., to accommodate 1248 subscribers who do not have the ability to perform key generation in 1249 a secure fashion. (The CA has to check the quality of the keys only 1250 if it generates them (see 6.1.6)). Since the keys used in this PKI 1251 are not for non-repudiation purposes, generation of key pairs by CAs 1252 does not inherently undermine the security of the PKI. Each CA MUST 1253 describe its key pair generation procedures in its CPS. 1255 6.1.2. Private key delivery to subscriber 1257 If a CA provides key pair generation services for subscribers, its 1258 CPS MUST describe the means by which private keys are delivered to 1259 subscribers in a secure fashion. 1261 6.1.3. Public key delivery to certificate issuer 1263 When a public key is transferred to the issuing CA to be certified, 1264 it MUST be delivered through a mechanism ensuring that the public 1265 key has not been altered during transit and that the subscriber 1266 possesses the private key corresponding to the transferred public 1267 key. 1269 6.1.4. CA public key delivery to relying parties 1271 CA public keys for all entities (other than trust anchors) are 1272 contained in certificates issued by other CAs. These certificates 1273 MUST be published in the RPKI distributed repository system. Relying 1274 parties download these certificates from the repositories. Public 1275 key values and associated data for (putative) trust anchors are 1276 distributed out of band and accepted by relying parties on the basis 1277 of locally-defined criteria. 1279 6.1.5. Key sizes 1281 The algorithms and key sizes used in the RPKI are specified in RFC 1282 ZZZZ [RFCzzzz]. 1284 6.1.6. Public key parameters generation and quality checking 1286 The public key parameters used in the RPKI are specified in RFC ZZZZ 1287 [RFCzzzz]. Each subscriber is responsible for performing checks on 1288 the quality of its key pair. A CA is not responsible for performing 1289 such checks for subscribers except in the case where the CA 1290 generates the key pair on behalf of the subscriber. 1292 6.1.7. Key usage purposes (as per X.509 v3 key usage field) 1294 The Key usage extension bit values used in the RPKI are specified in 1295 RFC YYYY [RFCyyyy]. 1297 6.2. Private Key Protection and Cryptographic Module Engineering 1298 Controls 1300 6.2.1. Cryptographic module standards and controls 1302 The cryptographic module standards and controls employed by each CA 1303 MUST be described in the CPS issued by that CA. 1305 6.2.2. Private key (n out of m) multi-person control 1307 CAs MAY employ multi-person controls to constrain access to their 1308 private keys, but this is not a requirement for all CAs in the PKI. 1309 The CPS for each CA MUST describe which, if any, multi-person 1310 controls it employs. 1312 6.2.3. Private key escrow 1314 No private key escrow procedures are required for the RPKI. 1316 6.2.4. Private key backup 1318 Because of the adverse operational implications associated with the 1319 loss of use of a CA private key in the PKI, each CA MUST employ a 1320 secure means to backup its private keys. The details of the 1321 procedures for backing up a CA's private key MUST be described in 1322 the CPS issued by the CA. 1324 6.2.5. Private key archival 1326 The details of the process and procedures used to archive the CA's 1327 private key MUST be described in the CPS issued by the CA. 1329 6.2.6. Private key transfer into or from a cryptographic module 1331 The details of the process and procedures used to transfer the CA's 1332 private key into or from a cryptographic module MUST be described in 1333 the CPS issued by the CA. 1335 6.2.7. Private key storage on cryptographic module 1337 The details of the process and procedures used to store the CA's 1338 private key on a cryptographic module and protect it from 1339 unauthorized use MUST be described in the CPS issued by the CA. 1341 6.2.8. Method of activating private key 1343 The details of the process and procedures used to activate the CA's 1344 private key MUST be described in the CPS issued by the CA. 1346 6.2.9. Method of deactivating private key 1348 The details of the process and procedures used to deactivate the 1349 CA's private key MUST be described in the CPS issued by the CA. 1351 6.2.10. Method of destroying private key 1353 The details of the process and procedures used to destroy the CA's 1354 private key MUST be described in the CPS issued by the CA. 1356 6.2.11. Cryptographic Module Rating 1358 The security rating of the cryptographic module MUST be described in 1359 the CPS issued by the CA. 1361 6.3. Other aspects of key pair management 1363 6.3.1. Public key archival 1365 Because this PKI does not support non-repudiation, there is no need 1366 to archive public keys. 1368 6.3.2. Certificate operational periods and key pair usage periods 1370 The INRs held by a CA may periodically change when it receives new 1371 distributions. To minimize disruption, the CA key pair MUST NOT 1372 change when INRs are added to its certificate. 1374 If ISP and network subscriber certificates are tied to the duration 1375 of service agreements, these certificates should have validity 1376 periods commensurate with the duration of these agreements. In any 1377 case, the validity period for certificates MUST be chosen by the 1378 issuing CA and described in its CPS. 1380 6.4. Activation data 1382 Each CA MUST document in its CPS how it will generate, install and 1383 protect its activation data. 1385 6.5. Computer security controls 1387 Each CA MUST document the technical security requirements it employs 1388 for CA computer operation in its CPS. 1390 6.6. Life cycle technical controls 1392 6.6.1. System development controls 1394 The CPS for each CA MUST document any system development controls 1395 required by that CA, if applicable. 1397 6.6.2. Security management controls 1399 The CPS for each CA MUST document the security controls applied to 1400 the software and equipment used for this PKI. These controls MUST be 1401 commensurate with those used for the systems used by the CAs for 1402 managing the INRs. 1404 6.6.3. Life cycle security controls 1406 The CPS for each CA MUST document how the equipment (hardware and 1407 software) used for this PKI will be procured, installed, maintained, 1408 and updated. This MUST be done in a fashion commensurate with the 1409 way in which equipment for the management and distribution of INRs 1410 is handled. 1412 6.7. Network security controls 1414 The CPS for each CA MUST document the network security controls 1415 employed for CA operation. These MUST be commensurate with the 1416 protection it employs for the computers used for managing 1417 distribution of INRs. 1419 6.8. Time-stamping 1421 The RPKI does not make use of time stamping. 1423 7. Certificate and CRL Profiles 1425 Please refer to the RPKI Certificate and CRL Profile [RFCyyyy]. 1427 8. Compliance Audit And Other Assessments 1429 The Certificate Policy for a typical PKI defines the criteria 1430 against which prospective CAs are evaluated and establishes 1431 requirements that they must meet. In this PKI, the CAs are already 1432 authoritative for the management of INRs, and the PKI simply 1433 supports verification of the distribution of these resources to 1434 network subscribers. Accordingly, whatever audit and other 1435 assessments are already used to ensure the security of the 1436 management of INRs is sufficient for this PKI. The CPS for each CA 1437 MUST describe what audits and other assessments are used. 1439 9. Other Business And Legal Matters 1441 As noted throughout this certificate policy, the organizations 1442 managing the distribution of INRs are authoritative in their roles 1443 as managers of this data. They MUST operate this PKI to allow the 1444 holders of INRs to generate digitally signed data that attest to 1445 these distributions. Therefore, the manner in which the 1446 organizations in question manage their business and legal matters 1447 for this PKI MUST be commensurate with the way in which they already 1448 manage business and legal matters in their existing roles. Since 1449 there is no single set of responses to this section that would apply 1450 to all organizations, the topics listed in sections 4.9.1 to 4.9.11 1451 and 4.9.13 to 4.9.17 of RFC 3647 SHOULD be covered in the CPS issued 1452 by each CA, although not every CA may choose to address all of these 1453 topics. 1455 9.12. Amendments 1457 9.12.1. Procedure for amendment 1459 The procedure for amending this CP is via written notice from the 1460 IESG in the form of a new (BCP) RFC that updates or obsoletes this 1461 document. 1463 9.12.2. Notification mechanism and period 1465 Successive versions of the CP will be published with the statement 1466 "This CP takes effect on MM/DD/YYYY." MM/DD/YYYY MUST be a minimum 1467 of 6 months from the date of publication. 1469 9.12.3. Circumstances under which OID must be changed 1471 If the IESG judges that changes to the CP do not materially reduce 1472 the acceptability of certificates issued for RPKI purposes, there 1473 will be no change to the CP OID. If the IESG judges that changes to 1474 the CP do materially change the acceptability of certificates for 1475 RPKI purposes, then there will be a new CP OID. 1477 10. Security Considerations 1479 According to X.509, a certificate policy (CP) is "a named set of 1480 rules that indicates the applicability of a certificate to a 1481 particular community and/or class of applications with common 1482 security requirements." A CP may be used by a relying party to help 1483 in deciding whether a certificate, and the binding therein, are 1484 sufficiently trustworthy and otherwise appropriate for a particular 1485 application. This document describes the CP for the Resource Public 1486 Key Infrastructure (RPKI). There are separate documents 1487 (Certification Practice Statements (CPS's)) that cover the factors 1488 that determine the degree to which a relying party can trust the 1489 binding embodied in a certificate. The degree to which such a 1490 binding can be trusted depends on several factors, e.g., the 1491 practices followed by the certification authority (CA) in 1492 authenticating the subject; the CA's operating policy, procedures, 1493 and technical security controls, including the scope of the 1494 subscriber's responsibilities (for example, in protecting the 1495 private key), and the stated responsibilities and liability terms 1496 and conditions of the CA (for example, warranties, disclaimers of 1497 warranties, and limitations of liability). 1499 Since name uniqueness within the RPKI cannot be guaranteed, there is 1500 a risk that two or more CAs in the RPKI will issue certificates and 1501 CRLs under the same Issuer name. Path validation implementations 1502 that conform to the resource certification path validation algorithm 1503 [see RFCyyyy] verify that the same key was used to sign both the 1504 target (the resource certificate) and the corresponding CRL. So a 1505 name collision will not change the result. Use of the basic X.509 1506 path validation algorithm, which assumes name uniqueness, could 1507 result in a revoked certificate being accepted as valid or a valid 1508 certificate being rejected as revoked. Relying parties must ensure 1509 that the software they use to validate certificates issued under 1510 this policy verifies that the same key was used to sign both the 1511 certificate and the corresponding CRL, as specified in [RFCyyyy]. 1513 11. IANA Considerations 1515 None. 1517 12. Acknowledgments 1519 The authors would like to thank Geoff Huston, Randy Bush, Andrei 1520 Robachevsky and other members of the RPKI community for reviewing 1521 this document and Matt Lepinski for his help with the formatting. 1523 13. References 1525 13.1. Normative References 1527 [ARCH] Lepinski M., Kent S., "An Infrastructure to Support Secure 1528 Internet Routing," work in progress. 1530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1531 Requirement Levels," BCP 14, RFC 2119, March 1997. 1533 [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3," 1534 BCP 9, RFC 2026, October 1996. 1536 [RFC3779] Lynn, C., Kent, S., Seo, K., "X.509 Extensions for IP 1537 Addresses and AS Identifiers," RFC 3779, June 2004. 1539 [RFCwwww] Huston, G., Loomans, R., and Michaelson, G., "A Profile for 1540 Resource Certificate Repository Structure," work in progress. 1542 [RFCxxxx] Huston, G., Michaelson, G., Kent, S., "CA Key Rollover in 1543 the RPKI," work in progress. 1545 [RFCyyyy] Huston, G., Michaelson, G., Loomans, R., "A Profile for 1546 X.509 PKIX Resource Certificates," work in progress. 1548 [RFCzzzz] Huston, G., "A Profile for Algorithms and Key Sizes for use 1549 in the Resource Public Key Infrastructure," work in progress. 1551 13.2. Informative References 1553 [PROV] Huston, G., Loomans, R., Ellacott, B., Austein, R., "A Protocol 1554 for Provisioning Resource Certificates," work in progress. 1556 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., Wu, S., 1557 "Internet X.509 Public Key Infrastructure Certificate Policy and 1558 Certification Practices Framework," RFC 3647, November 2003. 1560 Authors' Addresses: 1562 Stephen Kent 1563 BBN Technologies 1564 10 Moulton Street 1565 Cambridge MA 02138 1566 USA 1568 Phone: +1 (617) 873-3988 1569 Email: skent@bbn.com 1571 Derrick Kong 1572 BBN Technologies 1573 Moulton Street 1574 Cambridge MA 02138 1575 USA 1577 Phone: +1 (617) 873-1951 1578 Email: dkong@bbn.com 1580 Karen Seo 1581 BBN Technologies 1582 10 Moulton Street 1583 Cambridge MA 02138 1584 USA 1586 Phone: +1 (617) 873-3152 1587 Email: kseo@bbn.com 1589 Ronald Watro 1590 BBN Technologies 1591 10 Moulton Street 1592 Cambridge MA 02138 1593 USA 1595 Phone: +1 (617) 873-2551 1596 Email: rwatro@bbn.com 1598 Pre-5378 Material Disclaimer 1600 This document may contain material from IETF Documents or IETF 1601 Contributions published or made publicly available before November 1602 10, 2008. The person(s) controlling the copyright in some of this 1603 material may not have granted the IETF Trust the right to allow 1604 modifications of such material outside the IETF Standards Process. 1605 Without obtaining an adequate license from the person(s) controlling 1606 the copyright in such materials, this document may not be modified 1607 outside the IETF Standards Process, and derivative works of it may 1608 not be created outside the IETF Standards Process, except to format 1609 it for publication as an RFC or to translate it into languages other 1610 than English. 1612 Copyright Statement 1614 Copyright (c) 2010 IETF Trust and the persons identified as the 1615 document authors. All rights reserved. 1617 This document is subject to BCP 78 and the IETF Trust's Legal 1618 Provisions Relating to IETF Documents 1619 (http://trustee.ietf.org/license-info) in effect on the date of 1620 publication of this document. Please review these documents 1621 carefully, as they describe your rights and restrictions with 1622 respect to this document. Code Components extracted from this 1623 document must include Simplified BSD License text as described in 1624 Section 4.e of the Trust Legal Provisions and are provided without 1625 warranty as described in the Simplified BSD License.