idnits 2.17.1 draft-ietf-sidr-cps-01.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 : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 33 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 2013) is 4118 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: 'RFC6480' is mentioned on line 368, but not defined == Missing Reference: 'RFC6384' is mentioned on line 499, but not defined == Missing Reference: 'RFC6486' is mentioned on line 546, but not defined ** Obsolete undefined reference: RFC 6486 (Obsoleted by RFC 9286) == Missing Reference: 'RFC6482' is mentioned on line 547, but not defined == Missing Reference: 'RFC6481' is mentioned on line 560, but not defined == Missing Reference: 'OMITTED' is mentioned on line 1237, but not defined == Missing Reference: 'RFC6489' is mentioned on line 1235, but not defined == Unused Reference: 'RFC3280' is defined on line 1590, but no explicit reference was found in the text == Unused Reference: 'BGP4' is defined on line 1606, but no explicit reference was found in the text == Unused Reference: 'FIPS' is defined on line 1609, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 1614, but no explicit reference was found in the text -- Duplicate reference: RFC2119, mentioned in 'RFC3280', was also mentioned in 'RFC2119'. ** Obsolete normative reference: RFC 6485 (Obsoleted by RFC 7935) -- Obsolete informational reference (is this intentional?): RFC 1771 (ref. 'BGP4') (Obsoleted by RFC 4271) Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 3 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: July 2013 Seo, K. 4 Intended Status: BCP BBN Technologies 5 January 2013 7 Template for a Certification Practice Statement (CPS) for the 8 Resource PKI (RPKI) 9 draft-ietf-sidr-cps-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on July 31, 2013. 36 Abstract 38 This document contains a template to be used for creating a 39 Certification Practice Statement (CPS) for an Organization that is 40 part of the Resource Public Key Infrastructure (RPKI), e.g., a 41 resource allocation registry or an ISP. 43 Conventions used in this document 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC-2119 [RFC2119]. 49 Table of Contents 51 Preface...........................................................7 52 1. Introduction...................................................8 53 1.1. Overview..................................................8 54 1.2. Document Name and Identification..........................9 55 1.3. PKI Participants..........................................9 56 1.3.1. Certification Authorities............................9 57 1.3.2. Registration Authorities.............................9 58 1.3.3. Subscribers.........................................10 59 1.3.4. Relying Parties.....................................10 60 1.3.5. Other Participants..................................10 61 1.4. Certificate Usage........................................10 62 1.4.1. Appropriate Certificate Uses........................10 63 1.4.2. Prohibited Certificate Uses.........................10 64 1.5. Policy Administration....................................11 65 1.5.1. Organization administering the document.............11 66 1.5.2. Contact Person......................................11 67 1.5.3. Person Determining CPS Suitability for the Policy...11 68 1.5.4. CPS Approval Procedures.............................11 69 1.6. Definitions and Acronyms.................................11 70 2. Publication and Repository Responsibilities...................14 71 2.1. Repositories.............................................14 72 2.2. Publication of Certification Information.................14 73 2.3. Time or Frequency of Publication.........................14 74 2.4. Access Controls on Repositories..........................14 75 3. Identification And Authentication.............................15 76 3.1. Naming...................................................15 77 3.1.1. Types of Names......................................15 78 3.1.2. Need for Names to be Meaningful.....................15 79 3.1.3. Anonymity or Pseudonymity of Subscribers............15 80 3.1.4. Rules for Interpreting Various Name Forms...........15 81 3.1.5. Uniqueness of Names.................................15 82 3.1.6. Recognition, Authentication, and Role of Trademarks.16 83 3.2. Initial Identity Validation..............................16 84 3.2.1. Method to Prove Possession of Private Key...........16 85 3.2.2. Authentication of Organization Identity.............16 86 3.2.3. Authentication of Individual Identity...............16 87 3.2.4. Non-verified Subscriber Information.................17 88 3.2.5. Validation of Authority.............................17 89 3.2.6. Criteria for Interoperation.........................17 90 3.3. Identification and Authentication for Re-key Requests....17 91 3.3.1. Identification and Authentication for Routine Re-key17 92 3.3.2. Identification and Authentication for Re-key after 93 Revocation.................................................18 94 3.4. Identification and Authentication for Revocation Request.18 95 4. Certificate Life-Cycle Operational Requirements...............19 96 4.1. Certificate Application..................................19 97 4.1.1. Who Can Submit a Certificate Application............19 98 4.1.2. Enrollment Process and Responsibilities.............19 99 4.2. Certificate Application Processing.......................19 100 4.2.1. Performing Identification and Authentication Functions19 101 4.2.2. Approval or Rejection of Certificate Applications...19 102 4.2.3. Time to Process Certificate Applications............20 103 4.3. Certificate Issuance.....................................20 104 4.3.1. CA Actions During Certificate Issuance..............20 105 4.3.2. Notification to Subscriber by the CA of Issuance of 106 Certificate................................................20 107 4.3.3. Notification of Certificate Issuance by the CA to Other 108 Entities...................................................20 109 4.4. Certificate Acceptance...................................20 110 4.4.1. Conduct Constituting Certificate Acceptance.........20 111 4.4.2. Publication of the Certificate by the CA............20 112 4.5. Key Pair and Certificate Usage...........................20 113 4.5.1. Subscriber Private Key and Certificate Usage........21 114 4.5.2. Relying Party Public Key and Certificate Usage......21 115 4.6. Certificate Renewal......................................21 116 4.6.1. Circumstance for Certificate Renewal................21 117 4.6.2. Who May Request Renewal.............................21 118 4.6.3. Processing Certificate Renewal Requests.............22 119 4.6.4. Notification of New Certificate Issuance to Subscriber22 120 4.6.5. Conduct Constituting Acceptance of a Renewal Certificate 121 ...........................................................22 122 4.6.6. Publication of the Renewal Certificate by the CA....22 123 4.6.7. Notification of Certificate Issuance by the CA to Other 124 Entities...................................................22 125 4.7. Certificate Re-key.......................................22 126 4.7.1. Circumstance for Certificate Re-key.................22 127 4.7.2. Who May Request Certification of a New Public Key...23 128 4.7.3. Processing Certificate Re-keying Requests...........23 129 4.7.4. Notification of New Certificate Issuance to Subscriber23 130 4.7.5. Conduct Constituting Acceptance of a Re-keyed 131 Certificate................................................23 132 4.7.6. Publication of the Re-keyed Certificate by the CA...23 133 4.7.7. Notification of Certificate Issuance by the CA to Other 134 Entities...................................................24 135 4.8. Certificate Modification.................................24 136 4.8.1. Circumstance for Certificate Modification...........24 137 4.8.2. Who May Request Certificate modification............24 138 4.8.3. Processing Certificate Modification Requests........24 139 4.8.4. Notification of Modified Certificate Issuance to 140 Subscriber.................................................24 141 4.8.5. Conduct Constituting Acceptance of Modified Certificate 142 ...........................................................25 143 4.8.6. Publication of the Modified Certificate by the CA...25 144 4.8.7. Notification of Certificate Issuance by the CA to Other 145 Entities...................................................25 146 4.9. Certificate Revocation and Suspension....................25 147 4.9.1. Circumstances for Revocation........................25 148 4.9.2. Who Can Request Revocation..........................25 149 4.9.3. Procedure for Revocation Request....................25 150 4.9.4. Revocation Request Grace Period.....................26 151 4.9.5. Time Within Which CA Must Process the Revocation Request 152 ...........................................................26 153 4.9.6. Revocation Checking Requirement for Relying Parties.26 154 4.9.7. CRL Issuance Frequency..............................26 155 4.9.8. Maximum Latency for CRLs............................26 156 4.10. Certificate Status Services.............................26 157 5. Facility, Management, and Operational Controls ................27 158 5.1. Physical Controls........................................27 159 5.1.1. Site location and construction......................27 160 5.1.2. Physical access.....................................27 161 5.1.3. Power and air conditioning..........................27 162 5.1.4. Water exposures.....................................27 163 5.1.5. Fire prevention and protection......................27 164 5.1.6. Media storage.......................................27 165 5.1.7. Waste disposal......................................27 166 5.1.8. Off-site backup.....................................27 167 5.2. Procedural Controls......................................27 168 5.2.1. Trusted roles.......................................27 169 5.2.2. Number of persons required per task.................27 170 5.2.3. Identification and authentication for each role.....27 171 5.2.4. Roles requiring separation of duties................27 172 5.3. Personnel Controls.......................................27 173 5.3.1. Qualifications, experience, and clearance requirements28 174 5.3.2. Background check procedures.........................28 175 5.3.3. Training requirements...............................28 176 5.3.4. Retraining frequency and requirements...............28 177 5.3.5. Job rotation frequency and sequence.................28 178 5.3.6. Sanctions for unauthorized actions..................28 179 5.3.7. Independent contractor requirements.................28 180 5.3.8. Documentation supplied to personnel.................28 181 5.4. Audit Logging Procedures.................................28 182 5.4.1. Types of Events Recorded............................28 183 5.4.2. Frequency of Processing Log.........................28 184 5.4.3. Retention Period for Audit Log......................29 185 5.4.4. Protection of Audit Log.............................29 186 5.4.5. Audit Log Backup Procedures.........................29 187 5.4.6. Audit Collection System (Internal vs. External) 188 [OMITTED]..................................................29 189 5.4.7. Notification to Event-causing Subject [OMITTED].....29 190 5.4.8. Vulnerability Assessments...........................29 191 5.5. Records archival [OMITTED]...............................29 192 5.6. Key Changeover...........................................29 193 5.7. Compromise and disaster recovery [OMITTED]...............29 194 5.8. CA or RA Termination.....................................29 195 6. Technical Security Controls...................................30 196 6.1. Key Pair Generation and Installation.....................30 197 6.1.1. Key Pair Generation.................................30 198 6.1.2. Private Key Delivery to Subscriber..................30 199 6.1.3. Public Key Delivery to Certificate Issuer...........30 200 6.1.4. CA Public Key Delivery to Relying Parties...........30 201 6.1.5. Key Sizes...........................................30 202 6.1.6. Public Key Parameters Generation and Quality Checking31 203 6.1.7. Key Usage Purposes (as per X.509 v3 Key Usage Field)31 204 6.2. Private Key Protection and Cryptographic Module Engineering 205 Controls......................................................31 206 6.2.1. Cryptographic module standards and controls.........31 207 6.2.2. Private Key (n out of m) Multi-Person Control.......31 208 6.2.3. Private Key Escrow..................................31 209 6.2.4. Private Key Backup..................................31 210 6.2.5. Private Key Archival................................32 211 6.2.6. Private Key Transfer into or from a Cryptographic Module 212 ...........................................................32 213 6.2.7. Private Key Storage on Cryptographic Module.........32 214 6.2.8. Method of Activating Private Key....................32 215 6.2.9. Method of Deactivating Private Key..................32 216 6.2.10. Method of Destroying Private Key...................32 217 6.2.11. Cryptographic Module Rating........................32 218 6.3. Other aspects of Key Pair Management.....................32 219 6.3.1. Public Key Archival.................................32 220 6.3.2. Certificate Operational Periods and Key Pair Usage 221 Periods....................................................33 222 6.4. Activation data..........................................33 223 6.4.1. Activation Data Generation and Installation.........33 224 6.4.2. Activation data protection..........................33 225 6.4.3. Other Aspects of Activation Data....................33 226 6.5. Computer Security Controls...............................33 227 6.6. Life cycle Technical Controls............................33 228 6.6.1. System Development Controls.........................33 229 6.6.2. Security Management Controls........................33 230 6.6.3. Life Cycle Security Controls........................34 231 6.7. Network Security Controls................................34 232 6.8. Time-stamping............................................34 233 7. Certificate and CRL Profiles..................................35 234 8. Compliance Audit and Other Assessments........................36 235 9. Other Business And Legal Matters..............................37 236 9.1. Fees.....................................................38 237 9.1.1. Certificate issuance or renewal fees................38 238 9.1.2. Fees for other services (if applicable).............38 239 9.1.3. Refund policy.......................................38 240 9.2. Financial responsibility.................................38 241 9.2.1. Insurance coverage..................................38 242 9.2.2. Other assets........................................38 243 9.2.3. Insurance or warranty coverage for end-entities.....38 244 9.3. Confidentiality of business information..................38 245 9.3.1. Scope of confidential information...................38 246 9.3.2. Information not within the scope of confidential 247 information................................................38 248 9.3.3. Responsibility to protect confidential information..38 249 9.4. Privacy of personal information..........................38 250 9.4.1. Privacy plan........................................38 251 9.4.2. Information treated as private......................38 252 9.4.3. Information not deemed private......................38 253 9.4.4. Responsibility to protect private information.......38 254 9.4.5. Notice and consent to use private information.......38 255 9.4.6. Disclosure pursuant to judicial or administrative 256 process....................................................38 257 9.4.7. Other information disclosure circumstances..........38 258 9.5. Intellectual property rights (if applicable).............38 259 9.6. Representations and warranties...........................38 260 9.6.1. CA representations and warranties...................38 261 9.6.2. Subscriber representations and warranties...........39 262 9.6.3. Relying party representations and warranties........39 263 9.7. Disclaimers of warranties................................39 264 9.8. Limitations of liability.................................39 265 9.9. Indemnities..............................................39 266 9.10. Term and termination....................................39 267 9.10.1. Term...............................................39 268 9.10.2. Termination........................................39 269 9.10.3. Effect of termination and survival.................39 270 9.11. Individual notices and communications with participants.39 271 9.12. Amendments..............................................39 272 9.12.1. Procedure for amendment............................39 273 9.12.2. Notification mechanism and period..................39 274 9.13. Dispute resolution provisions...........................39 275 9.14. Governing law...........................................39 276 9.15. Compliance with applicable law..........................39 277 9.16. Miscellaneous provisions................................39 278 9.16.1. Entire agreement...................................39 279 9.16.2. Assignment.........................................39 280 9.16.3. Severability.......................................39 281 9.16.4. Enforcement (attorneys' fees and waiver of rights).39 282 9.16.5. Force Majeure......................................39 283 10. Security Considerations......................................39 284 11. IANA Considerations..........................................40 285 12. Acknowledgments..............................................40 286 13. References...................................................41 287 13.1. Normative References....................................41 288 13.2. Informative References..................................41 289 Author's Addresses...............................................42 290 Copyright Statement..............................................42 292 Preface 294 This document contains a template to be used for creating a 295 Certification Practice Statement (CPS) for an Organization that is 296 part of the Resource Public Key Infrastructure (RPKI). The user of 297 this document should: 299 1. substitute a title page for page 1 saying, e.g., '' Certification Practice Statement for the Resource 301 Public Key Infrastructure (RPKI)'' with date, author, etc. There 302 is no expectation that a CPS will be published as an RFC. 304 2. leave the table of contents intact 306 3. delete this Preface, headers and footers (but keep page numbers) 308 4. fill in the information indicated below by 311 5. delete sections 10, 11, 12, 13.1, Acknowledgments, Author's 312 Addresses, Intellectual Property Statement, Disclaimer of 313 Validity, Copyright Statement, Acknowledgments; leaving a 314 reference section with just the references in 13.2 316 6. update the table of contents to reflect the changes required by 317 steps 4 and 5 above . 319 This document has been generated to complement the Certificate Policy 320 (CP) for the RPKI [RFC6484]. Like the RPKI CP, it is is based on the 321 template specified in RFC 3647. A number of sections contained in the 322 template were omitted from this CPS because they did not apply to 323 this PKI. However, we have retained the section numbering scheme 324 employed in the RFC to facilitate comparison with the section 325 numbering scheme employed in that RFC and in the RPKI CP. 327 1. Introduction 329 This document is the Certification Practice Statement (CPS) of . It describes the practices employed by the Certification Authority (CA) in the Resource Public 332 Key Infrastructure (RPKI). These practices are defined in 333 accordance with the requirements of the Certificate Policy (CP, 334 [RFC6484]) for the RPKI. 336 The RPKI is designed to support validation of claims by current 337 holders of Internet Number Resources (INRs, see definition in Section 338 1.7) in accordance with the records of the organizations that act as 339 CAs in this PKI. The ability to verify such claims is essential to 340 ensuring the unique, unambiguous distribution of these resources 342 This PKI parallels the existing INR distribution hierarchy. These 343 resources are distributed by the Internet Assigned Numbers Authority 344 (IANA) to the Regional Internet Registries. In some regions, National 345 Internet Registries (NIRs) form a tier of the hierarchy below the 346 RIRs for internet number resource (INR) distribution. Internet 347 Service Providers (ISPs) and network subscribers form additional 348 tiers below registries. 350 1.1. Overview 352 This CPS describes: 354 . Participants 356 . Publication of the certificates and CRLs 358 . How certificates are issued, managed, and revoked 360 . Facility management (physical security, personnel, audit, etc.) 362 . Key management 364 . Audit procedures 366 . Business and legal issues 368 This PKI encompasses several types of certificates (see [RFC6480] for 369 more details): 371 . CA certificates for each organization distributing INRs and for 372 each subscriber INR holder) 374 . End entity (EE) certificates for organizations to use to validate 375 digital signatures on RPKI-signed objects (see definition in 376 Section 1.7). 378 . In the future, the PKI also may include end entity certificates in 379 support of access control for the repository system as described in 380 2.4. 382 1.2. Document Name and Identification 384 The name of this document is '''s Certification 385 Practice Statement for the Resource Public Key Infrastructure 386 (RPKI)''. 388 1.3. PKI Participants 390 Note that in a PKI, the term ''subscriber'' refers to an individual or 391 organization that is a subject of a certificate issued by a CA. The 392 term is used in this fashion throughout this document, without 393 qualification, and should not be confused with the networking use of 394 the term to refer to an individual or organization that receives 395 service from an ISP. In such cases the term ''network subscriber'' will 396 be used. Also note that, for brevity, this document always refers to 397 PKI participants as organizations or entities, even though some of 398 them are individuals. 400 1.3.1. Certification Authorities 402 portion of the RPKI. It provides a secure 406 revocation and recovery capability in case the production CA is 407 compromised or becomes unavailable. Thus the offline CA issues 408 certificates only to instances of the production CA; and the CRLs it 409 issues are used to revoke only certificates issued to the production 410 CA. The production CA is used to issue RPKI certificates to members, to whom INRs have been distributed.> 413 1.3.2. Registration Authorities 415 425 1.3.3. Subscribers 427 Organizations receiving INR allocations from this CA are subscribers 428 in the RPKI. 430 1.3.4. Relying Parties 432 Entities or individuals that act in reliance on certificates or RPKI- 433 signed objects issued under this PKI are relying parties. Relying 434 parties may or may not be subscribers within this PKI. (See Section 435 1.7 for the definition of an RPKI-signed object.) 437 1.3.5. Other Participants 439 443 1.4. Certificate Usage 445 1.4.1. Appropriate Certificate Uses 447 The certificates issued under this hierarchy are for authorization in 448 support of validation of claims of current holdings of INRs. 450 Additional uses of the certificates, consistent with the basic goal 451 cited above, are also permitted under the RPKI CP [RFC6484]. 453 Some of the certificates that may be issued under this PKI could be 454 used to support operation of this infrastructure, e.g., access 455 control for the repository system as described in 2.4. Such uses also 456 are permitted under the RPKI certificate policy. 458 1.4.2. Prohibited Certificate Uses 460 Any uses other than those described in Section 1.4.1 are prohibited. 462 1.5. Policy Administration 464 1.5.1. Organization administering the document 466 This CPS is administered by 468 1.5.2. Contact Person 470 472 1.5.3. Person Determining CPS Suitability for the Policy 474 Not applicable. Each organization issuing a certificate in this PKI 475 is attesting to the distribution of INRs to the holder of the private 476 key corresponding to the public key in the certificate. The issuing 477 organizations are the same organizations as the ones that perform the 478 distribution hence they are authoritative with respect to the 479 accuracy of this binding. 481 1.5.4. CPS Approval Procedures 483 Not applicable. Each organization issuing a certificate in this PKI 484 is attesting to the distribution of INRs to the holder of the private 485 key corresponding to the public key in the certificate. The issuing 486 organizations are the same organizations as the ones that perform the 487 distribution, hence they are authoritative with respect to the 488 accuracy of this binding. 490 1.6. Definitions and Acronyms 492 BPKI - Business PKI: A BPKI is an optional additional PKI used by an 493 Organization to identify members to whom RPKI certificates can 494 be issued. 496 CP - Certificate Policy. A CP is a named set of rules that indicates 497 the applicability of a certificate to a particular community 498 and/or class of applications with common security requirements. 499 The CP for the RPKI is [RFC6384]. 501 CPS - Certification Practice Statement. A CPS is a document that 502 specifies the practices that a Certification Authority employs 503 in issuing certificates. 505 Distribution of INRs - - A process of distribution of the INRs along the 506 respective number hierarchy. IANA distributes blocks of IP 507 addresses and Autonomous System Numbers to the five Regional 508 Internet Registries (RIRs). RIRs distribute smaller address 509 blocks and Autonomous System Numbers to organizations within 510 their service regions, who in turn distribute IP addresses to 511 their customers. 513 IANA - Internet Assigned Numbers Authority. IANA is responsible for 514 global coordination of the Internet Protocol addressing systems 515 and Autonomous System (AS) numbers used for routing internet 516 traffic. IANA distributes INRs to Regional Internet Registries 517 (RIRs). 519 INRs - Internet Number Resources. INRs are number values for three 520 protocol parameter sets, namely: 521 . IP Version 4 addresses, 523 . IP version 6 addresses, and 525 . Identifiers used in Internet inter-domain routing, currently 526 Border Gateway Protocol-4 Autonomous System numbers. 528 ISP - - Internet Service Provider. An ISP is an organization managing 529 and selling Internet services to other organizations. 531 NIR - - National Internet Registry. An NIR is an organization that 532 manages the distribution of INRs for a portion of the 533 geopolitical area covered by a Regional Registry. NIRs form an 534 optional second tier in the tree scheme used to manage INR 535 distribution. 537 RIR - Regional Internet Registry. An RIR is an organization that 538 manages the distribution of INRs for a geopolitical area. 540 RPKI-signed object - - An RPKI-signed object is a digitally signed data 541 object (other than a certificate or CRL) declared to be such by 542 a standards track RFC, and that can be validated using 543 certificates issued under this PKI. The content and format of 544 these data constructs depend on the context in which validation 545 of claims of current holdings of INRs takes place. Examples of 546 these objects are repository manifests [RFC6486] and Route 547 Origin Authorizations (ROAs) [RFC6482]. 549 2. Publication and Repository Responsibilities 551 2.1. Repositories 553 As per the CP, certificates, CRLs and RPKI-signed objects must be 554 made available for downloading by all relying parties, to enable them 555 to validate this data. 557 The RPKI CA will publish certificates, CRLs, 558 and RPKI-signed objects via a repository that is accessible via RSYNC 559 at . This repository will conform to the structure 560 described in [RFC6481]. 562 2.2. Publication of Certification Information 564 will publish certificates, CRLs and RPKI- 565 signed objects issued by it to a repository that operates as part of 566 a world-wide distributed system of RPKI repositories.. 568 2.3. Time or Frequency of Publication 570 579 The CA will publish its CRL prior to the 580 nextScheduledUpdate value in the scheduled CRL previously issued by 581 the CA. 583 2.4. Access Controls on Repositories 585 592 3. Identification And Authentication 594 3.1. Naming 596 3.1.1. Types of Names 598 The subject of each certificate issued by this Organization is 599 identified by an X.500 Distinguished Name (DN). The distinguished 600 name will consist of a single Common Name (CN) attribute with a 601 value generated by . Optionally, the 602 serialNumber attribute may be included along with the common name 603 (to form a terminal relative distinguished name set), to distinguish 604 among successive instances of certificates associated with the same 605 entity. 607 3.1.2. Need for Names to be Meaningful 609 The subject name in each subscriber certificate will be unique 610 relative to all certificates issued by . 611 However, there is no guarantee that the subject name will be globally 612 unique in this PKI. Also, the name of the subscriber will not be 613 ''meaningful'' in the conventional, human-readable sense. The rationale 614 here is that these certificates are used for authorization in support 615 of applications that make use of attestations of INR holdings. They 616 are not used to identify subjects. 618 3.1.3. Anonymity or Pseudonymity of Subscribers 620 Although Subject names in certificates issued by this Organization 621 need not be meaningful, and may appear ''random,'' anonymity is not a 622 function of this PKI; thus no explicit support for this feature is 623 provided. 625 3.1.4. Rules for Interpreting Various Name Forms 627 None 629 3.1.5. Uniqueness of Names 631 certifies subject names that are unique among 632 the certificates that it issues. Although it is desirable that these 633 subject names be unique throughout the PKI, to facilitate certificate 634 path discovery, such uniqueness is neither mandated nor enforced 635 through technical means. generates subject 636 names to minimize the chances that two entities in the RPKI will be 637 assigned the same name. Specifically, 640 3.1.6. Recognition, Authentication, and Role of Trademarks 642 Because the Subject names are not intended to be meaningful, makes no provision to either recognize or authenticate 644 trademarks, service marks, etc. 646 3.2. Initial Identity Validation 648 3.2.1. Method to Prove Possession of Private Key 650 655 3.2.2. Authentication of Organization Identity 657 Certificates issued under this PKI do not attest to the 658 organizational identity of subscribers. However, certificates are 659 issued to subscribers in a fashion that preserves the accuracy of 660 distributions of INRs as represented in 661 records. 663 subscriber 669 database that maintains the INR distribution records. The certificate 670 request could be matched against the database record for the 671 subscriber in question, and an RPKI certificate would be issued only 672 if the INRs requested were a subset of those held by the subscriber. 673 The specific procedures employed for this purpose should be 674 commensurate with any you already employ in the maintenance of INR 675 distribution.> 677 3.2.3. Authentication of Individual Identity 679 Certificates issued under this PKI do not attest to the individual 680 identity of a subscriber. However, maintains 681 contact information for each subscriber in support of certificate 682 renewal, re-key, and revocation. 684 BPKI (see Section 3.2.6) issues certificates that MUST 689 be used to identify individuals who represent 690 subscribers.'' The procedures should be commensurate with those you 691 already employ in authenticating individuals as representatives for 692 INR holders. Note that this authentication is solely for use by you 693 in dealing with the organizations to which you distribute (or sub- 694 distribute) INRs, and thus must not be relied upon outside of this 695 CA/subscriber relationship.> 697 3.2.4. Non-verified Subscriber Information 699 No non-verified subscriber data is included in certificates issued 700 under this certificate policy except for Subject Information Access 701 (SIA) extensions [RFC6487]. 703 3.2.5. Validation of Authority 705 714 3.2.6. Criteria for Interoperation 716 The RPKI is neither intended nor designed to interoperate with any 717 other PKI. 722 3.3. Identification and Authentication for Re-key Requests 724 3.3.1. Identification and Authentication for Routine Re-key 726 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 who holds INRs distributed by this Organization may 765 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 4.4.1. This will be done 840 within . 845 4.5. Key Pair and Certificate Usage 847 A summary of the use model for the RPKI is provided below. 849 4.5.1. Subscriber Private Key and Certificate Usage 851 The certificates issued by to subordinate INR 852 holders are CA certificates. The private key associated with each of 853 these certificates is used to sign subordinate (CA or EE) 854 certificates and CRLs. 856 4.5.2. Relying Party Public Key and Certificate Usage 858 The primary relying parties in this PKI are organizations that use 859 RPKI EE certificates to verify RPKI-signed objects. Relying parties 860 are referred to Section 4.5.2 of [RFC6484] for additional guidance 861 with respect to acts of reliance on RPKI certificates. 863 4.6. Certificate Renewal 865 4.6.1. Circumstance for Certificate Renewal 867 As per the RPKI CP, a certificate will be processed for renewal based 868 on its expiration date or a renewal request from the certificate 869 subject. The request may be implicit, a side effect of renewing a 870 resource holding agreement, or may be explicit. If initiates the renewal process based on the certificate 872 expiration date, then will notify the 873 subscriber The validity 876 interval of the new (renewed) certificate will overlap that of the 877 previous certificate by , to ensure uninterrupted coverage. 880 Certificate renewal will incorporate the same public key as the 881 previous certificate, unless the private key has been reported as 882 compromised. If a new key pair is being used, the stipulations of 883 Section 4.7 will apply. 885 4.6.2. Who May Request Renewal 887 The subscriber or may initiate the renewal 888 process. 900 4.6.3. Processing Certificate Renewal Requests 902 906 4.6.4. Notification of New Certificate Issuance to Subscriber 908 will notify the subscriber when the 909 certificate is published. 913 4.6.5. Conduct Constituting Acceptance of a Renewal Certificate 915 See Section 4.4.1 918 4.6.6. Publication of the Renewal Certificate by the CA 920 See Section 4.4.2. 922 4.6.7. Notification of Certificate Issuance by the CA to Other 923 Entities 925 See Section 4.4.3. 927 4.7. Certificate Re-key 929 4.7.1. Circumstance for Certificate Re-key 931 As per the RPKI CP, re-key of a certificate will be performed only 932 when required, based on: 934 1. knowledge or suspicion of compromise or loss of the associated 935 private key, or 937 2. the expiration of the cryptographic lifetime of the associated key 938 pair 940 If a certificate is revoked to replace the RFC 3779 extensions, the 941 replacement certificate will incorporate the same public key, not a 942 new key, unless the subscriber requests a re-key at the same time. 944 If the re-key is based on a suspected compromise, then the previous 945 certificate will be revoked. 947 Section 5.6 of the Certificate Policy notes that when a CA signs a 948 certificate, the signing key should have a validity period that 949 exceeds the validity period of the certificate. This places 950 additional constraints on when a subscriber should request a re-key. 952 4.7.2. Who May Request Certification of a New Public Key 954 Only the holder or 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 984 4.7.7. Notification of Certificate Issuance by the CA to Other 985 Entities 987 See Section 4.4.3. 989 4.8. Certificate Modification 991 4.8.1. Circumstance for Certificate Modification 993 As per the RPKI CP, modification of a certificate occurs to implement 994 changes to the RFC 3779 extension values or the SIA extension in a 995 certificate. A subscriber can request a certificate modification 996 when this information in a currently valid certificate has changed, 997 as a result of changes in the INR holdings of the subscriber or a 998 change of the repository publication point data. 1000 If a subscriber is to receive a distribution of INRs in addition to a 1001 current distribution, and if the subscriber does not request that a 1002 new certificate be issued containing only these additional INRs, then 1003 this is accomplished through a certificate modification. When a 1004 certificate modification is approved, a new certificate is issued. 1005 The new certificate will contain the same public key and the same 1006 expiration date as the original certificate, but with the incidental 1007 information corrected and/or the INR distribution expanded. When 1008 previously distributed INRs are to be removed from a certificate, 1009 then the old certificate will be revoked and a new certificate 1010 (reflecting the new distribution) issued. 1012 4.8.2. Who May Request Certificate modification 1014 The subscriber or may initiate the certificate 1015 modification process. 1019 4.8.3. Processing Certificate Modification Requests 1021 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 the RPKI CP, 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 1073 4.9.3. Procedure for Revocation Request 1075 .> 1083 4.9.4. Revocation Request Grace Period 1085 A subscriber is required request revocation as soon as possible after 1086 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 the RPKI CP, 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 nextScheduledUpdate value and a new CRL will be 1103 published at or before that time. will set the 1104 nextScheduledUpdate value when it issues a CRL, to signal when the 1105 next 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 1200 1202 5.4.2. Frequency of Processing Log 1204 1205 5.4.3. Retention Period for Audit Log 1207 1209 5.4.4. Protection of Audit Log 1211 1213 5.4.5. Audit Log Backup Procedures 1215 1217 5.4.6. Audit Collection System (Internal vs. External) [OMITTED] 1219 5.4.7. Notification to Event-causing Subject [OMITTED] 1221 5.4.8. Vulnerability Assessments 1223 1228 5.5. Records archival [OMITTED] 1230 5.6. Key Changeover 1232 The CA certificate will contain a validity 1233 period that is at least as long as that of any certificate being 1234 issued under that certificate. When CA 1235 changes keys it will follow the procedures described in [RFC6489]. 1237 5.7. Compromise and disaster recovery [OMITTED] 1239 5.8. CA or RA Termination 1241 1244 6. Technical Security Controls 1246 This section describes the security controls used by . 1249 6.1. Key Pair Generation and Installation 1251 6.1.1. Key Pair Generation 1253 1260 6.1.2. Private Key Delivery to Subscriber 1262 1267 6.1.3. Public Key Delivery to Certificate Issuer 1269 RPKI CA. These procedures 1271 should ensure that the public key has not been altered during transit 1272 and that the subscriber possesses the private key corresponding to 1273 the transferred public key. > 1275 6.1.4. CA Public Key Delivery to Relying Parties 1277 CA public keys for all entities (other than trust anchors) are 1278 contained in certificates issued by other CAs and will be published 1279 to the RPKI repository system. Relying parties will download these 1280 certificates from this system. Public key values and associated data 1281 for (putative) trust anchors will be distributed out of band and 1282 accepted by relying parties on the basis of locally-defined criteria, 1283 e.g., embedded in path validation software that will be made 1284 available to the Internet community. 1286 6.1.5. Key Sizes 1288 The key sizes used in this PKI are as specified in [RFC6485]. 1290 6.1.6. Public Key Parameters Generation and Quality Checking 1292 The public key algorithms and parameters used in this PKI are as 1293 specified in [RFC6485]. 1295 is not responsible for performing such checks 1299 for subscribers OR describe the procedures used by the CA for 1300 checking the quality of these subscriber key pairs.> 1302 6.1.7. Key Usage Purposes (as per X.509 v3 Key Usage Field) 1304 The Key usage extension bit values employed in RPKI certificates are 1305 specified in [RFC6487]. 1307 6.2. Private Key Protection and Cryptographic Module Engineering 1308 Controls 1310 6.2.1. Cryptographic module standards and controls 1312 . 1316 6.2.2. Private Key (n out of m) Multi-Person Control 1318 out of multi-person 1321 control.''> 1323 6.2.3. Private Key Escrow 1325 1328 6.2.4. Private Key Backup 1330 1335 6.2.5. Private Key Archival 1337 See sections 6.2.3 and 6.2.4 1339 6.2.6. Private Key Transfer into or from a Cryptographic Module 1341 The private key for 's production CA 1343 will be generated by the cryptographic module specified in 6.2.1. 1344 The private keys will never leave the module except in encrypted form 1345 for backup and/or transfer to a new module. 1346 6.2.7. Private Key Storage on Cryptographic Module 1348 The private key for 's production CA 1350 will be stored in the cryptographic module. It will be protected from 1351 unauthorized use . 1353 6.2.8. Method of Activating Private Key 1355 1358 6.2.9. Method of Deactivating Private Key 1360 . 1362 6.2.10. Method of Destroying Private Key 1364 1367 6.2.11. Cryptographic Module Rating 1369 1372 6.3. Other aspects of Key Pair Management 1374 6.3.1. Public Key Archival 1376 1379 6.3.2. Certificate Operational Periods and Key Pair Usage 1380 Periods 1382 The CA's key pair will have a validity 1383 interval of 1387 6.4. Activation data 1389 6.4.1. Activation Data Generation and Installation 1391 1393 6.4.2. Activation data protection 1395 Activation data for the CA private key will be protected by . 1398 6.4.3. Other Aspects of Activation Data 1400 1403 6.5. Computer Security Controls 1405 1410 6.6. Life cycle Technical Controls 1412 6.6.1. System Development Controls 1414 1417 6.6.2. Security Management Controls 1419 1423 6.6.3. Life Cycle Security Controls 1425 1429 6.7. Network Security Controls 1431 1436 6.8. Time-stamping 1438 The RPKI does not make use of time stamping. 1440 7. Certificate and CRL Profiles 1442 See [RFC6487]. 1444 8. Compliance Audit and Other Assessments 1446 1450 9. Other Business And Legal Matters 1452 1459 9.1. Fees 1461 9.1.1. Certificate issuance or renewal fees 1463 9.1.2. Fees for other services (if applicable) 1465 9.1.3. Refund policy 1467 9.2. Financial responsibility 1469 9.2.1. Insurance coverage 1471 9.2.2. Other assets 1473 9.2.3. Insurance or warranty coverage for end-entities 1475 9.3. Confidentiality of business information 1477 9.3.1. Scope of confidential information 1479 9.3.2. Information not within the scope of confidential 1480 information 1482 9.3.3. Responsibility to protect confidential information 1484 9.4. Privacy of personal information 1486 9.4.1. Privacy plan 1488 9.4.2. Information treated as private 1490 9.4.3. Information not deemed private 1492 9.4.4. Responsibility to protect private information 1494 9.4.5. Notice and consent to use private information 1496 9.4.6. Disclosure pursuant to judicial or administrative process 1498 9.4.7. Other information disclosure circumstances 1500 9.5. Intellectual property rights (if applicable) 1502 9.6. Representations and warranties 1504 9.6.1. CA representations and warranties 1505 9.6.2. Subscriber representations and warranties 1507 9.6.3. Relying party representations and warranties 1509 9.7. Disclaimers of warranties 1511 9.8. Limitations of liability 1513 9.9. Indemnities 1515 9.10. Term and termination 1517 9.10.1. Term 1519 9.10.2. Termination 1521 9.10.3. Effect of termination and survival 1523 9.11. Individual notices and communications with participants 1525 9.12. Amendments 1527 9.12.1. Procedure for amendment 1529 9.12.2. Notification mechanism and period 1531 9.13. Dispute resolution provisions 1533 9.14. Governing law 1535 9.15. Compliance with applicable law 1537 9.16. Miscellaneous provisions 1539 9.16.1. Entire agreement 1541 9.16.2. Assignment 1543 9.16.3. Severability 1545 9.16.4. Enforcement (attorneys' fees and waiver of rights) 1547 9.16.5. Force Majeure 1549 10. Security Considerations 1550 The degree to which a relying party can trust the binding embodied in 1551 a certificate depends on several factors. These factors can include 1552 the practices followed by the certification authority (CA) in 1553 authenticating the subject; the CA's operating policy, procedures, 1554 and technical security controls, including the scope of the 1555 subscriber's responsibilities (for example, in protecting the private 1556 key), and the stated responsibilities and liability terms and 1557 conditions of the CA (for example, warranties, disclaimers of 1558 warranties, and limitations of liability). This document provides a 1559 framework to address the technical, procedural, personnel, and 1560 physical security aspects of Certification Authorities, Registration 1561 Authorities, repositories, subscribers, and relying party 1562 cryptographic modules, in order to ensure that the certificate 1563 generation, publication, renewal, re-key, usage, and revocation is 1564 done in a secure manner. Specifically, Section 3 Identification and 1565 Authentication (I&A); Section 4 Certificate Life-Cycle Operational 1566 Requirements; Section 5 Facility Management, and Operational 1567 Controls; Section 6 Technical Security Controls; Section 7 1568 Certificate and CRL Profiles; and Section 8 Compliance Audit and 1569 Other Assessments are oriented towards ensuring secure operation of 1570 the PKI entities such as CA, RA, repository, subscriber systems, and 1571 relying party systems. 1573 11. IANA Considerations 1575 None. 1577 12. Acknowledgments 1579 The authors would like to thank Matt Lepinski for help with the 1580 formatting, Ron Watro for assistance with the editing, and other 1581 members of the SIDR working group for reviewing this document. 1583 13. References 1585 13.1. Normative References 1587 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1588 Requirement Levels", BCP 14, RFC 2119, March 1997. 1590 [RFC3280] Housley, R., Polk, W. Ford, W., Solo, D., "Internet X.509 1591 Public Key Infrastructure Certificate and Certificate 1592 Revocation List (CRL) Profile", BCP 14, RFC 2119, March 1593 1997. 1595 [RFC6484] Kent, S., Kong, D., Seo, K., and Watro, R., "Certificate 1596 Policy (CP) for the Resource PKI (RPKI),'' February 2012. 1598 [RFC6487] Huston, G., Michaelson, G., and Loomans, R., ''A Profile for 1599 X.509 PKIX Resource Certificates,'' February 2012. 1601 [RFC6485] Huston, G., ''A Profile for Algorithms and Key Sizes for Use 1602 in the Resource Public Key Infrastructure,'' February 2012. 1604 13.2. Informative References 1606 [BGP4] Y. Rekhter, T. Li (editors), A Border Gateway Protocol 4 1607 (BGP-4). IETF RFC 1771, March 1995. 1609 [FIPS] Federal Information Processing Standards Publication 140-3 1610 (FIPS-140-3), "Security Requirements for Cryptographic 1611 Modules", Information Technology Laboratory, National 1612 Institute of Standards and Technology, work in progress. 1614 [RSA] Rivest, R., Shamir, A., and Adelman, L. M. 1978. A method 1615 for obtaining digital signatures and public-key 1616 cryptosystems. Commun. ACM 21, 2 (Feb.), 120-126. 1618 Author's Addresses 1620 Stephen Kent 1621 BBN Technologies 1622 10 Moulton Street 1623 Cambridge MA 02138 1624 USA 1626 Phone: +1 (617) 873-3988 1627 Email: skent@bbn.com 1629 Derrick Kong 1630 BBN Technologies 1631 10 Moulton Street 1632 Cambridge MA 02138 1633 USA 1635 Phone: +1 (617) 873-1951 1636 Email: dkong@bbn.com 1638 Karen Seo 1639 BBN Technologies 1640 10 Moulton Street 1641 Cambridge MA 02138 1642 USA 1644 Phone: +1 (617) 873-3152 1645 Email: kseo@bbn.com 1647 Copyright Statement 1649 Copyright (c) 2013 IETF Trust and the persons identified as the 1650 document authors. All rights reserved. 1652 This document is subject to BCP 78 and the IETF Trust's Legal 1653 Provisions Relating to IETF Documents 1654 (http://trustee.ietf.org/license-info) in effect on the date of 1655 publication of this document. Please review these documents 1656 carefully, as they describe your rights and restrictions with respect 1657 to this document. Code Components extracted from this document must 1658 include Simplified BSD License text as described in Section 4.e of 1659 the Trust Legal Provisions and are provided without warranty as 1660 described in the Simplified BSD License.