idnits 2.17.1 draft-ietf-sidr-cps-03.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 (October 2013) is 3839 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 1477, but not defined == Unused Reference: 'RFC3647' is defined on line 1624, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 1646, but no explicit reference was found in the text ** 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 (~~), 4 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: April 2014 Seo, K. 4 Intended Status: BCP BBN Technologies 5 October 2013 7 Template for a Certification Practice Statement (CPS) for the 8 Resource PKI (RPKI) 9 draft-ietf-sidr-cps-03.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 April 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..............................................44 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. A number of sections contained in the 318 template were omitted from this CPS because they did not apply to 319 this PKI. However, we have retained the section numbering scheme 320 employed in the RFC to facilitate comparison with the section 321 numbering scheme employed in that RFC and in the RFC 6484. 323 Conventions used in this document 325 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 326 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 327 document are to be interpreted as described in [RFC2119]. 329 1. Introduction 331 This document is the Certification Practice Statement (CPS) of . It describes the practices employed by the Certification Authority (CA) in the Resource Public 334 Key Infrastructure (RPKI). These practices are defined in 335 accordance with the requirements of the Certificate Policy (CP, 336 [RFC6484]) for the RPKI. 338 The RPKI is designed to support validation of claims by current 339 holders of Internet Number Resources (INRs, see definition in Section 340 1.6) in accordance with the records of the organizations that act as 341 CAs in this PKI. The ability to verify such claims is essential to 342 ensuring the unique, unambiguous distribution of these resources 344 This PKI parallels the existing INR distribution hierarchy. These 345 resources are distributed by the Internet Assigned Numbers Authority 346 (IANA) to the Regional Internet Registries. In some regions, National 347 Internet Registries (NIRs) form a tier of the hierarchy below the 348 RIRs for internet number resource (INR) distribution. Internet 349 Service Providers (ISPs) and network subscribers form additional 350 tiers below registries. 352 1.1. Overview 354 This CPS describes: 356 . Participants 358 . Publication of the certificates and CRLs 360 . How certificates are issued, managed, rekeyed, renewed and revoked 362 . Facility management (physical security, personnel, audit, etc.) 364 . Key management 366 . Audit procedures 367 . Business and legal issues 369 This PKI encompasses several types of certificates (see [RFC6480] for 370 more details): 372 . CA certificates for each organization distributing INRs and for 373 each subscriber INR holder) 375 . End entity (EE) certificates for organizations to use to validate 376 digital signatures on RPKI-signed objects (see definition in 377 Section 1.6). 379 . In the future, the PKI also may include end entity certificates in 380 support of access control for the repository system as described in 381 Section 2.4. 383 1.2. Document Name and Identification 385 The name of this document is "'s Certification 386 Practice Statement for the Resource Public Key Infrastructure (RPKI) 387 ". 392 1.3. PKI Participants 394 Note that in a PKI, the term "subscriber" refers to an individual or 395 organization that is a subject of a certificate issued by a CA. The 396 term is used in this fashion throughout this document, without 397 qualification, and should not be confused with the networking use of 398 the term to refer to an individual or organization that receives 399 service from an ISP. In such cases the term "network subscriber" will 400 be used. Also note that, for brevity, this document always refers to 401 PKI participants as organizations or entities, even though some of 402 them are individuals. 404 1.3.1. Certification Authorities 406 portion of the RPKI. It provides a secure 410 revocation and recovery capability in case the production CA is 411 compromised or becomes unavailable. Thus the offline CA issues 412 certificates only to instances of the production CA; and the CRLs it 413 issues are used to revoke only certificates issued to the production 414 CA. The production CA is used to issue RPKI certificates to members, to whom INRs have been distributed.> 417 1.3.2. Registration Authorities 419 429 1.3.3. Subscribers 431 Organizations receiving INR allocations from this CA are subscribers 432 in the RPKI. 434 1.3.4. Relying Parties 436 Entities or individuals that act in reliance on certificates or RPKI- 437 signed objects issued under this PKI are relying parties. Relying 438 parties may or may not be subscribers within this PKI. (See Section 439 1.6 for the definition of an RPKI-signed object.) 441 1.3.5. Other Participants 443 447 1.4. Certificate Usage 449 1.4.1. Appropriate Certificate Uses 451 The certificates issued under this hierarchy are for authorization in 452 support of validation of claims of current holdings of INRs. 454 Additional uses of the certificates, consistent with the basic goal 455 cited above, are also permitted under RFC 6484. 457 Some of the certificates that may be issued under this PKI could be 458 used to support operation of this infrastructure, e.g., access 459 control for the repository system as described in Section 2.4. Such 460 uses also are permitted under the RPKI certificate policy. 462 1.4.2. Prohibited Certificate Uses 464 Any uses other than those described in Section 1.4.1 are prohibited. 466 1.5. Policy Administration 468 1.5.1. Organization administering the document 470 This CPS is administered by . 473 1.5.2. Contact Person 475 477 1.5.3. Person Determining CPS Suitability for the Policy 479 Not applicable. Each organization issuing a certificate in this PKI 480 is attesting to the distribution of INRs to the holder of the private 481 key corresponding to the public key in the certificate. The issuing 482 organizations are the same organizations as the ones that perform the 483 distribution hence they are authoritative with respect to the 484 accuracy of this binding. 486 1.5.4. CPS Approval Procedures 488 Not applicable. Each organization issuing a certificate in this PKI 489 is attesting to the distribution of INRs to the holder of the private 490 key corresponding to the public key in the certificate. The issuing 491 organizations are the same organizations as the ones that perform the 492 distribution, hence they are authoritative with respect to the 493 accuracy of this binding. 495 1.6. Definitions and Acronyms 497 BPKI Business PKI: A BPKI is an optional additional PKI used by an 498 Organization to identify members to whom RPKI certificates can 499 be issued. If a BPKI is employed by a CA, it may have its own 500 CP, separate from the RPKI CP. 502 CP Certificate Policy. A CP is a named set of rules that indicates 503 the applicability of a certificate to a particular community 504 and/or class of applications with common security requirements. 505 The CP for the RPKI is [RFC6484]. 507 CPS Certification Practice Statement. A CPS is a document that 508 specifies the practices that a Certification Authority employs 509 in issuing certificates. 511 Distribution of INRs A process of distribution of the INRs along 512 the respective number hierarchy. IANA distributes blocks of IP 513 addresses and Autonomous System Numbers to the five Regional 514 Internet Registries (RIRs). RIRs distribute smaller address 515 blocks and Autonomous System Numbers to organizations within 516 their service regions, who in turn distribute IP addresses to 517 their customers. 519 IANA Internet Assigned Numbers Authority. IANA is responsible for 520 global coordination of the Internet Protocol addressing systems 521 and Autonomous System (AS) numbers used for routing internet 522 traffic. IANA distributes INRs to Regional Internet Registries 523 (RIRs). 525 INRs Internet Number Resources. INRs are number values for three 526 protocol parameter sets, namely: 527 . IP Version 4 addresses, 529 . IP version 6 addresses, and 531 . Identifiers used in Internet inter-domain routing, currently 532 Border Gateway Protocol-4 Autonomous System numbers. 534 ISP Internet Service Provider. An ISP is an organization managing 535 and selling Internet services to other organizations. 537 NIR National Internet Registry. An NIR is an organization that 538 manages the distribution of INRs for a portion of the 539 geopolitical area covered by a Regional Registry. NIRs form an 540 optional second tier in the tree scheme used to manage INR 541 distribution. 543 RIR Regional Internet Registry. An RIR is an organization that 544 manages the distribution of INRs for a geopolitical area. 546 RPKI-signed object An RPKI signed object is a digitally signed data 547 object (other than a certificate or CRL) declared to be such by 548 a standards track RFC, and that can be validated using 549 certificates issued under this PKI. The content and format of 550 these data constructs depend on the context in which validation 551 of claims of current holdings of INRs takes place. Examples of 552 these objects are repository manifests [RFC6486] and Route 553 Origin Authorizations (ROAs) [RFC6482]. 555 2. Publication and Repository Responsibilities 557 2.1. Repositories 559 As per the CP, certificates, CRLs and RPKI-signed objects MUST be 560 made available for downloading by all relying parties, to enable them 561 to validate this data. 563 The RPKI CA will publish certificates, CRLs, 564 and RPKI-signed objects via a repository that is accessible via 565 at . 566 This repository will conform to the structure described in [RFC6481]. 568 2.2. Publication of Certification Information 570 will publish certificates, CRLs and RPKI- 571 signed objects issued by it to a repository that operates as part of 572 a worldwide distributed system of RPKI repositories. 574 2.3. Time or Frequency of Publication 576 585 The CA will publish its CRL prior to the 586 nextUpdate value in the scheduled CRL previously issued by the CA. 588 2.4. Access Controls on Repositories 590 597 3. Identification And Authentication 599 3.1. Naming 601 3.1.1. Types of Names 603 The subject of each certificate issued by this Organization is 604 identified by an X.500 Distinguished Name (DN). The distinguished 605 name will consist of a single Common Name (CN) attribute with a 606 value generated by . Optionally, the 607 serialNumber attribute may be included along with the common name 608 (to form a terminal relative distinguished name set), to distinguish 609 among successive instances of certificates associated with the same 610 entity. 612 3.1.2. Need for Names to be Meaningful 614 The Subject name in each certificate SHOULD NOT be "meaningful",in 615 the conventional, human-readable sense. The rationale here is that 616 these certificates are used for authorization in support of 617 applications that make use of attestations of INR holdings. They are 618 not used to identify subjects. 620 3.1.3. Anonymity or Pseudonymity of Subscribers 622 Although Subject names in certificates issued by this Organization 623 SHOULD NOT be meaningful, and may appear "random," anonymity is not a 624 function of this PKI; thus no explicit support for this feature is 625 provided. 627 3.1.4. Rules for Interpreting Various Name Forms 629 None 631 3.1.5. Uniqueness of Names 633 certifies subject names that are unique among 634 the certificates that it issues. Although it is desirable that these 635 subject names be unique throughout the PKI, to facilitate certificate 636 path discovery, such uniqueness is neither mandated nor enforced 637 through technical means. generates subject 638 names to minimize the chances that two entities in the RPKI will be 639 assigned the same name. Specifically, 641 3.1.6. Recognition, Authentication, and Role of Trademarks 643 Because the Subject names are not intended to be meaningful, makes no provision to either recognize or authenticate 645 trademarks, service marks, etc. 647 3.2. Initial Identity Validation 649 3.2.1. Method to Prove Possession of Private Key 651 656 3.2.2. Authentication of Organization Identity 658 Certificates issued under this PKI do not attest to the 659 organizational identity of subscribers. However, certificates are 660 issued to subscribers in a fashion that preserves the accuracy of 661 distributions of INRs as represented in 662 records. 664 subscriber 670 database that maintains the INR distribution records. The certificate 671 request could be matched against the database record for the 672 subscriber in question, and an RPKI certificate would be issued only 673 if the INRs requested were a subset of those held by the subscriber. 674 The specific procedures employed for this purpose should be 675 commensurate with any you already employ in the maintenance of INR 676 distribution.> 678 3.2.3. Authentication of Individual Identity 680 Certificates issued under this PKI do not attest to the individual 681 identity of a subscriber. However, maintains 682 contact information for each subscriber in support of certificate 683 renewal, re-key, and revocation. 685 BPKI (see Section 3.2.6) issues certificates that MUST 690 be used to identify individuals who represent 691 subscribers." The procedures should be commensurate with those you 692 already employ in authenticating individuals as representatives for 693 INR holders. Note that this authentication is solely for use by you 694 in dealing with the organizations to which you distribute (or sub- 695 distribute) INRs, and thus MUST NOT be relied upon outside of this 696 CA/subscriber relationship.> 698 3.2.4. Non-verified Subscriber Information 700 No non-verified subscriber data is included in certificates issued 701 under this certificate policy except for Subject Information Access 702 (SIA) extensions [RFC6487]. 704 3.2.5. Validation of Authority 706 715 3.2.6. Criteria for Interoperation 717 The RPKI is neither intended nor designed to interoperate with any 718 other PKI. 723 3.3. Identification and Authentication for Re-key Requests 725 3.3.1. Identification and Authentication for Routine Re-key 727 734 3.3.2. Identification and Authentication for Re-key after 735 Revocation 737 746 3.4. Identification and Authentication for Revocation Request 748 758 4. Certificate Life-Cycle Operational Requirements 760 4.1. Certificate Application 762 4.1.1. Who Can Submit a Certificate Application 764 Any subscriber in good standing who holds INRs distributed by may submit a certificate application to this CA. 767 4.1.2. Enrollment Process and Responsibilities 769 777 4.2. Certificate Application Processing 779 783 4.2.1. Performing Identification and Authentication Functions 785 791 4.2.2. Approval or Rejection of Certificate Applications 793 802 4.2.3. Time to Process Certificate Applications 804 807 4.3. Certificate Issuance 809 4.3.1. CA Actions During Certificate Issuance 811 814 4.3.2. Notification to Subscriber by the CA of Issuance of 815 Certificate 817 will notify the subscriber when the 818 certificate is published. 821 4.3.3. Notification of Certificate Issuance by the CA to Other 822 Entities 824 827 4.4. Certificate Acceptance 829 4.4.1. Conduct Constituting Certificate Acceptance 831 When a certificate is issued, the CA will 832 publish it to the repository and notify the subscriber. 836 4.4.2. Publication of the Certificate by the CA 838 Certificates will be published at once 839 issued, following the conduct described in Section 4.4.1. This will 840 be done within . 844 4.4.3. Notification of Certificate Issuance by the CA to Other 845 Entities 847 850 4.5. Key Pair and Certificate Usage 852 A summary of the use model for the RPKI is provided below. 854 4.5.1. Subscriber Private Key and Certificate Usage 856 The certificates issued by to subordinate INR 857 holders are CA certificates. The private key associated with each of 858 these certificates is used to sign subordinate (CA or EE) 859 certificates and CRLs. 861 4.5.2. Relying Party Public Key and Certificate Usage 863 The primary relying parties in this PKI are organizations that use 864 RPKI EE certificates to verify RPKI-signed objects. Relying parties 865 are referred to Section 4.5.2 of [RFC6484] for additional guidance 866 with respect to acts of reliance on RPKI certificates. 868 4.6. Certificate Renewal 870 4.6.1. Circumstance for Certificate Renewal 872 As per RFC 6484, a certificate will be processed for renewal based on 873 its expiration date or a renewal request from the certificate 874 subject. The request may be implicit, a side effect of renewing a 875 resource holding agreement, or may be explicit. If initiates the renewal process based on the certificate 877 expiration date, then will notify the 878 subscriber The validity 881 interval of the new (renewed) certificate will overlap that of the 882 previous certificate by , to ensure uninterrupted coverage. 885 Certificate renewal will incorporate the same public key as the 886 previous certificate, unless the private key has been reported as 887 compromised (see Section 4.9.3). If a new key pair is being used, 888 the stipulations of Section 4.7 will apply. 890 4.6.2. Who May Request Renewal 892 The subscriber or may initiate the renewal 893 process. 905 4.6.3. Processing Certificate Renewal Requests 907 911 4.6.4. Notification of New Certificate Issuance to Subscriber 913 will notify the subscriber when the 914 certificate is published. 918 4.6.5. Conduct Constituting Acceptance of a Renewal Certificate 920 See Section 4.4.1 923 4.6.6. Publication of the Renewal Certificate by the CA 925 See Section 4.4.2. 927 4.6.7. Notification of Certificate Issuance by the CA to Other 928 Entities 930 See Section 4.4.3. 932 4.7. Certificate Re-key 934 4.7.1. Circumstance for Certificate Re-key 936 As per RFC 6484, re-key of a certificate will be performed only when 937 required, based on: 939 1. knowledge or suspicion of compromise or loss of the associated 940 private key, or 942 2. the expiration of the cryptographic lifetime of the associated key 943 pair 945 If a certificate is revoked to replace the RFC 3779 extensions, the 946 replacement certificate will incorporate the same public key, not a 947 new key. 949 If the re-key is based on a suspected compromise, then the previous 950 certificate will be revoked. 952 4.7.2. Who May Request Certification of a New Public Key 954 Only the holder of a certificate may request a re-key. In addition, 955 may initiate a re-key based on a verified 956 compromise report. BPKI. Describe how a compromise report received 959 from other than a subscriber is verified.> 961 4.7.3. Processing Certificate Re-keying Requests 963 967 4.7.4. Notification of New Certificate Issuance to Subscriber 969 974 4.7.5. Conduct Constituting Acceptance of a Re-keyed Certificate 976 When a re-keyed certificate is issued, the CA will publish it in the 977 repository and notify the subscriber. See Section 4.4.1. 979 4.7.6. Publication of the Re-keyed Certificate by the CA 981 985 4.7.7. Notification of Certificate Issuance by the CA to Other 986 Entities 988 See Section 4.4.3. 990 4.8. Certificate Modification 992 4.8.1. Circumstance for Certificate Modification 994 As per RFC 6484, modification of a certificate occurs to implement 995 changes to the RFC 3779 extension values or the SIA extension in a 996 certificate. A subscriber can request a certificate modification 997 when this information in a currently valid certificate has changed, 998 as a result of changes in the INR holdings of the subscriber or a 999 change of the repository publication point data. 1001 If a subscriber is to receive a distribution of INRs in addition to a 1002 current distribution, and if the subscriber does not request that a 1003 new certificate be issued containing only these additional INRs, then 1004 this is accomplished through a certificate modification. When a 1005 certificate modification is approved, a new certificate is issued. 1006 The new certificate will contain the same public key and the same 1007 expiration date as the original certificate, but with the incidental 1008 information corrected and/or the INR distribution expanded. When 1009 previously distributed INRs are to be removed from a certificate, 1010 then the old certificate will be revoked and a new certificate 1011 (reflecting the new distribution) issued. 1013 4.8.2. Who May Request Certificate modification 1015 The subscriber or may initiate the certificate 1016 modification process. 1020 4.8.3. Processing Certificate Modification Requests 1022 1026 4.8.4. Notification of Modified Certificate Issuance to 1027 Subscriber 1029 1034 4.8.5. Conduct Constituting Acceptance of Modified Certificate 1036 When a modified certificate is issued, will 1037 publish it to the repository and notify the subscriber. See Section 1038 4.4.1. 1040 4.8.6. Publication of the Modified Certificate by the CA 1042 1046 4.8.7. Notification of Certificate Issuance by the CA to Other 1047 Entities 1049 See Section 4.4.3. 1051 4.9. Certificate Revocation and Suspension 1053 4.9.1. Circumstances for Revocation 1055 As per RFC 6484, certificates can be revoked for several reasons. 1056 Either or the subject may choose to end the 1057 relationship expressed in the certificate, thus creating cause to 1058 revoke the certificate. If one or more of the INRs bound to the 1059 public key in the certificate are no longer associated with the 1060 subject, that too constitutes a basis for revocation. A certificate 1061 also may be revoked due to loss or compromise of the private key 1062 corresponding to the public key in the certificate. Finally, a 1063 certificate may be revoked in order to invalidate data signed by the 1064 private key associated with that certificate. 1066 4.9.2. Who Can Request Revocation 1068 The subscriber or may request a revocation. 1069 1072 4.9.3. Procedure for Revocation Request 1074 .> 1082 4.9.4. Revocation Request Grace Period 1084 A subscriber is required to request revocation as soon as possible 1085 after the need for revocation has been identified. 1087 4.9.5. Time Within Which CA Must Process the Revocation Request 1089 1092 4.9.6. Revocation Checking Requirement for Relying Parties 1094 As per RFC 6484, a relying party is responsible for acquiring and 1095 checking the most recent, scheduled CRL from the issuer of the 1096 certificate, whenever the relying party validates a certificate. 1098 4.9.7. CRL Issuance Frequency 1100 1101 Each CRL contains a nextUpdate value and a new CRL will be published 1102 at or before that time. will set the 1103 nextUpdate value when it issues a CRL, to signal when the next 1104 scheduled CRL will be issued. 1106 4.9.8. Maximum Latency for CRLs 1108 A CRL will be published to the repository system within after generation. 1111 4.10. Certificate Status Services 1113 does not support OCSP or SCVP. issues CRLs. 1116 5. Facility, Management, and Operational Controls 1118 5.1. Physical Controls 1120 1124 5.1.1. Site location and construction 1126 5.1.2. Physical access 1128 5.1.3. Power and air conditioning 1130 5.1.4. Water exposures 1132 5.1.5. Fire prevention and protection 1134 5.1.6. Media storage 1136 5.1.7. Waste disposal 1138 5.1.8. Off-site backup 1140 5.2. Procedural Controls 1142 1146 5.2.1. Trusted roles 1148 5.2.2. Number of persons required per task 1150 5.2.3. Identification and authentication for each role 1152 5.2.4. Roles requiring separation of duties 1154 5.3. Personnel Controls 1156 1160 5.3.1. Qualifications, experience, and clearance requirements 1162 5.3.2. Background check procedures 1164 5.3.3. Training requirements 1166 5.3.4. Retraining frequency and requirements 1168 5.3.5. Job rotation frequency and sequence 1170 5.3.6. Sanctions for unauthorized actions 1172 5.3.7. Independent contractor requirements 1174 5.3.8. Documentation supplied to personnel 1176 5.4. Audit Logging Procedures 1178 1181 5.4.1. Types of Events Recorded 1183 Audit records will be generated for the basic operations of the 1184 certification authority computing equipment. Audit records will 1185 include the date, time, responsible user or process, and summary 1186 content data relating to the event. Auditable events include: 1188 . Access to CA computing equipment (e.g., logon, logout) 1190 . Messages received requesting CA actions (e.g., certificate 1191 requests, certificate revocation requests, compromise 1192 notifications) 1194 . Certificate creation, modification, revocation, or renewal actions 1196 . Posting of any material to a repository 1198 . Any attempts to change or delete audit data 1200 . Key generation 1202 . Software and/or configuration updates to the CA 1203 . Clock adjustments 1205 1207 5.4.2. Frequency of Processing Log 1209 1211 5.4.3. Retention Period for Audit Log 1213 1215 5.4.4. Protection of Audit Log 1217 1219 5.4.5. Audit Log Backup Procedures 1221 1223 5.4.6. Audit Collection System (Internal vs. External) [OMITTED] 1225 5.4.7. Notification to Event-causing Subject [OMITTED] 1227 5.4.8. Vulnerability Assessments 1229 1234 5.5. Records Archival [OMITTED] 1236 5.6. Key Changeover 1238 The CA certificate will contain a validity 1239 period that is at least as long as that of any certificate being 1240 issued under that certificate. When CA 1241 changes keys it will follow the procedures described in [RFC6489]. 1243 5.7. Compromise and Disaster Recovery 1245 1249 5.8. CA or RA Termination 1251 1254 6. Technical Security Controls 1256 This section describes the security controls used by . 1259 6.1. Key Pair Generation and Installation 1261 6.1.1. Key Pair Generation 1263 1270 6.1.2. Private Key Delivery to Subscriber 1272 1277 6.1.3. Public Key Delivery to Certificate Issuer 1279 RPKI CA. These procedures 1281 MUST ensure that the public key has not been altered during transit 1282 and that the subscriber possesses the private key corresponding to 1283 the transferred public key.> See RFC 6487 for details. 1285 6.1.4. CA Public Key Delivery to Relying Parties 1287 CA public keys for all entities (other than trust anchors) are 1288 contained in certificates issued by other CAs and will be published 1289 to the RPKI repository system. Relying parties will download these 1290 certificates from this system. Public key values and associated data 1291 for (putative) trust anchors will be distributed out of band and 1292 accepted by relying parties on the basis of locally-defined criteria, 1293 e.g., embedded in path validation software that will be made 1294 available to the Internet community. 1296 6.1.5. Key Sizes 1298 The key sizes used in this PKI are as specified in [RFC6485]. 1300 6.1.6. Public Key Parameters Generation and Quality Checking 1302 The public key algorithms and parameters used in this PKI are as 1303 specified in [RFC6485]. 1305 is not responsible for performing such checks 1309 for subscribers OR describe the procedures used by the CA for 1310 checking the quality of these subscriber key pairs.> 1312 6.1.7. Key Usage Purposes (as per X.509 v3 Key Usage Field) 1314 The Key usage extension bit values employed in RPKI certificates are 1315 specified in [RFC6487]. 1317 6.2. Private Key Protection and Cryptographic Module Engineering 1318 Controls 1320 6.2.1. Cryptographic module standards and controls 1322 . 1326 6.2.2. Private Key (n out of m) Multi-Person Control 1328 out of multi-person 1331 control."> 1333 6.2.3. Private Key Escrow 1335 1338 6.2.4. Private Key Backup 1340 1345 6.2.5. Private Key Archival 1347 See sections 6.2.3 and 6.2.4 1349 6.2.6. Private Key Transfer into or from a Cryptographic Module 1351 The private key for 's production CA 1353 will be generated by the cryptographic module specified in 6.2.1. 1354 The private keys will never leave the module except in encrypted form 1355 for backup and/or transfer to a new module. 1356 6.2.7. Private Key Storage on Cryptographic Module 1358 The private key for 's production CA 1360 will be stored in the cryptographic module. It will be protected from 1361 unauthorized use . 1363 6.2.8. Method of Activating Private Key 1365 1368 6.2.9. Method of Deactivating Private Key 1370 1372 6.2.10. Method of Destroying Private Key 1374 1377 6.2.11. Cryptographic Module Rating 1379 1382 6.3. Other aspects of Key Pair Management 1384 6.3.1. Public Key Archival 1386 1389 6.3.2. Certificate Operational Periods and Key Pair Usage 1390 Periods 1392 The CA's key pair will have a validity 1393 interval of . 1399 6.4. Activation data 1401 6.4.1. Activation Data Generation and Installation 1403 1405 6.4.2. Activation data protection 1407 Activation data for the CA private key will be protected by . 1410 6.4.3. Other Aspects of Activation Data 1412 1415 6.5. Computer Security Controls 1417 1422 6.6. Life cycle Technical Controls 1424 6.6.1. System Development Controls 1426 1429 6.6.2. Security Management Controls 1431 1435 6.6.3. Life Cycle Security Controls 1437 1441 6.7. Network Security Controls 1443 1448 6.8. Time-stamping 1450 The RPKI does not make use of time stamping. 1452 7. Certificate and CRL Profiles 1454 See [RFC6487]. 1456 8. Compliance Audit and Other Assessments 1458 1462 9. Other Business And Legal Matters 1464 1471 9.1. Fees 1473 9.1.1. Certificate issuance or renewal fees 1475 9.1.2. Certificate access fees [OMITTED] 1477 9.1.3. Revocation or status information access fees [OMITTED] 1479 9.1.4. Fees for other services (if applicable) 1481 9.1.5. Refund policy 1483 9.2. Financial responsibility 1485 9.2.1. Insurance coverage 1487 9.2.2. Other assets 1489 9.2.3. Insurance or warranty coverage for end-entities 1491 9.3. Confidentiality of business information 1493 9.3.1. Scope of confidential information 1495 9.3.2. Information not within the scope of confidential 1496 information 1498 9.3.3. Responsibility to protect confidential information 1500 9.4. Privacy of personal information 1502 9.4.1. Privacy plan 1504 9.4.2. Information treated as private 1506 9.4.3. Information not deemed private 1508 9.4.4. Responsibility to protect private information 1510 9.4.5. Notice and consent to use private information 1512 9.4.6. Disclosure pursuant to judicial or administrative process 1514 9.4.7. Other information disclosure circumstances 1516 9.5. Intellectual property rights (if applicable) 1518 9.6. Representations and warranties 1520 9.6.1. CA representations and warranties 1522 9.6.2. Subscriber representations and warranties 1524 9.6.3. Relying party representations and warranties 1526 9.7. Disclaimers of warranties 1528 9.8. Limitations of liability 1530 9.9. Indemnities 1532 9.10. Term and termination 1534 9.10.1. Term 1536 9.10.2. Termination 1538 9.10.3. Effect of termination and survival 1540 9.11. Individual notices and communications with participants 1542 9.12. Amendments 1544 9.12.1. Procedure for amendment 1546 9.12.2. Notification mechanism and period 1548 9.13. Dispute resolution provisions 1550 9.14. Governing law 1552 9.15. Compliance with applicable law 1554 9.16. Miscellaneous provisions 1556 9.16.1. Entire agreement 1558 9.16.2. Assignment 1560 9.16.3. Severability 1562 9.16.4. Enforcement (attorneys' fees and waiver of rights) 1564 9.16.5. Force Majeure 1566 10. Security Considerations 1568 The degree to which a relying party can trust the binding embodied in 1569 a certificate depends on several factors. These factors can include 1570 the practices followed by the certification authority (CA) in 1571 authenticating the subject; the CA's operating policy, procedures, 1572 and technical security controls, including the scope of the 1573 subscriber's responsibilities (for example, in protecting the private 1574 key), and the stated responsibilities and liability terms and 1575 conditions of the CA (for example, warranties, disclaimers of 1576 warranties, and limitations of liability). This document provides a 1577 framework to address the technical, procedural, personnel, and 1578 physical security aspects of Certification Authorities, Registration 1579 Authorities, repositories, subscribers, and relying party 1580 cryptographic modules, in order to ensure that the certificate 1581 generation, publication, renewal, re-key, usage, and revocation is 1582 done in a secure manner. Specifically, Section 3 Identification and 1583 Authentication (I&A); Section 4 Certificate Life-Cycle Operational 1584 Requirements; Section 5 Facility Management, and Operational 1585 Controls; Section 6 Technical Security Controls; Section 7 1586 Certificate and CRL Profiles; and Section 8 Compliance Audit and 1587 Other Assessments are oriented towards ensuring secure operation of 1588 the PKI entities such as CA, RA, repository, subscriber systems, and 1589 relying party systems. 1591 11. IANA Considerations 1593 None. 1595 12. Acknowledgments 1597 The authors would like to thank Matt Lepinski for help with the 1598 formatting, Ron Watro for assistance with the editing, and other 1599 members of the SIDR working group for reviewing this document. 1601 13. References 1603 13.1. Normative References 1605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1606 Requirement Levels", BCP 14, RFC 2119, March 1997. 1608 [RFC6484] Kent, S., Kong, D., Seo, K., and Watro, R., "Certificate 1609 Policy (CP) for the Resource PKI (RPKI)," February 2012. 1611 [RFC6487] Huston, G., Michaelson, G., and Loomans, R., "A Profile for 1612 X.509 PKIX Resource Certificates," February 2012. 1614 [RFC6485] Huston, G., "A Profile for Algorithms and Key Sizes for Use 1615 in the Resource Public Key Infrastructure," February 2012. 1617 13.2. Informative References 1619 [FIPS] Federal Information Processing Standards Publication 140-3 1620 (FIPS-140-3), "Security Requirements for Cryptographic 1621 Modules", Information Technology Laboratory, National 1622 Institute of Standards and Technology, work in progress. 1624 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and Wu, 1625 S., "Internet X.509 Public Key Infrastructure Certificate 1626 Policy and Certification Practices Framework", RFC 3647, 1627 November 2003. 1629 [RFC6480] M. Lepinski, S. Kent, "An Infrastructure to Support Secure 1630 Internet Routing," February 2012. 1632 [RFC6481] G. Huston, R. Loomans, G. Michaelson, "A Profile for 1633 Resource Certificate Repository Structure," February 2012. 1635 [RFC6482] M. Lepinski, S. Kent, D. Kong, "A Profile for Route Origin 1636 Authorizations (ROAs)," February 2012. 1638 [RFC6486] R. Austein, G. Huston, S. Kent, M. Lepinski, "Manifests for 1639 the Resource Public Key Infrastructure (RPKI)," February 1640 2012. 1642 [RFC6489] G. Huston, G. Michaelson, S. Kent, "Certification Authority 1643 (CA) Key Rollover in the Resource Public Key Infrastructure 1644 (RPKI), February 2012. 1646 [RSA] Rivest, R., Shamir, A., and Adelman, L. M. 1978. A method 1647 for obtaining digital signatures and public-key 1648 cryptosystems. Commun. ACM 21, 2 (Feb.), 120-126. 1650 Author's Addresses 1652 Stephen Kent 1653 BBN Technologies 1654 10 Moulton Street 1655 Cambridge MA 02138 1656 USA 1658 Phone: +1 (617) 873-3988 1659 Email: skent@bbn.com 1661 Derrick Kong 1662 BBN Technologies 1663 10 Moulton Street 1664 Cambridge MA 02138 1665 USA 1667 Phone: +1 (617) 873-1951 1668 Email: dkong@bbn.com 1670 Karen Seo 1671 BBN Technologies 1672 10 Moulton Street 1673 Cambridge MA 02138 1674 USA 1676 Phone: +1 (617) 873-3152 1677 Email: kseo@bbn.com 1679 Copyright Statement 1681 Copyright (c) 2013 IETF Trust and the persons identified as the 1682 document authors. All rights reserved. 1684 This document is subject to BCP 78 and the IETF Trust's Legal 1685 Provisions Relating to IETF Documents 1686 (http://trustee.ietf.org/license-info) in effect on the date of 1687 publication of this document. Please review these documents 1688 carefully, as they describe your rights and restrictions with respect 1689 to this document. Code Components extracted from this document must 1690 include Simplified BSD License text as described in Section 4.e of 1691 the Trust Legal Provisions and are provided without warranty as 1692 described in the Simplified BSD License.