idnits 2.17.1 draft-ietf-sidr-cps-irs-05.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 8 instances of too long lines in the document, the longest one being 31 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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5155 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: 'ARCH' is mentioned on line 379, but not defined == Missing Reference: 'OMITTED' is mentioned on line 1274, but not defined == Unused Reference: 'RFC3280' is defined on line 1658, but no explicit reference was found in the text == Unused Reference: 'BGP4' is defined on line 1675, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 1683, but no explicit reference was found in the text -- Duplicate reference: RFC2119, mentioned in 'RFC3280', was also mentioned in 'RFC2119'. -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCxxxx' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCyyyy' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCzzzz' -- Obsolete informational reference (is this intentional?): RFC 1771 (ref. 'BGP4') (Obsoleted by RFC 4271) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Secure Inter-Domain Routing (sidr) Kong, D. 2 Internet Draft Seo, K. 3 Expires: October 2010 Kent, S. 4 Intended Status: BCP BBN Technologies 5 March 8, 2010 7 Template for an 8 Internet Registry's Certification Practice Statement (CPS) 9 for the Resource PKI (RPKI) 10 draft-ietf-sidr-cps-irs-05.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on October 31, 2010. 35 Abstract 37 This document contains a template to be used for creating a 38 Certification Practice Statement (CPS) for an Internet Registry 39 (e.g., NIR or RIR) that is part of the Resource Public Key 40 Infrastructure (RPKI). 42 Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC-2119 [RFC2119]. 48 Table of Contents 50 Preface...........................................................7 51 1. Introduction...................................................8 52 1.1. Overview..................................................8 53 1.2. Document name and identification..........................9 54 1.3. PKI participants..........................................9 55 1.3.1. Certification authorities............................9 56 1.3.2. Registration authorities.............................9 57 1.3.3. Subscribers.........................................10 58 1.3.4. Relying parties.....................................10 59 1.3.5. Other participants..................................10 60 1.4. Certificate usage........................................10 61 1.4.1. Appropriate certificate uses........................10 62 1.4.2. Prohibited certificate uses.........................10 63 1.5. Policy administration....................................11 64 1.5.1. Organization administering the document.............11 65 1.5.2. Contact person......................................11 66 1.5.3. Person determining CPS suitability for the policy...11 67 1.5.4. CPS approval procedures.............................11 68 1.6. Definitions and acronyms.................................11 69 2. Publication And Repository Responsibilities...................13 70 2.1. Repositories.............................................13 71 2.2. Publication of certification information.................13 72 2.3. Time or Frequency of Publication.........................13 73 2.4. Access controls on repositories..........................13 74 3. Identification And Authentication.............................15 75 3.1. Naming...................................................15 76 3.1.1. Types of names......................................15 77 3.1.2. Need for names to be meaningful.....................15 78 3.1.3. Anonymity or pseudonymity of subscribers............15 79 3.1.4. Rules for interpreting various name forms...........15 80 3.1.5. Uniqueness of names.................................15 81 3.1.6. Recognition, authentication, and role of trademarks.16 82 3.2. Initial identity validation..............................16 83 3.2.1. Method to prove possession of private key...........16 84 3.2.2. Authentication of organization identity.............16 85 3.2.3. Authentication of individual identity...............16 86 3.2.4. Non-verified subscriber information.................17 87 3.2.5. Validation of authority.............................17 88 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 functions 101 ...........................................................19 102 4.2.2. Approval or rejection of certificate applications...19 103 4.2.3. Time to process certificate applications............20 104 4.3. Certificate issuance.....................................20 105 4.3.1. CA actions during certificate issuance..............20 106 4.3.2. Notification to subscriber by the CA of issuance of 107 certificate................................................20 108 4.3.3. Notification of certificate issuance by the CA to other 109 entities...................................................20 110 4.4. Certificate acceptance...................................20 111 4.4.1. Conduct constituting certificate acceptance.........20 112 4.4.2. Publication of the certificate by the CA............20 113 4.5. Key pair and certificate usage...........................20 114 4.5.1. Subscriber private key and certificate usage........21 115 4.5.2. Relying party public key and certificate usage......21 116 4.6. Certificate renewal......................................21 117 4.6.1. Circumstance for certificate renewal................21 118 4.6.2. Who may request renewal.............................21 119 4.6.3. Processing certificate renewal requests.............22 120 4.6.4. Notification of new certificate issuance to subscriber 121 ...........................................................22 122 4.6.5. Conduct constituting acceptance of a renewal 123 certificate................................................22 124 4.6.6. Publication of the renewal certificate by the CA....22 125 4.6.7. Notification of certificate issuance by the CA to other 126 entities...................................................22 127 4.7. Certificate re-key.......................................22 128 4.7.1. Circumstance for certificate re-key.................22 129 4.7.2. Who may request certification of a new public key...23 130 4.7.3. Processing certificate re-keying requests...........23 131 4.7.4. Notification of new certificate issuance to subscriber 132 ...........................................................23 133 4.7.5. Conduct constituting acceptance of a re-keyed 134 certificate................................................23 135 4.7.6. Publication of the re-keyed certificate by the CA...24 136 4.7.7. Notification of certificate issuance by the CA to other 137 entities...................................................24 139 4.8. Certificate modification.................................24 140 4.8.1. Circumstance for certificate modification...........24 141 4.8.2. Who may request certificate modification............24 142 4.8.3. Processing certificate modification requests........24 143 4.8.4. Notification of modified certificate issuance to 144 subscriber.................................................25 145 4.8.5. Conduct constituting acceptance of modified certificate 146 ...........................................................25 147 4.8.6. Publication of the modified certificate by the CA...25 148 4.8.7. Notification of certificate issuance by the CA to other 149 entities...................................................25 150 4.9. Certificate revocation and suspension....................25 151 4.9.1. Circumstances for revocation........................25 152 4.9.2. Who can request revocation..........................25 153 4.9.3. Procedure for revocation request....................26 154 4.9.4. Revocation request grace period.....................26 155 4.9.5. Time within which CA must process the revocation 156 request....................................................26 157 4.9.6. Revocation checking requirement for relying parties.26 158 4.9.7. CRL issuance frequency..............................26 159 4.9.8. Maximum latency for CRLs............................26 160 4.10. Certificate status services.............................26 161 5. Facility, Management, and Operational Controls................27 162 5.1. Physical controls........................................27 163 5.1.1. Site location and construction......................27 164 5.1.2. Physical access.....................................27 165 5.1.3. Power and air conditioning..........................27 166 5.1.4. Water exposures.....................................27 167 5.1.5. Fire prevention and protection......................27 168 5.1.6. Media storage.......................................27 169 5.1.7. Waste disposal......................................27 170 5.1.8. Off-site backup.....................................27 171 5.2. Procedural controls......................................27 172 5.2.1. Trusted roles.......................................27 173 5.2.2. Number of persons required per task.................27 174 5.2.3. Identification and authentication for each role.....27 175 5.2.4. Roles requiring separation of duties................27 176 5.3. Personnel controls.......................................27 177 5.3.1. Qualifications, experience, and clearance requirements 178 ...........................................................28 179 5.3.2. Background check procedures.........................28 180 5.3.3. Training requirements...............................28 181 5.3.4. Retraining frequency and requirements...............28 182 5.3.5. Job rotation frequency and sequence.................28 183 5.3.6. Sanctions for unauthorized actions..................28 184 5.3.7. Independent contractor requirements.................28 185 5.3.8. Documentation supplied to personnel.................28 186 5.4. Audit logging procedures.................................28 187 5.4.1. Types of events recorded............................28 188 5.4.2. Frequency of processing log.........................28 189 5.4.3. Retention period for audit log......................28 190 5.4.4. Protection of audit log.............................29 191 5.4.5. Audit log backup procedures.........................29 192 5.4.6. Audit collection system (internal vs. external) 193 [OMITTED]..................................................29 194 5.4.7. Notification to event-causing subject [OMITTED].....29 195 5.4.8. Vulnerability assessments...........................29 196 5.5. Records archival [OMITTED]...............................29 197 5.6. Key changeover...........................................29 198 5.7. Compromise and disaster recovery [OMITTED]...............29 199 5.8. CA or RA termination.....................................29 200 6. Technical Security Controls...................................30 201 6.1. Key pair generation and installation.....................30 202 6.1.1. Key pair generation.................................30 203 6.1.2. Private key delivery to subscriber..................30 204 6.1.3. Public key delivery to certificate issuer...........30 205 6.1.4. CA public key delivery to relying parties...........30 206 6.1.5. Key sizes...........................................31 207 6.1.6. Public key parameters generation and quality checking31 208 6.1.7. Key usage purposes (as per X.509 v3 key usage field)31 209 6.2. Private Key Protection and Cryptographic Module Engineering 210 Controls......................................................31 211 6.2.1. Cryptographic module standards and controls.........31 212 6.2.2. Private key (n out of m) multi-person control.......31 213 6.2.3. Private key escrow..................................31 214 6.2.4. Private key backup..................................32 215 6.2.5. Private key archival................................32 216 6.2.6. Private key transfer into or from a cryptographic 217 module.....................................................32 218 6.2.7. Private key storage on cryptographic module.........32 219 6.2.8. Method of activating private key....................32 220 6.2.9. Method of deactivating private key..................32 221 6.2.10. Method of destroying private key...................32 222 6.2.11. Cryptographic Module Rating........................33 223 6.3. Other aspects of key pair management.....................33 224 6.3.1. Public key archival.................................33 225 6.3.2. Certificate operational periods and key pair usage 226 periods....................................................33 227 6.4. Activation data..........................................33 228 6.4.1. Activation data generation and installation.........33 229 6.4.2. Activation data protection..........................33 230 6.4.3. Other aspects of activation data....................33 231 6.5. Computer security controls...............................33 232 6.5.1. Specific computer security technical requirement....33 233 6.6. Life cycle technical controls............................34 234 6.6.1. System development controls.........................34 235 6.6.2. Security management controls........................34 236 6.6.3. Life cycle security controls........................34 237 6.7. Network security controls................................34 238 6.8. Time-stamping............................................34 239 7. Certificate and CRL Profiles..................................34 240 8. Please refer to the Certificate and CRL Profile [RFCyyyy].....34 241 8. Compliance Audit and Other Assessments........................35 242 8.1. Frequency or circumstances of assessment.................35 243 8.2. Identity/qualifications of assessor......................35 244 8.3. Assessor's relationship to assessed entity...............35 245 8.4. Topics covered by assessment.............................35 246 8.5. Actions taken as a result of deficiency..................35 247 8.6. Communication of results.................................35 248 9. Other Business And Legal Matters..............................36 249 9.1. Fees.....................................................36 250 9.1.1. Certificate issuance or renewal fees................36 251 9.1.2. Fees for other services (if applicable).............36 252 9.1.3. Refund policy.......................................36 253 9.2. Financial responsibility.................................36 254 9.2.1. Insurance coverage..................................36 255 9.2.2. Other assets........................................36 256 9.2.3. Insurance or warranty coverage for end-entities.....36 257 9.3. Confidentiality of business information..................36 258 9.3.1. Scope of confidential information...................36 259 9.3.2. Information not within the scope of confidential 260 information................................................36 261 9.3.3. Responsibility to protect confidential information..36 262 9.4. Privacy of personal information..........................36 263 9.4.1. Privacy plan........................................36 264 9.4.2. Information treated as private......................36 265 9.4.3. Information not deemed private......................36 266 9.4.4. Responsibility to protect private information.......36 267 9.4.5. Notice and consent to use private information.......36 268 9.4.6. Disclosure pursuant to judicial or administrative 269 process....................................................36 270 9.4.7. Other information disclosure circumstances..........37 271 9.5. Intellectual property rights (if applicable).............37 272 9.6. Representations and warranties...........................37 273 9.6.1. CA representations and warranties...................37 274 9.6.2. Subscriber representations and warranties...........37 275 9.6.3. Relying party representations and warranties........37 276 9.7. Disclaimers of warranties................................37 277 9.8. Limitations of liability.................................37 278 9.9. Indemnities..............................................37 279 9.10. Term and termination....................................37 280 9.10.1. Term...............................................37 281 9.10.2. Termination........................................37 282 9.10.3. Effect of termination and survival.................37 284 9.11. Individual notices and communications with participants.37 285 9.12. Amendments..............................................37 286 9.12.1. Procedure for amendment............................37 287 9.12.2. Notification mechanism and period..................37 288 9.13. Dispute resolution provisions...........................37 289 9.14. Governing law...........................................37 290 9.15. Compliance with applicable law..........................37 291 9.16. Miscellaneous provisions................................37 292 9.16.1. Entire agreement...................................37 293 9.16.2. Assignment.........................................37 294 9.16.3. Severability.......................................37 295 9.16.4. Enforcement (attorneys' fees and waiver of rights).38 296 9.16.5. Force Majeure......................................38 297 10. Security Considerations......................................39 298 11. IANA Considerations..........................................39 299 12. Acknowledgments..............................................39 300 13. References...................................................39 301 13.1. Normative References....................................39 302 13.2. Informative References..................................40 303 Author's Addresses...............................................40 304 Pre-5378 Material Disclaimer.....................................41 305 Copyright Statement..............................................41 307 Preface 309 This document contains a template to be used for creating a 310 Certification Practice Statement (CPS) for an Internet Registry 311 (e.g., an NIR or RIR) that is part of the Resource Public Key 312 Infrastructure (RPKI). The user of this document should 314 1. substitute a title page for page 1 saying, e.g., '' Certification Practice Statement for the Resource 316 Public Key Infrastructure (RPKI)'' with date, author, etc. 318 2. delete this Preface 320 3. fill in the information indicated below by 323 4. delete sections 10, 11, 12, 13.1, Acknowledgments, Author's 324 Addresses, Intellectual Property Statement, Disclaimer of 325 Validity, Copyright Statement, Acknowledgments; leaving a 326 reference section with just the references in 13.2 328 5. update the table of contents to reflect the deletions and 329 additions above. 331 Note: This CPS is based on the template specified in RFC 3647. A 332 number of sections contained in the template were omitted from this 333 CPS because they did not apply to this PKI. However, we have 334 retained the section numbering scheme employed in the RFC to 335 facilitate comparison with the outline in the RFC. [There are 4 sub- 336 sections that I haven't removed yet due to Word problems.) 338 1. Introduction 340 This document is the Certification Practice Statement (CPS) of . It describes the practices employed by the Certification Authority (CA) in the Resource Public Key 343 Infrastructure (RPKI). These practices are defined in accordance 344 with the requirements of the Certificate Policy (CP, [RFCxxxx]) of 345 this PKI. 347 The RPKI is designed to support validation of claims by current 348 holders of Internet Number Resources (INRs, see definition in 1.7) 349 in accordance with the records of the organizations that act as CAs 350 in this PKI. The ability to verify such claims is essential to 351 ensuring the unique, unambiguous distribution of these resources 353 This PKI parallels the existing INR distribution hierarchy. These 354 resources are distributed by the Internet Assigned Numbers Authority 355 (IANA) to the Regional Internet Registries. In some regions, 356 National Internet Registries (NIRs) form a tier of the hierarchy 357 below the RIRs for internet number resource (INR) distribution. ISPs 358 and network subscribers form additional tiers below registries. 360 1.1. Overview 362 This CPS describes: 364 . Participants 366 . Publication of the certificates and CRLs 368 . How certificates are issued, managed, and revoked 370 . Facility management (physical security, personnel, audit, etc.) 372 . Key management 374 . Audit procedures 376 . Business and legal issues 378 This PKI encompasses several types of certificates (see IETF 379 document draft-ietf-sidr-arch-xx [ARCH] for more details): 381 . CA certificates for each organization distributing INRs and for 382 each subscriber (INR holder) 384 . End entity (EE) certificates for organizations to use to validate 385 digital signatures on RPKI-signed objects (see definition in 1.7). 387 . In the future, the PKI also may include end entity certificates in 388 support of access control for the repository system as described 389 in 2.4. 391 1.2. Document name and identification 393 The name of this document is '''s Certification 394 Practice Statement for the Resource Public Key Infrastructure 395 (RPKI)''. 397 1.3. PKI participants 399 Note: In a PKI, the term ''subscriber'' refers to an individual or 400 organization that is a Subject of a certificate issued by a CA. The 401 term is used in this fashion throughout this document, without 402 qualification, and should not be confused with the networking use of 403 the term to refer to an individual or organization that receives 404 service from an ISP. In such cases the term ''network subscriber'' 405 will be used. Also note that, for brevity, this document always 406 refers to PKI participants as organizations or entities, even though 407 some of them are individuals. 409 1.3.1. Certification authorities 411 portion of the RPKI. It provides a secure 415 revocation and recovery capability in case the production CA is 416 compromised or becomes unavailable. Thus the offline CA issues 417 certificates only to instances of the production CA; and the CRLs it 418 issues are used to revoke only certificates issued to the production 419 CA. The production CA is used to issue RPKI certificates to members, to whom INRs have been distributed. > 422 1.3.2. Registration authorities 424 434 1.3.3. Subscribers 436 Two types of organizations receive distributions of INRs from this 437 CA and thus are subscribers in the PKI sense: network subscribers 438 and Internet Service Providers (ISPs). Registries, who, in turn, issue 440 certificates to network subscribers or ISPs.> 442 1.3.4. Relying parties 444 Entities or individuals that act in reliance on certificates or 445 RPKI-signed objects issued under this PKI are relying parties. 446 Relying parties may or may not be subscribers within this PKI. (See 447 section 1.7 for the definition of an RPKI-signed object.) 449 1.3.5. Other participants 451 will operate a repository that holds 452 certificates, CRLs, and other RPKI-signed objects. 454 1.4. Certificate usage 456 1.4.1. Appropriate certificate uses 458 The certificates issued under this hierarchy are for authorization 459 in support of validation of claims of current holdings of INRs. 461 Additional uses of the certificates, consistent with the basic goal 462 cited above, are also permitted under the RPKI certificate policy. 464 Some of the certificates that may be issued under this PKI could be 465 used to support operation of this infrastructure, e.g., access 466 control for the repository system as described in 2.4. Such uses 467 also are permitted under the RPKI certificate policy. 469 1.4.2. Prohibited certificate uses 471 Any uses other than those described in Section 1.4.1 are prohibited. 473 1.5. Policy administration 475 1.5.1. Organization administering the document 477 This CPS is administered by . 479 1.5.2. Contact person 481 483 1.5.3. Person determining CPS suitability for the policy 485 Not applicable. Each organization issuing a certificate in this PKI 486 is attesting to the distribution of INRs to the holder of the 487 private key corresponding to the public key in the certificate. The 488 issuing organizations are the same organizations as the ones that 489 perform the distribution hence they are authoritative with respect 490 to the accuracy of this binding. 492 1.5.4. CPS approval procedures 494 Not applicable. Each organization issuing a certificate in this PKI 495 is attesting to the distribution of INRs to the holder of the 496 private key corresponding to the public key in the certificate. The 497 issuing organizations are the same organizations as the ones that 498 perform the distribution hence they are authoritative with respect 499 to the accuracy of this binding. 501 1.6. Definitions and acronyms 503 BPKI - Business PKI. A BPKI is an optional additional PKI used by an 504 RIR to identify members to whom RPKI certificates can be 505 issued. 507 CP - Certificate Policy. A CP is a named set of rules that 508 indicates the applicability of a certificate to a particular 509 community and/or class of applications with common security 510 requirements. 512 CPS - Certification Practice Statement. A CPS is a document that 513 specifies the practices that a Certification Authority employs 514 in issuing certificates. 516 Distribution of INRs - - A process of distribution of the INRs along 517 the respective number hierarchy. IANA distributes blocks of IP 518 addresses and Autonomous System Numbers to the five Regional 519 Internet Registries (RIRs). RIRs distribute smaller address 520 blocks and Autonomous System Numbers to organizations within 521 their service regions, who in turn distribute IP addresses to 522 their customers. 524 IANA - Internet Assigned Numbers Authority. IANA is responsible 525 for global coordination of the Internet Protocol addressing 526 systems and Autonomous System (AS) numbers used for routing 527 internet traffic. IANA distributes INRs to Regional Internet 528 Registries (RIRs). 530 INRs - Internet Number Resources. INRs are number values for three 531 protocol parameter sets, namely: 533 . IP Version 4 addresses, 535 . IP version 6 addresses, and 537 . Identifiers used in Internet inter-domain routing, currently 538 Border Gateway Protocol-4 Autonomous System numbers. 540 ISP - - Internet Service Provider. An ISP is an organization managing 541 and selling Internet services to other organizations. 543 NIR - - National Internet Registry. An NIR is an organization that 544 manages the distribution of INRS for a portion of the 545 geopolitical area covered by a Regional Registry. NIRs form an 546 optional second tier in the tree scheme used to manage INR 547 distribution. 549 RIR - Regional Internet Registry. An RIR is an organization that 550 manages the distribution of INRs for a geopolitical area. 552 RPKI-signed object - - An RPKI-signed object is a digitally signed 553 data object (other than a certificate or CRL) declared to be 554 such by a standards track RFC, and that can be validated using 555 certificates issued under this PKI. The content and format of 556 these data constructs depend on the context in which 557 validation of claims of current holdings of INRs takes place. 558 Examples of these objects are repository manifests and CRLs. 560 2. Publication And Repository Responsibilities 562 2.1. Repositories 564 As per the CP, certificates, CRLs and RPKI-signed objects MUST be 565 made available for downloading by all relying parties to enable them 566 to validate this data. 568 The RPKI CA will publish certificates, CRLs, and 569 RPKI-signed objects via a repository that is accessible via RSYNC at 570 rpki..net. 572 2.2. Publication of certification information 574 MUST publish certificates, CRLs, and RPKI-signed 575 objects issued by it to a local repository system that it operates 576 as part of a world-wide distributed system of repositories. 578 2.3. Time or Frequency of Publication 580 589 As per the CP, the following standard exists for publication times 590 and frequency: 592 The RPKI CA MUST publish its CRL prior to the 593 nextScheduledUpdate value in the scheduled CRL previously issued by 594 the CA. 596 2.4. Access controls on repositories 598 Access to the repository system, for modification of entries, must 599 be controlled to prevent denial of service attacks. All data 600 (certificates, CRLs and RPKI-signed objects) published to a 601 repository are digitally signed. RPKI items that 602 issues MUST be published to the repository that it runs by means not 603 accessible to the outside world. offers 604 repository services to its subscribers, then 608 3. Identification And Authentication 610 3.1. Naming 612 3.1.1. Types of names 614 The Subject of each certificate issued by this Registry is 615 identified by an X.500 Distinguished Name (DN). The distinguished 616 name will consist of a single Common Name (CN) attribute with a 617 value generated by . Optionally, the serialNumber 618 attribute may be included along with the common name (to form a 619 terminal relative distinguished name set), to distinguish among 620 successive instances of certificates associated with the same 621 entity. 623 3.1.2. Need for names to be meaningful 625 The Subject name in each subscriber certificate will be unique 626 relative to all certificates issued by . However, 627 there is no guarantee that the subject name will be globally unique 628 in this PKI. Also, the name of the subscriber need not to be 629 ''meaningful'' in the conventional, human-readable sense. The 630 certificates issued under this PKI are used for authorization in 631 support of applications that make use of attestations of Internet 632 resource holding, not for identification 634 3.1.3. Anonymity or pseudonymity of subscribers 636 Although Subject names in certificates issued by this registry need 637 not be meaningful, and may appear ''random,'' anonymity is not a 638 function of this PKI, and thus no explicit support for this feature 639 is provided. 641 3.1.4. Rules for interpreting various name forms 643 None 645 3.1.5. Uniqueness of names 647 certifies Subject names that are unique among the 648 certificates that it issues. Although it is desirable that these 649 Subject names be unique throughout the PKI, to facilitate 650 certificate path discovery, such uniqueness is neither mandated nor 651 enforced through technical means. 653 3.1.6. Recognition, authentication, and role of trademarks 655 Because the Subject names are not intended to be meaningful, there 656 is no provision to recognize or authenticate trademarks, service 657 marks, etc. 659 3.2. Initial identity validation 661 3.2.1. Method to prove possession of private key 663 issuing the certificate. One possible approach makes 667 use of the PKCS #10 format, as profiled in [RFCyyyy]. This request 668 format requires that the PKCS #10 request be signed using the (RSA) 669 private key corresponding to the public key in the certificate 670 request. This mechanism provides proof of possession by the 671 requester.> 673 3.2.2. Authentication of organization identity 675 Certificates issued under this PKI do not attest to the 676 organizational identity of subscribers, with the exception of 677 registries. However, certificates are issued to subscribers in a 678 fashion that preserves the accuracy of distributions as represented 679 in records. 681 subscriber database 684 that maintains the INR distribution records. The certificate request 685 could be matched against the database record for the subscriber in 686 question, and an RPKI certificate would be issued only if the INRs 687 requested were a subset of those held by the subscriber.> 689 3.2.3. Authentication of individual identity 691 Certificates issued under this PKI do not attest to the individual 692 identity of a subscriber. However, maintains 693 contact information for each subscriber in support of certificate 694 renewal, re-key, or revocation. 696 < Describe the procedures that MUST be used to identify at least one 697 individual as a representative of each subscriber. This is done in 698 support of issuance, renewal, and revocation of the certificate 699 issued to the organization. For example, one might say ''The BPKI (see Section 3.2.6) issues certificates that MUST be 701 used to identify individuals who represent 702 subscribers.'' The procedures should be commensurate with those you 703 already employ in authenticating individuals as representatives for 704 INR holders. Note that this authentication is solely for use by you 705 in dealing with the organizations to which you distribute (or sub- 706 distribute) INRs, and thus must not be relied upon outside of this 707 CA-subscriber relationship> 709 3.2.4. Non-verified subscriber information 711 No non-verified subscriber data is included in certificates issued 712 under this certificate policy except for SIA/AIA extensions. 714 3.2.5. Validation of authority 716 726 3.2.6. Criteria for interoperation 728 The RPKI is neither intended nor designed to interoperate with any 729 other PKI. 734 3.3. Identification and authentication for re-key requests 736 3.3.1. Identification and authentication for routine re-key 738 746 3.3.2. Identification and authentication for re-key after revocation 748 758 3.4. Identification and authentication for revocation request 760 770 Note that if a Subscriber requests a new INR distribution, an 771 existing RPKI certificate issued to the subscriber is NOT revoked, 772 so long as the set of INRs distributed to the subscriber did not 773 ''shrink,'' i.e., the new INRs are a superset of the old INR set. 774 However, if a new INR distribution results in ''shrinkage'' of the set 775 of INRs distributed to a subscriber, this triggers an implicit 776 revocation of the old RPKI certificate(s) associated with that 777 subscriber. 779 4. Certificate Life-Cycle Operational Requirements 781 4.1. Certificate Application 783 4.1.1. Who can submit a certificate application 785 Any subscriber who holds INRs distributed by this registry may 786 submit a certificate application to this CA. 788 4.1.2. Enrollment process and responsibilities 790 798 4.2. Certificate application processing 800 807 4.2.1. Performing identification and authentication functions 809 815 4.2.2. Approval or rejection of certificate applications 817 827 4.2.3. Time to process certificate applications 829 832 4.3. Certificate issuance 834 4.3.1. CA actions during certificate issuance 836 839 4.3.2. Notification to subscriber by the CA of issuance of certificate 841 MUST notify the subscriber when the certificate 842 is published. 845 4.3.3. Notification of certificate issuance by the CA to other entities 847 850 4.4. Certificate acceptance 852 4.4.1. Conduct constituting certificate acceptance 854 When a certificate is issued, the CA MUST publish it to the 855 repository and notify the subscriber. This will be done without 856 subscriber review and acceptance. 858 4.4.2. Publication of the certificate by the CA 860 Certificates MUST be published in the RPKI distributed repository 861 system via publication of the certificate at 's 862 repository publication. This will be done within . 867 4.5. Key pair and certificate usage 869 A summary of the use model for the RPKI is provided below. 871 4.5.1. Subscriber private key and certificate usage 873 The certificates issued by to subscribers are CA 874 certificates. The private key associated with each of these 875 certificates is used to sign subordinate (CA or EE) certificates and 876 CRLs. A subscriber may in turn issue certificates to any 877 organizations to which it distributes INRs and may issue one or more 878 EE certificates for use in verifying signatures on RPKI-signed 879 objects signed by the subscriber. Subscribers also will issue 880 certificates to operators in support of repository access control. 882 4.5.2. Relying party public key and certificate usage 884 The primary relying parties in this PKI are organizations who will 885 use RPKI EE certificates to verify RPKI-signed objects. Repositories 886 will use operator certificates to verify the authorization of 887 entities to engage in repository maintenance activities, and thus 888 repositories represent a secondary type of relying party. 890 4.6. Certificate renewal 892 4.6.1. Circumstance for certificate renewal 894 As per the CP, a certificate MUST be processed for renewal based on 895 its expiration date or a renewal request from the certificate 896 Subject. The request may be implicit, a side effect of renewing its 897 resource holding agreement, or may be explicit. If initiates the renewal process based on the certificate 899 expiration date, then will notify the subscriber 900 The validity interval of 903 the new (renewed) certificate will overlap that of the previous 904 certificate by , to 905 ensure uninterrupted coverage. 907 Certificate renewal will incorporate the same public key as the 908 previous certificate, unless the private key has been reported as 909 compromised. If a new key pair is being used, the stipulations of 910 Section 4.7 will apply. 912 4.6.2. Who may request renewal 914 The subscriber or may initiate the renewal 915 process. 927 4.6.3. Processing certificate renewal requests 929 934 4.6.4. Notification of new certificate issuance to subscriber 936 MUST notify the subscriber when the certificate 937 is published. 941 4.6.5. Conduct constituting acceptance of a renewal certificate 943 When a renewal certificate is issued, MUST 944 publish it to the repository and notify the subscriber. This will be 945 done without subscriber review and acceptance. 947 4.6.6. Publication of the renewal certificate by the CA 949 952 4.6.7. Notification of certificate issuance by the CA to other entities 954 957 4.7. Certificate re-key 959 4.7.1. Circumstance for certificate re-key 961 As per the CP, re-key of a certificate will be performed only when 962 required, based on: 964 (1) knowledge or suspicion of compromise or loss of the associated 965 private key, or 967 (2) the expiration of the cryptographic lifetime of the associated 968 key pair 970 If a certificate is revoked to replace the RFC 3779 extensions, the 971 replacement certificate will incorporate the same public key, not a 972 new key, unless the subscriber requests a re-key at the same time. 974 If the re-key is based on a suspected compromise, then the previous 975 certificate will be revoked. 977 Section 5.6 of the Certificate Policy notes that when a CA signs a 978 certificate, the signing key should have a validity period that 979 exceeds the validity period of the certificate. This places 980 additional constraints on when a CA should request a re-key. 982 4.7.2. Who may request certification of a new public key 984 Only the subscriber may request a re-key. In addition, may initiate a re-key based on a verified compromise 986 report. BPKI. Describe how a compromise report received from other 989 than a subscriber is verified.> 991 4.7.3. Processing certificate re-keying requests 993 997 4.7.4. Notification of new certificate issuance to subscriber 999 1004 4.7.5. Conduct constituting acceptance of a re-keyed certificate 1006 When a re-keyed certificate is issued, the CA will publish it in the 1007 repository and notify the subscriber. This will be done without 1008 subscriber review and acceptance. 1010 4.7.6. Publication of the re-keyed certificate by the CA 1012 1016 4.7.7. Notification of certificate issuance by the CA to other entities 1018 1021 4.8. Certificate modification 1023 4.8.1. Circumstance for certificate modification 1025 As per the CP, modification of a certificate occurs to implement 1026 changes to the RFC 3779 extension values in a certificate. A 1027 subscriber can request a certificate modification when this 1028 information in a currently valid certificate has changed as a result 1029 of changes in the INR holdings of the subscriber. 1031 If INRs are to be distributed to a subscriber and the INRs are in 1032 addition to a current distribution, and if the subscriber does not 1033 request that a new certificate be issued containing only these 1034 additional resources, then this is accomplished through a 1035 certificate modification. When a certificate modification is 1036 approved, a new certificate is issued. The new certificate will 1037 contain the same public key and the same expiration date as the 1038 original certificate, but with the incidental information corrected 1039 and/or the INR distribution expanded. When previously distributed 1040 INRs are to be removed from a certificate, then the old certificate 1041 MUST be revoked and a new certificate (reflecting the new 1042 distribution) issued. 1044 4.8.2. Who may request certificate modification 1046 The subscriber or may initiate the certificate 1047 modification process. 1051 4.8.3. Processing certificate modification requests 1053 1058 4.8.4. Notification of modified certificate issuance to subscriber 1060 1065 4.8.5. Conduct constituting acceptance of modified certificate 1067 When a modified certificate is issued, the will 1068 publish in the repository and notify the subscriber. This will be 1069 done without subscriber review and acceptance. 1071 4.8.6. Publication of the modified certificate by the CA 1073 1077 4.8.7. Notification of certificate issuance by the CA to other entities 1079 1082 4.9. Certificate revocation and suspension 1084 4.9.1. Circumstances for revocation 1086 As per the CP, certificates can be revoked for several reasons. 1087 Either or the subject may choose to end the 1088 relationship expressed in the certificate, thus creating cause to 1089 revoke the certificate. If one or more of the INRs bound to the 1090 public key in the certificate are no longer associated with the 1091 subject, that too constitutes a basis for revocation. A certificate 1092 also may be revoked due to loss or compromise of the private key 1093 corresponding to the public key in the certificate. Finally, a 1094 certificate may be revoked in order to invalidate data signed by the 1095 private key associated with that certificate. 1097 4.9.2. Who can request revocation 1099 The subscriber or may request a revocation. 1104 4.9.3. Procedure for revocation request 1106 .> 1114 4.9.4. Revocation request grace period 1116 A subscriber should request revocation as soon as possible after the 1117 need for revocation has been identified. 1119 4.9.5. Time within which CA must process the revocation request 1121 1124 4.9.6. Revocation checking requirement for relying parties 1126 As per the CP, a relying party is responsible for acquiring and 1127 checking the most recent, scheduled CRL from the issuer of the 1128 certificate, whenever the relying party validates a certificate. 1130 4.9.7. CRL issuance frequency 1132 1133 Each CRL will carry a nextScheduledUpdate value; and a new CRL will 1134 be published at or before that time. will set 1135 the nextScheduledUpdate value when it issues a CRL, to signal when 1136 the next scheduled CRL will be issued. 1138 4.9.8. Maximum latency for CRLs 1140 A CRL will be published to the repository system within after generation. 1143 4.10. Certificate status services 1145 does not support OCSP or SCVP. 1146 issues CRLs. 1148 5. Facility, Management, and Operational Controls 1150 5.1. Physical controls 1152 1156 5.1.1. Site location and construction 1158 5.1.2. Physical access 1160 5.1.3. Power and air conditioning 1162 5.1.4. Water exposures 1164 5.1.5. Fire prevention and protection 1166 5.1.6. Media storage 1168 5.1.7. Waste disposal 1170 5.1.8. Off-site backup 1172 5.2. Procedural controls 1174 1178 5.2.1. Trusted roles 1180 5.2.2. Number of persons required per task 1182 5.2.3. Identification and authentication for each role 1184 5.2.4. Roles requiring separation of duties 1186 5.3. Personnel controls 1188 1193 5.3.1. Qualifications, experience, and clearance requirements 1195 5.3.2. Background check procedures 1197 5.3.3. Training requirements 1199 5.3.4. Retraining frequency and requirements 1201 5.3.5. Job rotation frequency and sequence 1203 5.3.6. Sanctions for unauthorized actions 1205 5.3.7. Independent contractor requirements 1207 5.3.8. Documentation supplied to personnel 1209 5.4. Audit logging procedures 1211 1214 5.4.1. Types of events recorded 1216 Audit records will be generated for the basic operations of the 1217 certification authority computing equipment. Audit records will 1218 include the date, time, responsible user or process, and summary 1219 content data relating to the event. Auditable events include: 1221 Access to CA computing equipment (e.g., logon, logout) 1223 Messages received requesting CA actions (e.g., certificate requests, 1224 certificate revocation requests, compromise notifications) 1226 Certificate creation, modification, revocation, or renewal actions 1228 Posting of any material to a repository 1230 Any attempts to change or delete audit data 1232 1234 5.4.2. Frequency of processing log 1236 1238 5.4.3. Retention period for audit log 1240 1242 5.4.4. Protection of audit log 1244 1246 5.4.5. Audit log backup procedures 1248 1250 5.4.6. Audit collection system (internal vs. external) [OMITTED] 1252 5.4.7. Notification to event-causing subject [OMITTED] 1254 5.4.8. Vulnerability assessments 1256 1261 5.5. Records archival [OMITTED] 1263 5.6. Key changeover 1265 The CA certificate will contain a validity period 1266 that is at least as long as that of any certificate being issued 1267 under that certificate. When CA wishes to change 1268 keys, will create a new signature key pair, and 1269 acquire and publish a new certificate containing the public key of 1270 the pair, in advance of the scheduled change of the 1272 current signature key pair. 1274 5.7. Compromise and disaster recovery [OMITTED] 1276 5.8. CA or RA termination 1278 1281 6. Technical Security Controls 1283 This section describes the security controls used by . 1286 6.1. Key pair generation and installation 1288 6.1.1. Key pair generation 1290 1302 6.1.2. Private key delivery to subscriber 1304 1309 6.1.3. Public key delivery to certificate issuer 1311 RPKI CA. These procedures 1313 should ensure that the public key has not been altered during 1314 transit and that the subscriber possesses the private key 1315 corresponding to the transferred public key. > 1317 6.1.4. CA public key delivery to relying parties 1319 CA public keys for all entities (other than trust anchors) are 1320 contained in certificates issued by other CAs and MUST be published 1321 to the RPKI repository system. Relying parties MUST download these 1322 certificates from this system. Public key values and associated data 1323 for (putative) trust anchors MUST be distributed out of band and 1324 accepted by relying parties on the basis of locally-defined 1325 criteria, e.g., embedded in path validation software that will be 1326 made available to the Internet community. 1328 6.1.5. Key sizes 1330 The key sizes used in this PKI are as specified in RFC ZZZZ 1331 [RFCzzzz]. 1333 6.1.6. Public key parameters generation and quality checking 1335 The public key algorithms and parameters used in this PKI are as 1336 specified in RFC ZZZZ [RFCzzzz]. 1339 is not responsible for performing 1343 such checks for subscribers OR describe the procedures used by the 1344 CA for checking the quality of these subscriber key pairs.> 1346 6.1.7. Key usage purposes (as per X.509 v3 key usage field) 1348 The Key usage extension bit values will be consistent with RFC 5280. 1349 For 's CA certificates, the keyCertSign and 1350 cRLSign bits will be set TRUE. All other bits (including 1351 digitalSignature) will be set FALSE, and the extension will be 1352 marked critical. 1356 6.2. Private Key Protection and Cryptographic Module Engineering 1357 Controls 1359 6.2.1. Cryptographic module standards and controls 1361 The CA employs a cryptographic module evaluated 1362 under FIPS 140-2/3, at level 3 [FIPS]. 1364 6.2.2. Private key (n out of m) multi-person control 1366 out of multi-person 1369 control.''> 1371 6.2.3. Private key escrow 1373 No private key escrow procedures are required for this PKI. 1375 6.2.4. Private key backup 1377 1383 6.2.5. Private key archival 1385 See sections 6.2.3 and 6.2.4 1387 6.2.6. Private key transfer into or from a cryptographic module 1389 The private keys for 's production CA < if 1390 appropriate, change ''production CA'' to ''production and offline CAs''> 1391 MUST be generated by the cryptographic module specified in 6.2.1. 1392 The private keys will never leave the module except in encrypted 1393 form for backup and/or transfer to a new module. 1395 6.2.7. Private key storage on cryptographic module 1397 The private key for 's production CA 1399 MUST be stored in the cryptographic module and will be protected 1400 from unauthorized use in accordance with the FIPS 140-2/3 1401 requirements applicable to the module. (See [FIPS]) 1403 6.2.8. Method of activating private key 1405 1408 6.2.9. Method of deactivating private key 1410 The cryptographic module, when activated, will not be left 1411 unattended. After use, it will be deactivated by The module 1413 will be stored securely when not in use. 1415 6.2.10. Method of destroying private key 1417 1421 6.2.11. Cryptographic Module Rating 1423 The cryptographic module used by the production 1424 CA will be certified FIPS 140-2/3, at level 3 [FIPS]. 1426 6.3. Other aspects of key pair management 1428 6.3.1. Public key archival 1430 Because this PKI does not support non-repudiation, there is no need 1431 to archive public keys. 1433 6.3.2. Certificate operational periods and key pair usage periods 1435 The CA's key pair will have a validity interval 1436 of 1440 6.4. Activation data 1442 6.4.1. Activation data generation and installation 1444 1446 6.4.2. Activation data protection 1448 Activation data for the CA private key will be protected by 1449 . 1451 6.4.3. Other aspects of activation data 1453 1456 6.5. Computer security controls 1458 6.5.1. Specific computer security technical requirement 1460 1466 6.6. Life cycle technical controls 1468 6.6.1. System development controls 1470 1474 6.6.2. Security management controls 1476 1481 6.6.3. Life cycle security controls 1483 1488 6.7. Network security controls 1490 1495 6.8. Time-stamping 1497 The RPKI does not make use of time stamping. 1499 7. Certificate and CRL Profiles 1501 8. Please refer to the Certificate and CRL Profile [RFCyyyy]. 1503 Compliance Audit and Other Assessments 1505 1509 8.1. Frequency or circumstances of assessment 1511 8.2. Identity/qualifications of assessor 1513 8.3. Assessor's relationship to assessed entity 1515 8.4. Topics covered by assessment 1517 8.5. Actions taken as a result of deficiency 1519 8.6. Communication of results 1520 9. Other Business And Legal Matters 1522 1529 9.1. Fees 1531 9.1.1. Certificate issuance or renewal fees 1533 9.1.2. Fees for other services (if applicable) 1535 9.1.3. Refund policy 1537 9.2. Financial responsibility 1539 9.2.1. Insurance coverage 1541 9.2.2. Other assets 1543 9.2.3. Insurance or warranty coverage for end-entities 1545 9.3. Confidentiality of business information 1547 9.3.1. Scope of confidential information 1549 9.3.2. Information not within the scope of confidential information 1551 9.3.3. Responsibility to protect confidential information 1553 9.4. Privacy of personal information 1555 9.4.1. Privacy plan 1557 9.4.2. Information treated as private 1559 9.4.3. Information not deemed private 1561 9.4.4. Responsibility to protect private information 1563 9.4.5. Notice and consent to use private information 1565 9.4.6. Disclosure pursuant to judicial or administrative process 1566 9.4.7. Other information disclosure circumstances 1568 9.5. Intellectual property rights (if applicable) 1570 9.6. Representations and warranties 1572 9.6.1. CA representations and warranties 1574 9.6.2. Subscriber representations and warranties 1576 9.6.3. Relying party representations and warranties 1578 9.7. Disclaimers of warranties 1580 9.8. Limitations of liability 1582 9.9. Indemnities 1584 9.10. Term and termination 1586 9.10.1. Term 1588 9.10.2. Termination 1590 9.10.3. Effect of termination and survival 1592 9.11. Individual notices and communications with participants 1594 9.12. Amendments 1596 9.12.1. Procedure for amendment 1598 9.12.2. Notification mechanism and period 1600 9.13. Dispute resolution provisions 1602 9.14. Governing law 1604 9.15. Compliance with applicable law 1606 9.16. Miscellaneous provisions 1608 9.16.1. Entire agreement 1610 9.16.2. Assignment 1612 9.16.3. Severability 1613 9.16.4. Enforcement (attorneys' fees and waiver of rights) 1615 9.16.5. Force Majeure 1616 10. Security Considerations 1618 The degree to which a relying party can trust the binding embodied 1619 in a certificate depends on several factors. These factors can 1620 include the practices followed by the certification authority (CA) 1621 in authenticating the subject; the CA's operating policy, 1622 procedures, and technical security controls, including the scope of 1623 the subscriber's responsibilities (for example, in protecting the 1624 private key), and the stated responsibilities and liability terms 1625 and conditions of the CA (for example, warranties, disclaimers of 1626 warranties, and limitations of liability). This document provides a 1627 framework to address the technical, procedural, personnel, and 1628 physical security aspects of Certification Authorities, Registration 1629 Authorities, repositories, subscribers, and relying party 1630 cryptographic modules, in order to ensure that the certificate 1631 generation, publication, renewal, re-key, usage, and revocation is 1632 done in a secure manner. Specifically, Section 3 Identification and 1633 Authentication (I&A); Section 4 Certificate Life-Cycle Operational 1634 Requirements; Section 5 Facility Management, and Operational 1635 Controls; Section 6 Technical Security Controls; Section 7 1636 Certificate and CRL Profiles; and Section 8 Compliance Audit and 1637 Other Assessments are oriented towards ensuring secure operation of 1638 the PKI entities such as CA, RA, repository, subscriber systems, and 1639 relying party systems. 1641 11. IANA Considerations 1643 None. 1645 12. Acknowledgments 1647 The authors would like to thank Geoff Huston for reviewing this 1648 document, Matt Lepinski for his help with the formatting, and Ron 1649 Watro for assistance with editing. 1651 13. References 1653 13.1. Normative References 1655 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1656 Requirement Levels", BCP 14, RFC 2119, March 1997. 1658 [RFC3280] Housley, R., Polk, W. Ford, W., Solo, D., ''Internet 1659 X.509 Public Key Infrastructure Certificate and Certificate 1660 Revocation List (CRL) Profile,'' BCP 14, RFC 2119, March 1997. 1662 [RFCxxxx] Seo, K., Watro, R., Kong, D., and Kent, S., 1663 ''Certificate Policy for the Resource PKI (RPKI),'' work in 1664 progress. 1666 [RFCyyyy] Huston, G., Michaelson, G., Loomans, R., ''A Profile for 1667 X.509 PKIX Resource Certificates,'' work in progress. 1669 [RFCzzzz] Huston, G., ''A Profile for Algorithms and Key Sizes for 1670 use in the Resource Public Key Infrastructure,'' work in 1671 progress. 1673 13.2. Informative References 1675 [BGP4] Y. Rekhter, T. Li (editors), A Border Gateway Protocol 4 1676 (BGP-4). IETF RFC 1771, March 1995. 1678 [FIPS] Federal Information Processing Standards Publication 140-3 1679 (FIPS-140-3), "Security Requirements for Cryptographic 1680 Modules", Information Technology Laboratory, National 1681 Institute of Standards and Technology, work in progress. 1683 [RSA] Rivest, R., Shamir, A., and Adelman, L. M. 1978. A method for 1684 obtaining digital signatures and public-key cryptosystems. 1685 Commun. ACM 21, 2 (Feb.), 120-126. 1687 Author's Addresses 1689 Stephen Kent 1690 BBN Technologies 1691 10 Moulton Street 1692 Cambridge MA 02138 1693 USA 1694 Phone: +1 (617) 873-3988 1695 Email: skent@bbn.com 1697 Derrick Kong 1698 BBN Technologies 1699 10 Moulton Street 1700 Cambridge MA 02138 1701 USA 1703 Phone: +1 (617) 873-1951 1704 Email: dkong@bbn.com 1706 Karen Seo 1707 BBN Technologies 1708 10 Moulton Street 1709 Cambridge MA 02138 1710 USA 1712 Phone: +1 (617) 873-3152 1713 Email: kseo@bbn.com 1715 Pre-5378 Material Disclaimer 1717 This document may contain material from IETF Documents or IETF 1718 Contributions published or made publicly available before November 1719 10, 2008. The person(s) controlling the copyright in some of this 1720 material may not have granted the IETF Trust the right to allow 1721 modifications of such material outside the IETF Standards Process. 1722 Without obtaining an adequate license from the person(s) controlling 1723 the copyright in such materials, this document may not be modified 1724 outside the IETF Standards Process, and derivative works of it may 1725 not be created outside the IETF Standards Process, except to format 1726 it for publication as an RFC or to translate it into languages other 1727 than English. 1729 Copyright Statement 1731 Copyright (c) 2010 IETF Trust and the persons identified as the 1732 document authors. All rights reserved. 1734 This document is subject to BCP 78 and the IETF Trust's Legal 1735 Provisions Relating to IETF Documents 1736 (http://trustee.ietf.org/license-info) in effect on the date of 1737 publication of this document. Please review these documents 1738 carefully, as they describe your rights and restrictions with 1739 respect to this document. Code Components extracted from this 1740 document must include Simplified BSD License text as described in 1741 Section 4.e of the Trust Legal Provisions and are provided without 1742 warranty as described in the Simplified BSD License.