idnits 2.17.1 draft-ietf-sidr-cps-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 : ---------------------------------------------------------------------------- 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 date (April 2014) is 3656 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: 'OMITTED' is mentioned on line 1478, but not defined ** Obsolete normative reference: RFC 6485 (Obsoleted by RFC 7935) -- Obsolete informational reference (is this intentional?): RFC 6486 (Obsoleted by RFC 9286) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 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: October 2014 Seo, K. 4 Intended Status: BCP BBN Technologies 5 April 2014 7 Template for a Certification Practice Statement (CPS) for the 8 Resource PKI (RPKI) 9 draft-ietf-sidr-cps-04.txt 11 Abstract 13 This document contains a template to be used for creating a 14 Certification Practice Statement (CPS) for an Organization that is 15 part of the Resource Public Key Infrastructure (RPKI), e.g., a 16 resource allocation registry or an ISP. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with 21 the provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on October 31,2014. 40 Table of Contents 42 Preface...........................................................7 43 1. Introduction...................................................8 44 1.1. Overview..................................................8 45 1.2. Document Name and Identification..........................9 46 1.3. PKI Participants..........................................9 47 1.3.1. Certification Authorities............................9 48 1.3.2. Registration Authorities............................10 49 1.3.3. Subscribers.........................................10 50 1.3.4. Relying Parties.....................................10 51 1.3.5. Other Participants..................................10 52 1.4. Certificate Usage........................................10 53 1.4.1. Appropriate Certificate Uses........................10 54 1.4.2. Prohibited Certificate Uses.........................11 55 1.5. Policy Administration....................................11 56 1.5.1. Organization administering the document.............11 57 1.5.2. Contact Person......................................11 58 1.5.3. Person Determining CPS Suitability for the Policy...11 59 1.5.4. CPS Approval Procedures.............................11 60 1.6. Definitions and Acronyms.................................11 61 2. Publication and Repository Responsibilities...................14 62 2.1. Repositories.............................................14 63 2.2. Publication of Certification Information.................14 64 2.3. Time or Frequency of Publication.........................14 65 2.4. Access Controls on Repositories..........................14 66 3. Identification And Authentication.............................15 67 3.1. Naming...................................................15 68 3.1.1. Types of Names......................................15 69 3.1.2. Need for Names to be Meaningful.....................15 70 3.1.3. Anonymity or Pseudonymity of Subscribers............15 71 3.1.4. Rules for Interpreting Various Name Forms...........15 72 3.1.5. Uniqueness of Names.................................15 73 3.1.6. Recognition, Authentication, and Role of Rrademarks.16 74 3.2. Initial Identity Validation..............................16 75 3.2.1. Method to Prove Possession of Private Key...........16 76 3.2.2. Authentication of Organization Identity.............16 77 3.2.3. Authentication of Individual Identity...............16 78 3.2.4. Non-verified Subscriber Information.................17 79 3.2.5. Validation of Authority.............................17 80 3.2.6. Criteria for Interoperation.........................17 81 3.3. Identification and Authentication for Re-key Requests....17 82 3.3.1. Identification and Authentication for Routine Re-key17 83 3.3.2. Identification and Authentication for Re-key after 84 Revocation.................................................18 85 3.4. Identification and Authentication for Revocation Request.18 86 4. Certificate Life-Cycle Operational Requirements...............19 87 4.1. Certificate Application..................................19 88 4.1.1. Who Can Submit a Certificate Application............19 89 4.1.2. Enrollment Process and Responsibilities.............19 90 4.2. Certificate Application Processing.......................19 91 4.2.1. Performing Identification and Authentication Functions19 92 4.2.2. Approval or Rejection of Certificate Applications...19 93 4.2.3. Time to Process Certificate Applications............20 94 4.3. Certificate Issuance.....................................20 95 4.3.1. CA Actions During Certificate Issuance..............20 96 4.3.2. Notification to Subscriber by the CA of Issuance of 97 Certificate................................................20 98 4.3.3. Notification of Certificate Issuance by the CA to Other 99 Entities...................................................20 100 4.4. Certificate Acceptance...................................20 101 4.4.1. Conduct Constituting Certificate Acceptance.........20 102 4.4.2. Publication of the Certificate by the CA............20 103 4.4.3. Notification of Certificate Issuance by the CA to Other 104 Entities...................................................21 105 4.5. Key Pair and Certificate Usage...........................21 106 4.5.1. Subscriber Private Key and Certificate Usage........21 107 4.5.2. Relying Party Public Key and Certificate Usage......21 108 4.6. Certificate Renewal......................................21 109 4.6.1. Circumstance for Certificate Renewal................21 110 4.6.2. Who May Request Renewal.............................22 111 4.6.3. Processing Certificate Renewal Requests.............22 112 4.6.4. Notification of New Certificate Issuance to Subscriber22 113 4.6.5. Conduct Constituting Acceptance of a Renewal Certificate 114 ...........................................................22 115 4.6.6. Publication of the Renewal Certificate by the CA....22 116 4.6.7. Notification of Certificate Issuance by the CA to Other 117 Entities...................................................22 118 4.7. Certificate Re-key.......................................23 119 4.7.1. Circumstance for Certificate Re-key.................23 120 4.7.2. Who May Request Certification of a New Public Key...23 121 4.7.3. Processing Certificate Re-keying Requests...........23 122 4.7.4. Notification of New Certificate Issuance to Subscriber23 123 4.7.5. Conduct Constituting Acceptance of a Re-keyed 124 Certificate................................................23 125 4.7.6. Publication of the Re-keyed Certificate by the CA...24 126 4.7.7. Notification of Certificate Issuance by the CA to Other 127 Entities...................................................24 128 4.8. Certificate Modification.................................24 129 4.8.1. Circumstance for Certificate Modification...........24 130 4.8.2. Who May Request Certificate modification............24 131 4.8.3. Processing Certificate Modification Requests........24 132 4.8.4. Notification of Modified Certificate Issuance to 133 Subscriber.................................................25 134 4.8.5. Conduct Constituting Acceptance of Modified Certificate 135 ...........................................................25 136 4.8.6. Publication of the Modified Certificate by the CA...25 137 4.8.7. Notification of Certificate Issuance by the CA to Other 138 Entities...................................................25 140 4.9. Certificate Revocation and Suspension....................25 141 4.9.1. Circumstances for Revocation........................25 142 4.9.2. Who Can Request Revocation..........................25 143 4.9.3. Procedure for Revocation Request....................26 144 4.9.4. Revocation Request Grace Period.....................26 145 4.9.5. Time Within Which CA Must Process the Revocation Request 146 ...........................................................26 147 4.9.6. Revocation Checking Requirement for Relying Parties.26 148 4.9.7. CRL Issuance Frequency..............................26 149 4.9.8. Maximum Latency for CRLs............................26 150 4.10. Certificate Status Services.............................26 151 5. Facility, Management, and Operational Controls ................27 152 5.1. Physical Controls........................................27 153 5.1.1. Site location and construction......................27 154 5.1.2. Physical access.....................................27 155 5.1.3. Power and air conditioning..........................27 156 5.1.4. Water exposures.....................................27 157 5.1.5. Fire prevention and protection......................27 158 5.1.6. Media storage.......................................27 159 5.1.7. Waste disposal......................................27 160 5.1.8. Off-site backup.....................................27 161 5.2. Procedural Controls......................................27 162 5.2.1. Trusted roles.......................................27 163 5.2.2. Number of persons required per task.................27 164 5.2.3. Identification and authentication for each role.....27 165 5.2.4. Roles requiring separation of duties................27 166 5.3. Personnel Controls.......................................27 167 5.3.1. Qualifications, experience, and clearance requirements28 168 5.3.2. Background check procedures.........................28 169 5.3.3. Training requirements...............................28 170 5.3.4. Retraining frequency and requirements...............28 171 5.3.5. Job rotation frequency and sequence.................28 172 5.3.6. Sanctions for unauthorized actions..................28 173 5.3.7. Independent contractor requirements.................28 174 5.3.8. Documentation supplied to personnel.................28 175 5.4. Audit Logging Procedures.................................28 176 5.4.1. Types of Events Recorded............................28 177 5.4.2. Frequency of Processing Log.........................29 178 5.4.3. Retention Period for Audit Log......................29 179 5.4.4. Protection of Audit Log.............................29 180 5.4.5. Audit Log Backup Procedures.........................29 181 5.4.6. Audit Collection System (Internal vs. External) 182 [OMITTED]..................................................29 183 5.4.7. Notification to Event-causing Subject [OMITTED].....29 184 5.4.8. Vulnerability Assessments...........................29 185 5.5. Records Archival [OMITTED]...............................29 186 5.6. Key Changeover...........................................29 187 5.7. Compromise and Disaster Recovery.........................29 188 5.8. CA or RA Termination.....................................30 189 6. Technical Security Controls...................................31 190 6.1. Key Pair Generation and Installation.....................31 191 6.1.1. Key Pair Generation.................................31 192 6.1.2. Private Key Delivery to Subscriber..................31 193 6.1.3. Public Key Delivery to Certificate Issuer...........31 194 6.1.4. CA Public Key Delivery to Relying Parties...........31 195 6.1.5. Key Sizes...........................................31 196 6.1.6. Public Key Parameters Generation and Quality Checking32 197 6.1.7. Key Usage Purposes (as per X.509 v3 Key Usage Field)32 198 6.2. Private Key Protection and Cryptographic Module Engineering 199 Controls......................................................32 200 6.2.1. Cryptographic module standards and controls.........32 201 6.2.2. Private Key (n out of m) Multi-Person Control.......32 202 6.2.3. Private Key Escrow..................................32 203 6.2.4. Private Key Backup..................................32 204 6.2.5. Private Key Archival................................33 205 6.2.6. Private Key Transfer into or from a Cryptographic Module 206 ...........................................................33 207 6.2.7. Private Key Storage on Cryptographic Module.........33 208 6.2.8. Method of Activating Private Key....................33 209 6.2.9. Method of Deactivating Private Key..................33 210 6.2.10. Method of Destroying Private Key...................33 211 6.2.11. Cryptographic Module Rating........................33 212 6.3. Other aspects of Key Pair Management.....................33 213 6.3.1. Public Key Archival.................................33 214 6.3.2. Certificate Operational Periods and Key Pair Usage 215 Periods....................................................34 216 6.4. Activation data..........................................34 217 6.4.1. Activation Data Generation and Installation.........34 218 6.4.2. Activation data protection..........................34 219 6.4.3. Other Aspects of Activation Data....................34 220 6.5. Computer Security Controls...............................34 221 6.6. Life cycle Technical Controls............................34 222 6.6.1. System Development Controls.........................34 223 6.6.2. Security Management Controls........................34 224 6.6.3. Life Cycle Security Controls........................35 225 6.7. Network Security Controls................................35 226 6.8. Time-stamping............................................35 227 7. Certificate and CRL Profiles..................................36 228 8. Compliance Audit and Other Assessments........................37 229 9. Other Business And Legal Matters..............................38 230 9.1. Fees.....................................................38 231 9.1.1. Certificate issuance or renewal fees................38 232 9.1.2. Fees for other services (if applicable).............38 233 9.1.3. Refund policy.......................................38 235 9.2. Financial responsibility.................................38 236 9.2.1. Insurance coverage..................................38 237 9.2.2. Other assets........................................38 238 9.2.3. Insurance or warranty coverage for end-entities.....38 239 9.3. Confidentiality of business information..................38 240 9.3.1. Scope of confidential information...................38 241 9.3.2. Information not within the scope of confidential 242 information................................................38 243 9.3.3. Responsibility to protect confidential information..38 244 9.4. Privacy of personal information..........................39 245 9.4.1. Privacy plan........................................39 246 9.4.2. Information treated as private......................39 247 9.4.3. Information not deemed private......................39 248 9.4.4. Responsibility to protect private information.......39 249 9.4.5. Notice and consent to use private information.......39 250 9.4.6. Disclosure pursuant to judicial or administrative 251 process....................................................39 252 9.4.7. Other information disclosure circumstances..........39 253 9.5. Intellectual property rights (if applicable).............39 254 9.6. Representations and warranties...........................39 255 9.6.1. CA representations and warranties...................39 256 9.6.2. Subscriber representations and warranties...........39 257 9.6.3. Relying party representations and warranties........39 258 9.7. Disclaimers of warranties................................39 259 9.8. Limitations of liability.................................39 260 9.9. Indemnities..............................................39 261 9.10. Term and termination....................................39 262 9.10.1. Term...............................................39 263 9.10.2. Termination........................................39 264 9.10.3. Effect of termination and survival.................39 265 9.11. Individual notices and communications with participants.39 266 9.12. Amendments..............................................39 267 9.12.1. Procedure for amendment............................39 268 9.12.2. Notification mechanism and period..................39 269 9.13. Dispute resolution provisions...........................40 270 9.14. Governing law...........................................40 271 9.15. Compliance with applicable law..........................40 272 9.16. Miscellaneous provisions................................40 273 9.16.1. Entire agreement...................................40 274 9.16.2. Assignment.........................................40 275 9.16.3. Severability.......................................40 276 9.16.4. Enforcement (attorneys' fees and waiver of rights).40 277 9.16.5. Force Majeure......................................40 278 10. Security Considerations......................................41 279 11. IANA Considerations..........................................41 280 12. Acknowledgments..............................................41 281 13. References...................................................42 282 13.1. Normative References....................................42 283 13.2. Informative References..................................42 284 Author's Addresses...............................................43 285 Copyright Statement..............................................43 287 Preface 289 This document contains a template to be used for creating a 290 Certification Practice Statement (CPS) for an Organization that is 291 part of the Resource Public Key Infrastructure (RPKI). (Throughout 292 this document the term "organization" is used broadly, e.g., the 293 entity in question might be a business unit of a larger 294 organization.) The user of this document should: 296 1. substitute a title page for page 1 saying, e.g., " Certification Practice Statement for the Resource 298 Public Key Infrastructure (RPKI)" with date, author, etc. There 299 is no expectation that a CPS will be published as an RFC. 301 2. leave the table of contents intact 303 3. delete this Preface, headers and footers (but keep page numbers) 305 4. fill in the information indicated below by 308 5. delete sections 10, 11, Acknowledgments, Author's Addresses, and 309 Copyright Statement; leaving a reference section (omitting RFC 310 2119) 312 6. update the table of contents to reflect the changes required by 313 steps 4 and 5 above . 315 This document has been generated to complement the Certificate Policy 316 (CP) for the RPKI [RFC6484]. Like the RFC 6484, it is based on the 317 template specified in RFC 3647 [RFC3647]. A number of sections 318 contained in the template were omitted from this CPS because they did 319 not apply to this PKI. However, we have retained the section 320 numbering scheme employed in the RFC to facilitate comparison with 321 the section numbering scheme employed in that RFC and in the RFC 322 6484. 324 Conventions used in this document 326 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 327 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 328 document are to be interpreted as described in [RFC2119]. 330 1. Introduction 332 This document is the Certification Practice Statement (CPS) of . It describes the practices employed by the Certification Authority (CA) in the Resource Public 335 Key Infrastructure (RPKI). These practices are defined in 336 accordance with the requirements of the Certificate Policy (CP, 337 [RFC6484]) for the RPKI. 339 The RPKI is designed to support validation of claims by current 340 holders of Internet Number Resources (INRs, see definition in Section 341 1.6) in accordance with the records of the organizations that act as 342 CAs in this PKI. The ability to verify such claims is essential to 343 ensuring the unique, unambiguous distribution of these resources 345 This PKI parallels the existing INR distribution hierarchy. These 346 resources are distributed by the Internet Assigned Numbers Authority 347 (IANA) to the Regional Internet Registries. In some regions, National 348 Internet Registries (NIRs) form a tier of the hierarchy below the 349 RIRs for internet number resource (INR) distribution. Internet 350 Service Providers (ISPs) and network subscribers form additional 351 tiers below registries. 353 1.1. Overview 355 This CPS describes: 357 . Participants 359 . Publication of the certificates and CRLs 361 . How certificates are issued, managed, rekeyed, renewed and revoked 363 . Facility management (physical security, personnel, audit, etc.) 365 . Key management 367 . Audit procedures 368 . Business and legal issues 370 This PKI encompasses several types of certificates (see [RFC6480] for 371 more details): 373 . CA certificates for each organization distributing INRs and for 374 each subscriber INR holder) 376 . End entity (EE) certificates for organizations to use to validate 377 digital signatures on RPKI-signed objects (see definition in 378 Section 1.6). 380 . In the future, the PKI also may include end entity certificates in 381 support of access control for the repository system as described in 382 Section 2.4. 384 1.2. Document Name and Identification 386 The name of this document is "'s Certification 387 Practice Statement for the Resource Public Key Infrastructure (RPKI) 388 ". 393 1.3. PKI Participants 395 Note that in a PKI, the term "subscriber" refers to an individual or 396 organization that is a subject of a certificate issued by a CA. The 397 term is used in this fashion throughout this document, without 398 qualification, and should not be confused with the networking use of 399 the term to refer to an individual or organization that receives 400 service from an ISP. In such cases the term "network subscriber" will 401 be used. Also note that, for brevity, this document always refers to 402 PKI participants as organizations or entities, even though some of 403 them are individuals. 405 1.3.1. Certification Authorities 407 portion of the RPKI. It provides a secure 411 revocation and recovery capability in case the production CA is 412 compromised or becomes unavailable. Thus the offline CA issues 413 certificates only to instances of the production CA; and the CRLs it 414 issues are used to revoke only certificates issued to the production 415 CA. The production CA is used to issue RPKI certificates to members, to whom INRs have been distributed.> 418 1.3.2. Registration Authorities 420 430 1.3.3. Subscribers 432 Organizations receiving INR allocations from this CA are subscribers 433 in the RPKI. 435 1.3.4. Relying Parties 437 Entities or individuals that act in reliance on certificates or RPKI- 438 signed objects issued under this PKI are relying parties. Relying 439 parties may or may not be subscribers within this PKI. (See Section 440 1.6 for the definition of an RPKI-signed object.) 442 1.3.5. Other Participants 444 448 1.4. Certificate Usage 450 1.4.1. Appropriate Certificate Uses 452 The certificates issued under this hierarchy are for authorization in 453 support of validation of claims of current holdings of INRs. 455 Additional uses of the certificates, consistent with the basic goal 456 cited above, are also permitted under RFC 6484. 458 Some of the certificates that may be issued under this PKI could be 459 used to support operation of this infrastructure, e.g., access 460 control for the repository system as described in Section 2.4. Such 461 uses also are permitted under the RPKI certificate policy. 463 1.4.2. Prohibited Certificate Uses 465 Any uses other than those described in Section 1.4.1 are prohibited. 467 1.5. Policy Administration 469 1.5.1. Organization administering the document 471 This CPS is administered by . 474 1.5.2. Contact Person 476 478 1.5.3. Person Determining CPS Suitability for the Policy 480 Not applicable. Each organization issuing a certificate in this PKI 481 is attesting to the distribution of INRs to the holder of the private 482 key corresponding to the public key in the certificate. The issuing 483 organizations are the same organizations as the ones that perform the 484 distribution hence they are authoritative with respect to the 485 accuracy of this binding. 487 1.5.4. CPS Approval Procedures 489 Not applicable. Each organization issuing a certificate in this PKI 490 is attesting to the distribution of INRs to the holder of the private 491 key corresponding to the public key in the certificate. The issuing 492 organizations are the same organizations as the ones that perform the 493 distribution, hence they are authoritative with respect to the 494 accuracy of this binding. 496 1.6. Definitions and Acronyms 498 BPKI Business PKI: A BPKI is an optional additional PKI used by an 499 Organization to identify members to whom RPKI certificates can 500 be issued. If a BPKI is employed by a CA, it may have its own 501 CP, separate from the RPKI CP. 503 CP Certificate Policy. A CP is a named set of rules that indicates 504 the applicability of a certificate to a particular community 505 and/or class of applications with common security requirements. 506 The CP for the RPKI is [RFC6484]. 508 CPS Certification Practice Statement. A CPS is a document that 509 specifies the practices that a Certification Authority employs 510 in issuing certificates. 512 Distribution of INRs A process of distribution of the INRs along 513 the respective number hierarchy. IANA distributes blocks of IP 514 addresses and Autonomous System Numbers to the five Regional 515 Internet Registries (RIRs). RIRs distribute smaller address 516 blocks and Autonomous System Numbers to organizations within 517 their service regions, who in turn distribute IP addresses to 518 their customers. 520 IANA Internet Assigned Numbers Authority. IANA is responsible for 521 global coordination of the Internet Protocol addressing systems 522 and Autonomous System (AS) numbers used for routing internet 523 traffic. IANA distributes INRs to Regional Internet Registries 524 (RIRs). 526 INRs Internet Number Resources. INRs are number values for three 527 protocol parameter sets, namely: 528 . IP Version 4 addresses, 530 . IP version 6 addresses, and 532 . Identifiers used in Internet inter-domain routing, currently 533 Border Gateway Protocol-4 Autonomous System numbers. 535 ISP Internet Service Provider. An ISP is an organization managing 536 and selling Internet services to other organizations. 538 NIR National Internet Registry. An NIR is an organization that 539 manages the distribution of INRs for a portion of the 540 geopolitical area covered by a Regional Registry. NIRs form an 541 optional second tier in the tree scheme used to manage INR 542 distribution. 544 RIR Regional Internet Registry. An RIR is an organization that 545 manages the distribution of INRs for a geopolitical area. 547 RPKI-signed object An RPKI signed object is a digitally signed data 548 object (other than a certificate or CRL) declared to be such by 549 a standards track RFC, and that can be validated using 550 certificates issued under this PKI. The content and format of 551 these data constructs depend on the context in which validation 552 of claims of current holdings of INRs takes place. Examples of 553 these objects are repository manifests [RFC6486] and Route 554 Origin Authorizations (ROAs) [RFC6482]. 556 2. Publication and Repository Responsibilities 558 2.1. Repositories 560 As per the CP, certificates, CRLs and RPKI-signed objects MUST be 561 made available for downloading by all relying parties, to enable them 562 to validate this data. 564 The RPKI CA will publish certificates, CRLs, 565 and RPKI-signed objects via a repository that is accessible via 566 at . 567 This repository will conform to the structure described in [RFC6481]. 569 2.2. Publication of Certification Information 571 will publish certificates, CRLs and RPKI- 572 signed objects issued by it to a repository that operates as part of 573 a worldwide distributed system of RPKI repositories. 575 2.3. Time or Frequency of Publication 577 586 The CA will publish its CRL prior to the 587 nextUpdate value in the scheduled CRL previously issued by the CA. 589 2.4. Access Controls on Repositories 591 598 3. Identification And Authentication 600 3.1. Naming 602 3.1.1. Types of Names 604 The subject of each certificate issued by this Organization is 605 identified by an X.500 Distinguished Name (DN). The distinguished 606 name will consist of a single Common Name (CN) attribute with a 607 value generated by . Optionally, the 608 serialNumber attribute may be included along with the common name 609 (to form a terminal relative distinguished name set), to distinguish 610 among successive instances of certificates associated with the same 611 entity. 613 3.1.2. Need for Names to be Meaningful 615 The Subject name in each certificate SHOULD NOT be "meaningful," in 616 the conventional, human-readable sense. The rationale here is that 617 these certificates are used for authorization in support of 618 applications that make use of attestations of INR holdings. They are 619 not used to identify subjects. 621 3.1.3. Anonymity or Pseudonymity of Subscribers 623 Although Subject names in certificates issued by this Organization 624 SHOULD NOT be meaningful, and may appear "random," anonymity is not a 625 function of this PKI; thus no explicit support for this feature is 626 provided. 628 3.1.4. Rules for Interpreting Various Name Forms 630 None 632 3.1.5. Uniqueness of Names 634 certifies subject names that are unique among 635 the certificates that it issues. Although it is desirable that these 636 subject names be unique throughout the PKI, to facilitate certificate 637 path discovery, such uniqueness is neither mandated nor enforced 638 through technical means. generates subject 639 names to minimize the chances that two entities in the RPKI will be 640 assigned the same name. Specifically, 642 3.1.6. Recognition, Authentication, and Role of Trademarks 644 Because the Subject names are not intended to be meaningful, makes no provision to either recognize or authenticate 646 trademarks, service marks, etc. 648 3.2. Initial Identity Validation 650 3.2.1. Method to Prove Possession of Private Key 652 657 3.2.2. Authentication of Organization Identity 659 Certificates issued under this PKI do not attest to the 660 organizational identity of subscribers. However, certificates are 661 issued to subscribers in a fashion that preserves the accuracy of 662 distributions of INRs as represented in 663 records. 665 subscriber 671 database that maintains the INR distribution records. The certificate 672 request could be matched against the database record for the 673 subscriber in question, and an RPKI certificate would be issued only 674 if the INRs requested were a subset of those held by the subscriber. 675 The specific procedures employed for this purpose should be 676 commensurate with any you already employ in the maintenance of INR 677 distribution.> 679 3.2.3. Authentication of Individual Identity 681 Certificates issued under this PKI do not attest to the individual 682 identity of a subscriber. However, maintains 683 contact information for each subscriber in support of certificate 684 renewal, re-key, and revocation. 686 BPKI (see Section 3.2.6) issues certificates that MUST 691 be used to identify individuals who represent 692 subscribers." The procedures should be commensurate with those you 693 already employ in authenticating individuals as representatives for 694 INR holders. Note that this authentication is solely for use by you 695 in dealing with the organizations to which you distribute (or sub- 696 distribute) INRs, and thus MUST NOT be relied upon outside of this 697 CA/subscriber relationship.> 699 3.2.4. Non-verified Subscriber Information 701 No non-verified subscriber data is included in certificates issued 702 under this certificate policy except for Subject Information Access 703 (SIA) extensions [RFC6487]. 705 3.2.5. Validation of Authority 707 716 3.2.6. Criteria for Interoperation 718 The RPKI is neither intended nor designed to interoperate with any 719 other PKI. 724 3.3. Identification and Authentication for Re-key Requests 726 3.3.1. Identification and Authentication for Routine Re-key 728 735 3.3.2. Identification and Authentication for Re-key after 736 Revocation 738 747 3.4. Identification and Authentication for Revocation Request 749 759 4. Certificate Life-Cycle Operational Requirements 761 4.1. Certificate Application 763 4.1.1. Who Can Submit a Certificate Application 765 Any subscriber in good standing who holds INRs distributed by may submit a certificate application to this CA. 768 4.1.2. Enrollment Process and Responsibilities 770 778 4.2. Certificate Application Processing 780 784 4.2.1. Performing Identification and Authentication Functions 786 792 4.2.2. Approval or Rejection of Certificate Applications 794 803 4.2.3. Time to Process Certificate Applications 805 808 4.3. Certificate Issuance 810 4.3.1. CA Actions During Certificate Issuance 812 815 4.3.2. Notification to Subscriber by the CA of Issuance of 816 Certificate 818 will notify the subscriber when the 819 certificate is published. 822 4.3.3. Notification of Certificate Issuance by the CA to Other 823 Entities 825 828 4.4. Certificate Acceptance 830 4.4.1. Conduct Constituting Certificate Acceptance 832 When a certificate is issued, the CA will 833 publish it to the repository and notify the subscriber. 837 4.4.2. Publication of the Certificate by the CA 839 Certificates will be published at once 840 issued, following the conduct described in Section 4.4.1. This will 841 be done within . 845 4.4.3. Notification of Certificate Issuance by the CA to Other 846 Entities 848 851 4.5. Key Pair and Certificate Usage 853 A summary of the use model for the RPKI is provided below. 855 4.5.1. Subscriber Private Key and Certificate Usage 857 The certificates issued by to subordinate INR 858 holders are CA certificates. The private key associated with each of 859 these certificates is used to sign subordinate (CA or EE) 860 certificates and CRLs. 862 4.5.2. Relying Party Public Key and Certificate Usage 864 The primary relying parties in this PKI are organizations that use 865 RPKI EE certificates to verify RPKI-signed objects. Relying parties 866 are referred to Section 4.5.2 of [RFC6484] for additional guidance 867 with respect to acts of reliance on RPKI certificates. 869 4.6. Certificate Renewal 871 4.6.1. Circumstance for Certificate Renewal 873 As per RFC 6484, a certificate will be processed for renewal based on 874 its expiration date or a renewal request from the certificate 875 subject. The request may be implicit, a side effect of renewing a 876 resource holding agreement, or may be explicit. If initiates the renewal process based on the certificate 878 expiration date, then will notify the 879 subscriber The validity 882 interval of the new (renewed) certificate will overlap that of the 883 previous certificate by , to ensure uninterrupted coverage. 886 Certificate renewal will incorporate the same public key as the 887 previous certificate, unless the private key has been reported as 888 compromised (see Section 4.9.3). If a new key pair is being used, 889 the stipulations of Section 4.7 will apply. 891 4.6.2. Who May Request Renewal 893 The subscriber or may initiate the renewal 894 process. 906 4.6.3. Processing Certificate Renewal Requests 908 912 4.6.4. Notification of New Certificate Issuance to Subscriber 914 will notify the subscriber when the 915 certificate is published. 919 4.6.5. Conduct Constituting Acceptance of a Renewal Certificate 921 See Section 4.4.1 924 4.6.6. Publication of the Renewal Certificate by the CA 926 See Section 4.4.2. 928 4.6.7. Notification of Certificate Issuance by the CA to Other 929 Entities 931 See Section 4.4.3. 933 4.7. Certificate Re-key 935 4.7.1. Circumstance for Certificate Re-key 937 As per RFC 6484, re-key of a certificate will be performed only when 938 required, based on: 940 1. knowledge or suspicion of compromise or loss of the associated 941 private key, or 943 2. the expiration of the cryptographic lifetime of the associated key 944 pair 946 If a certificate is revoked to replace the RFC 3779 extensions, the 947 replacement certificate will incorporate the same public key, not a 948 new key. 950 If the re-key is based on a suspected compromise, then the previous 951 certificate will be revoked. 953 4.7.2. Who May Request Certification of a New Public Key 955 Only the holder of a certificate may request a re-key. In addition, 956 may initiate a re-key based on a verified 957 compromise report. BPKI. Describe how a compromise report received 960 from other than a subscriber is verified.> 962 4.7.3. Processing Certificate Re-keying Requests 964 968 4.7.4. Notification of New Certificate Issuance to Subscriber 970 975 4.7.5. Conduct Constituting Acceptance of a Re-keyed Certificate 977 When a re-keyed certificate is issued, the CA will publish it in the 978 repository and notify the subscriber. See Section 4.4.1. 980 4.7.6. Publication of the Re-keyed Certificate by the CA 982 986 4.7.7. Notification of Certificate Issuance by the CA to Other 987 Entities 989 See Section 4.4.3. 991 4.8. Certificate Modification 993 4.8.1. Circumstance for Certificate Modification 995 As per RFC 6484, modification of a certificate occurs to implement 996 changes to the RFC 3779 extension values or the SIA extension in a 997 certificate. A subscriber can request a certificate modification 998 when this information in a currently valid certificate has changed, 999 as a result of changes in the INR holdings of the subscriber or a 1000 change of the repository publication point data. 1002 If a subscriber is to receive a distribution of INRs in addition to a 1003 current distribution, and if the subscriber does not request that a 1004 new certificate be issued containing only these additional INRs, then 1005 this is accomplished through a certificate modification. When a 1006 certificate modification is approved, a new certificate is issued. 1007 The new certificate will contain the same public key and the same 1008 expiration date as the original certificate, but with the incidental 1009 information corrected and/or the INR distribution expanded. When 1010 previously distributed INRs are to be removed from a certificate, 1011 then the old certificate will be revoked and a new certificate 1012 (reflecting the new distribution) issued. 1014 4.8.2. Who May Request Certificate modification 1016 The subscriber or may initiate the certificate 1017 modification process. 1021 4.8.3. Processing Certificate Modification Requests 1023 1027 4.8.4. Notification of Modified Certificate Issuance to 1028 Subscriber 1030 1035 4.8.5. Conduct Constituting Acceptance of Modified Certificate 1037 When a modified certificate is issued, will 1038 publish it to the repository and notify the subscriber. See Section 1039 4.4.1. 1041 4.8.6. Publication of the Modified Certificate by the CA 1043 1047 4.8.7. Notification of Certificate Issuance by the CA to Other 1048 Entities 1050 See Section 4.4.3. 1052 4.9. Certificate Revocation and Suspension 1054 4.9.1. Circumstances for Revocation 1056 As per RFC 6484, certificates can be revoked for several reasons. 1057 Either or the subject may choose to end the 1058 relationship expressed in the certificate, thus creating cause to 1059 revoke the certificate. If one or more of the INRs bound to the 1060 public key in the certificate are no longer associated with the 1061 subject, that too constitutes a basis for revocation. A certificate 1062 also may be revoked due to loss or compromise of the private key 1063 corresponding to the public key in the certificate. Finally, a 1064 certificate may be revoked in order to invalidate data signed by the 1065 private key associated with that certificate. 1067 4.9.2. Who Can Request Revocation 1069 The subscriber or may request a revocation. 1070 1073 4.9.3. Procedure for Revocation Request 1075 .> 1083 4.9.4. Revocation Request Grace Period 1085 A subscriber is required to request revocation as soon as possible 1086 after the need for revocation has been identified. 1088 4.9.5. Time Within Which CA Must Process the Revocation Request 1090 1093 4.9.6. Revocation Checking Requirement for Relying Parties 1095 As per RFC 6484, a relying party is responsible for acquiring and 1096 checking the most recent, scheduled CRL from the issuer of the 1097 certificate, whenever the relying party validates a certificate. 1099 4.9.7. CRL Issuance Frequency 1101 1102 Each CRL contains a nextUpdate value and a new CRL will be published 1103 at or before that time. will set the 1104 nextUpdate value when it issues a CRL, to signal when the next 1105 scheduled CRL will be issued. 1107 4.9.8. Maximum Latency for CRLs 1109 A CRL will be published to the repository system within after generation. 1112 4.10. Certificate Status Services 1114 does not support OCSP or SCVP. issues CRLs. 1117 5. Facility, Management, and Operational Controls 1119 5.1. Physical Controls 1121 1125 5.1.1. Site location and construction 1127 5.1.2. Physical access 1129 5.1.3. Power and air conditioning 1131 5.1.4. Water exposures 1133 5.1.5. Fire prevention and protection 1135 5.1.6. Media storage 1137 5.1.7. Waste disposal 1139 5.1.8. Off-site backup 1141 5.2. Procedural Controls 1143 1147 5.2.1. Trusted roles 1149 5.2.2. Number of persons required per task 1151 5.2.3. Identification and authentication for each role 1153 5.2.4. Roles requiring separation of duties 1155 5.3. Personnel Controls 1157 1161 5.3.1. Qualifications, experience, and clearance requirements 1163 5.3.2. Background check procedures 1165 5.3.3. Training requirements 1167 5.3.4. Retraining frequency and requirements 1169 5.3.5. Job rotation frequency and sequence 1171 5.3.6. Sanctions for unauthorized actions 1173 5.3.7. Independent contractor requirements 1175 5.3.8. Documentation supplied to personnel 1177 5.4. Audit Logging Procedures 1179 1182 5.4.1. Types of Events Recorded 1184 Audit records will be generated for the basic operations of the 1185 certification authority computing equipment. Audit records will 1186 include the date, time, responsible user or process, and summary 1187 content data relating to the event. Auditable events include: 1189 . Access to CA computing equipment (e.g., logon, logout) 1191 . Messages received requesting CA actions (e.g., certificate 1192 requests, certificate revocation requests, compromise 1193 notifications) 1195 . Certificate creation, modification, revocation, or renewal actions 1197 . Posting of any material to a repository 1199 . Any attempts to change or delete audit data 1201 . Key generation 1203 . Software and/or configuration updates to the CA 1204 . Clock adjustments 1206 1208 5.4.2. Frequency of Processing Log 1210 1212 5.4.3. Retention Period for Audit Log 1214 1216 5.4.4. Protection of Audit Log 1218 1220 5.4.5. Audit Log Backup Procedures 1222 1224 5.4.6. Audit Collection System (Internal vs. External) [OMITTED] 1226 5.4.7. Notification to Event-causing Subject [OMITTED] 1228 5.4.8. Vulnerability Assessments 1230 1235 5.5. Records Archival [OMITTED] 1237 5.6. Key Changeover 1239 The CA certificate will contain a validity 1240 period that is at least as long as that of any certificate being 1241 issued under that certificate. When CA 1242 changes keys it will follow the procedures described in [RFC6489]. 1244 5.7. Compromise and Disaster Recovery 1246 1250 5.8. CA or RA Termination 1252 1255 6. Technical Security Controls 1257 This section describes the security controls used by . 1260 6.1. Key Pair Generation and Installation 1262 6.1.1. Key Pair Generation 1264 1271 6.1.2. Private Key Delivery to Subscriber 1273 1278 6.1.3. Public Key Delivery to Certificate Issuer 1280 RPKI CA. These procedures 1282 MUST ensure that the public key has not been altered during transit 1283 and that the subscriber possesses the private key corresponding to 1284 the transferred public key.> See RFC 6487 for details. 1286 6.1.4. CA Public Key Delivery to Relying Parties 1288 CA public keys for all entities (other than trust anchors) are 1289 contained in certificates issued by other CAs and will be published 1290 to the RPKI repository system. Relying parties will download these 1291 certificates from this system. Public key values and associated data 1292 for (putative) trust anchors will be distributed out of band and 1293 accepted by relying parties on the basis of locally-defined criteria, 1294 e.g., embedded in path validation software that will be made 1295 available to the Internet community. 1297 6.1.5. Key Sizes 1299 The key sizes used in this PKI are as specified in [RFC6485]. 1301 6.1.6. Public Key Parameters Generation and Quality Checking 1303 The public key algorithms and parameters used in this PKI are as 1304 specified in [RFC6485]. 1306 is not responsible for performing such checks 1310 for subscribers OR describe the procedures used by the CA for 1311 checking the quality of these subscriber key pairs.> 1313 6.1.7. Key Usage Purposes (as per X.509 v3 Key Usage Field) 1315 The Key usage extension bit values employed in RPKI certificates are 1316 specified in [RFC6487]. 1318 6.2. Private Key Protection and Cryptographic Module Engineering 1319 Controls 1321 6.2.1. Cryptographic module standards and controls 1323 . 1327 6.2.2. Private Key (n out of m) Multi-Person Control 1329 out of multi-person 1332 control."> 1334 6.2.3. Private Key Escrow 1336 1339 6.2.4. Private Key Backup 1341 1346 6.2.5. Private Key Archival 1348 See sections 6.2.3 and 6.2.4 1350 6.2.6. Private Key Transfer into or from a Cryptographic Module 1352 The private key for 's production CA 1354 will be generated by the cryptographic module specified in 6.2.1. 1355 The private keys will never leave the module except in encrypted form 1356 for backup and/or transfer to a new module. 1357 6.2.7. Private Key Storage on Cryptographic Module 1359 The private key for 's production CA 1361 will be stored in the cryptographic module. It will be protected from 1362 unauthorized use . 1364 6.2.8. Method of Activating Private Key 1366 1369 6.2.9. Method of Deactivating Private Key 1371 1373 6.2.10. Method of Destroying Private Key 1375 1378 6.2.11. Cryptographic Module Rating 1380 1383 6.3. Other aspects of Key Pair Management 1385 6.3.1. Public Key Archival 1387 1390 6.3.2. Certificate Operational Periods and Key Pair Usage 1391 Periods 1393 The CA's key pair will have a validity 1394 interval of . 1400 6.4. Activation data 1402 6.4.1. Activation Data Generation and Installation 1404 1406 6.4.2. Activation data protection 1408 Activation data for the CA private key will be protected by . 1411 6.4.3. Other Aspects of Activation Data 1413 1416 6.5. Computer Security Controls 1418 1423 6.6. Life cycle Technical Controls 1425 6.6.1. System Development Controls 1427 1430 6.6.2. Security Management Controls 1432 1436 6.6.3. Life Cycle Security Controls 1438 1442 6.7. Network Security Controls 1444 1449 6.8. Time-stamping 1451 The RPKI does not make use of time stamping. 1453 7. Certificate and CRL Profiles 1455 See [RFC6487]. 1457 8. Compliance Audit and Other Assessments 1459 1463 9. Other Business And Legal Matters 1465 1472 9.1. Fees 1474 9.1.1. Certificate issuance or renewal fees 1476 9.1.2. Certificate access fees [OMITTED] 1478 9.1.3. Revocation or status information access fees [OMITTED] 1480 9.1.4. Fees for other services (if applicable) 1482 9.1.5. Refund policy 1484 9.2. Financial responsibility 1486 9.2.1. Insurance coverage 1488 9.2.2. Other assets 1490 9.2.3. Insurance or warranty coverage for end-entities 1492 9.3. Confidentiality of business information 1494 9.3.1. Scope of confidential information 1496 9.3.2. Information not within the scope of confidential 1497 information 1499 9.3.3. Responsibility to protect confidential information 1501 9.4. Privacy of personal information 1503 9.4.1. Privacy plan 1505 9.4.2. Information treated as private 1507 9.4.3. Information not deemed private 1509 9.4.4. Responsibility to protect private information 1511 9.4.5. Notice and consent to use private information 1513 9.4.6. Disclosure pursuant to judicial or administrative process 1515 9.4.7. Other information disclosure circumstances 1517 9.5. Intellectual property rights (if applicable) 1519 9.6. Representations and warranties 1521 9.6.1. CA representations and warranties 1523 9.6.2. Subscriber representations and warranties 1525 9.6.3. Relying party representations and warranties 1527 9.7. Disclaimers of warranties 1529 9.8. Limitations of liability 1531 9.9. Indemnities 1533 9.10. Term and termination 1535 9.10.1. Term 1537 9.10.2. Termination 1539 9.10.3. Effect of termination and survival 1541 9.11. Individual notices and communications with participants 1543 9.12. Amendments 1545 9.12.1. Procedure for amendment 1547 9.12.2. Notification mechanism and period 1549 9.13. Dispute resolution provisions 1551 9.14. Governing law 1553 9.15. Compliance with applicable law 1555 9.16. Miscellaneous provisions 1557 9.16.1. Entire agreement 1559 9.16.2. Assignment 1561 9.16.3. Severability 1563 9.16.4. Enforcement (attorneys' fees and waiver of rights) 1565 9.16.5. Force Majeure 1567 10. Security Considerations 1569 The degree to which a relying party can trust the binding embodied in 1570 a certificate depends on several factors. These factors can include 1571 the practices followed by the certification authority (CA) in 1572 authenticating the subject; the CA's operating policy, procedures, 1573 and technical security controls, including the scope of the 1574 subscriber's responsibilities (for example, in protecting the private 1575 key), and the stated responsibilities and liability terms and 1576 conditions of the CA (for example, warranties, disclaimers of 1577 warranties, and limitations of liability). This document provides a 1578 framework to address the technical, procedural, personnel, and 1579 physical security aspects of Certification Authorities, Registration 1580 Authorities, repositories, subscribers, and relying party 1581 cryptographic modules, in order to ensure that the certificate 1582 generation, publication, renewal, re-key, usage, and revocation is 1583 done in a secure manner. Specifically, Section 3 Identification and 1584 Authentication (I&A); Section 4 Certificate Life-Cycle Operational 1585 Requirements; Section 5 Facility Management, and Operational 1586 Controls; Section 6 Technical Security Controls; Section 7 1587 Certificate and CRL Profiles; and Section 8 Compliance Audit and 1588 Other Assessments are oriented towards ensuring secure operation of 1589 the PKI entities such as CA, RA, repository, subscriber systems, and 1590 relying party systems. 1592 11. IANA Considerations 1594 None. 1596 12. Acknowledgments 1598 The authors would like to thank Matt Lepinski for help with the 1599 formatting, Ron Watro for assistance with the editing, and other 1600 members of the SIDR working group for reviewing this document. 1602 13. References 1604 13.1. Normative References 1606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1607 Requirement Levels", BCP 14, RFC 2119, March 1997. 1609 [RFC6484] Kent, S., Kong, D., Seo, K., and Watro, R., "Certificate 1610 Policy (CP) for the Resource PKI (RPKI)," February 2012. 1612 [RFC6487] Huston, G., Michaelson, G., and Loomans, R., "A Profile for 1613 X.509 PKIX Resource Certificates," February 2012. 1615 [RFC6485] Huston, G., "A Profile for Algorithms and Key Sizes for Use 1616 in the Resource Public Key Infrastructure," February 2012. 1618 13.2. Informative References 1620 [FIPS] Federal Information Processing Standards Publication 140-3 1621 (FIPS-140-3), "Security Requirements for Cryptographic 1622 Modules", Information Technology Laboratory, National 1623 Institute of Standards and Technology, work in progress. 1625 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and Wu, 1626 S., "Internet X.509 Public Key Infrastructure Certificate 1627 Policy and Certification Practices Framework", RFC 3647, 1628 November 2003. 1630 [RFC6480] M. Lepinski, S. Kent, "An Infrastructure to Support Secure 1631 Internet Routing," February 2012. 1633 [RFC6481] G. Huston, R. Loomans, G. Michaelson, "A Profile for 1634 Resource Certificate Repository Structure," February 2012. 1636 [RFC6482] M. Lepinski, S. Kent, D. Kong, "A Profile for Route Origin 1637 Authorizations (ROAs)," February 2012. 1639 [RFC6486] R. Austein, G. Huston, S. Kent, M. Lepinski, "Manifests for 1640 the Resource Public Key Infrastructure (RPKI)," February 1641 2012. 1643 [RFC6489] G. Huston, G. Michaelson, S. Kent, "Certification Authority 1644 (CA) Key Rollover in the Resource Public Key Infrastructure 1645 (RPKI), February 2012. 1647 Author's Addresses 1649 Stephen Kent 1650 BBN Technologies 1651 10 Moulton Street 1652 Cambridge MA 02138 1653 USA 1655 Phone: +1 (617) 873-3988 1656 Email: skent@bbn.com 1658 Derrick Kong 1659 BBN Technologies 1660 10 Moulton Street 1661 Cambridge MA 02138 1662 USA 1664 Phone: +1 (617) 873-1951 1665 Email: dkong@bbn.com 1667 Karen Seo 1668 BBN Technologies 1669 10 Moulton Street 1670 Cambridge MA 02138 1671 USA 1673 Phone: +1 (617) 873-3152 1674 Email: kseo@bbn.com 1676 Copyright Statement 1678 Copyright (c) 2014 IETF Trust and the persons identified as the 1679 document authors. All rights reserved. 1681 This document is subject to BCP 78 and the IETF Trust's Legal 1682 Provisions Relating to IETF Documents 1683 (http://trustee.ietf.org/license-info) in effect on the date of 1684 publication of this document. Please review these documents 1685 carefully, as they describe your rights and restrictions with respect 1686 to this document. Code Components extracted from this document must 1687 include Simplified BSD License text as described in Section 4.e of 1688 the Trust Legal Provisions and are provided without warranty as 1689 described in the Simplified BSD License.