idnits 2.17.1 draft-ietf-sidr-cps-isp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 32 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 5156 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 372, but not defined == Missing Reference: 'OMITTED' is mentioned on line 1262, but not defined == Unused Reference: 'RFC3280' is defined on line 1642, but no explicit reference was found in the text == Unused Reference: 'BGP4' is defined on line 1659, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 1667, 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 Internet Service Provider's Certification Practice 8 Statement (CPS) for the Resource PKI (RPKI) 9 draft-ietf-sidr-cps-isp-04.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 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on October 31, 2010. 34 Abstract 36 This document contains a template to be used for creating a 37 Certification Practice Statement (CPS) for an Internet Service 38 Provider (ISP) that is part of the Resource Public Key Infrastructure 39 (RPKI). 41 Conventions used in this document 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC-2119 [RFC2119]. 47 Table of Contents 49 Preface...........................................................7 50 1. Introduction...................................................8 51 1.1. Overview..................................................8 52 1.2. Document name and identification..........................9 53 1.3. PKI participants..........................................9 54 1.3.1. Certification authorities............................9 55 1.3.2. Registration authorities.............................9 56 1.3.3. Subscribers.........................................10 57 1.3.4. Relying parties.....................................10 58 1.3.5. Other participants..................................10 59 1.4. Certificate usage........................................10 60 1.4.1. Appropriate certificate uses........................10 61 1.4.2. Prohibited certificate uses.........................10 62 1.5. Policy administration....................................11 63 1.5.1. Organization administering the document.............11 64 1.5.2. Contact person......................................11 65 1.5.3. Person determining CPS suitability for the policy...11 66 1.5.4. CPS approval procedures.............................11 67 1.6. Definitions and acronyms.................................11 68 2. Publication And Repository Responsibilities...................13 69 2.1. Repositories.............................................13 70 2.2. Publication of certification information.................13 71 2.3. Time or Frequency of Publication.........................13 72 2.4. Access controls on repositories..........................13 73 3. Identification And Authentication.............................15 74 3.1. Naming...................................................15 75 3.1.1. Types of names......................................15 76 3.1.2. Need for names to be meaningful.....................15 77 3.1.3. Anonymity or pseudonymity of subscribers............15 78 3.1.4. Rules for interpreting various name forms...........15 79 3.1.5. Uniqueness of names.................................15 80 3.1.6. Recognition, authentication, and role of trademarks.16 81 3.2. Initial identity validation..............................16 82 3.2.1. Method to prove possession of private key...........16 83 3.2.2. Authentication of organization identity.............16 84 3.2.3. Authentication of individual identity...............16 85 3.2.4. Non-verified subscriber information.................17 86 3.2.5. Validation of authority.............................17 87 3.2.6. Criteria for interoperation.........................17 88 3.3. Identification and authentication for re-key requests....17 89 3.3.1. Identification and authentication for routine re-key17 90 3.3.2. Identification and authentication for re-key after 91 revocation.................................................18 92 3.4. Identification and authentication for revocation request.18 93 4. Certificate Life-Cycle Operational Requirements...............19 94 4.1. Certificate Application..................................19 95 4.1.1. Who can submit a certificate application............19 96 4.1.2. Enrollment process and responsibilities.............19 97 4.2. Certificate application processing.......................19 98 4.2.1. Performing identification and authentication functions19 99 4.2.2. Approval or rejection of certificate applications...19 100 4.2.3. Time to process certificate applications............20 101 4.3. Certificate issuance.....................................20 102 4.3.1. CA actions during certificate issuance..............20 103 4.3.2. Notification to subscriber by the CA of issuance of 104 certificate................................................20 105 4.3.3. Notification of certificate issuance by the CA to other 106 entities...................................................20 107 4.4. Certificate acceptance...................................20 108 4.4.1. Conduct constituting certificate acceptance.........20 109 4.4.2. Publication of the certificate by the CA............20 110 4.5. Key pair and certificate usage...........................20 111 4.5.1. Subscriber private key and certificate usage........21 112 4.5.2. Relying party public key and certificate usage......21 113 4.6. Certificate renewal......................................21 114 4.6.1. Circumstance for certificate renewal................21 115 4.6.2. Who may request renewal.............................21 116 4.6.3. Processing certificate renewal requests.............22 117 4.6.4. Notification of new certificate issuance to subscriber22 118 4.6.5. Conduct constituting acceptance of a renewal certificate 119 ...........................................................22 120 4.6.6. Publication of the renewal certificate by the CA....22 121 4.6.7. Notification of certificate issuance by the CA to other 122 entities...................................................22 123 4.7. Certificate re-key.......................................22 124 4.7.1. Circumstance for certificate re-key.................22 125 4.7.2. Who may request certification of a new public key...23 126 4.7.3. Processing certificate re-keying requests...........23 127 4.7.4. Notification of new certificate issuance to subscriber23 128 4.7.5. Conduct constituting acceptance of a re-keyed 129 certificate................................................23 130 4.7.6. Publication of the re-keyed certificate by the CA...24 131 4.7.7. Notification of certificate issuance by the CA to other 132 entities...................................................24 133 4.8. Certificate modification.................................24 134 4.8.1. Circumstance for certificate modification...........24 135 4.8.2. Who may request certificate modification............24 136 4.8.3. Processing certificate modification requests........24 137 4.8.4. Notification of modified certificate issuance to 138 subscriber.................................................25 139 4.8.5. Conduct constituting acceptance of modified certificate 140 ...........................................................25 141 4.8.6. Publication of the modified certificate by the CA...25 142 4.8.7. Notification of certificate issuance by the CA to other 143 entities...................................................25 144 4.9. Certificate revocation and suspension....................25 145 4.9.1. Circumstances for revocation........................25 146 4.9.2. Who can request revocation..........................25 147 4.9.3. Procedure for revocation request....................26 148 4.9.4. Revocation request grace period.....................26 149 4.9.5. Time within which CA must process the revocation request 150 ...........................................................26 151 4.9.6. Revocation checking requirement for relying parties.26 152 4.9.7. CRL issuance frequency..............................26 153 4.9.8. Maximum latency for CRLs............................26 154 4.10. Certificate status services.............................26 155 5. Facility, Management, and Operational Controls................27 156 5.1. Physical controls........................................27 157 5.1.1. Site location and construction......................27 158 5.1.2. Physical access.....................................27 159 5.1.3. Power and air conditioning..........................27 160 5.1.4. Water exposures.....................................27 161 5.1.5. Fire prevention and protection......................27 162 5.1.6. Media storage.......................................27 163 5.1.7. Waste disposal......................................27 164 5.1.8. Off-site backup.....................................27 165 5.2. Procedural controls......................................27 166 5.2.1. Trusted roles.......................................27 167 5.2.2. Number of persons required per task.................27 168 5.2.3. Identification and authentication for each role.....27 169 5.2.4. Roles requiring separation of duties................27 170 5.3. Personnel controls.......................................27 171 5.3.1. Qualifications, experience, and clearance requirements28 172 5.3.2. Background check procedures.........................28 173 5.3.3. Training requirements...............................28 174 5.3.4. Retraining frequency and requirements...............28 175 5.3.5. Job rotation frequency and sequence.................28 176 5.3.6. Sanctions for unauthorized actions..................28 177 5.3.7. Independent contractor requirements.................28 178 5.3.8. Documentation supplied to personnel.................28 179 5.4. Audit logging procedures.................................28 180 5.4.1. Types of events recorded............................28 181 5.4.2. Frequency of processing log.........................28 182 5.4.3. Retention period for audit log......................29 183 5.4.4. Protection of audit log.............................29 184 5.4.5. Audit log backup procedures.........................29 185 5.4.6. Audit collection system (internal vs. external) 186 [OMITTED]..................................................29 187 5.4.7. Notification to event-causing subject [OMITTED].....29 188 5.4.8. Vulnerability assessments...........................29 189 5.5. Records archival [OMITTED]...............................29 190 5.6. Key changeover...........................................29 191 5.7. Compromise and disaster recovery [OMITTED]...............29 192 5.8. CA or RA termination.....................................29 193 6. Technical Security Controls...................................30 194 6.1. Key pair generation and installation.....................30 195 6.1.1. Key pair generation.................................30 196 6.1.2. Private key delivery to subscriber..................30 197 6.1.3. Public key delivery to certificate issuer...........30 198 6.1.4. CA public key delivery to relying parties...........30 199 6.1.5. Key sizes...........................................31 200 6.1.6. Public key parameters generation and quality checking31 201 6.1.7. Key usage purposes (as per X.509 v3 key usage field)31 202 6.2. Private Key Protection and Cryptographic Module Engineering 203 Controls......................................................31 204 6.2.1. Cryptographic module standards and controls.........31 205 6.2.2. Private key (n out of m) multi-person control.......31 206 6.2.3. Private key escrow..................................31 207 6.2.4. Private key backup..................................32 208 6.2.5. Private key archival................................32 209 6.2.6. Private key transfer into or from a cryptographic module 210 ...........................................................32 211 6.2.7. Private key storage on cryptographic module.........32 212 6.2.8. Method of activating private key....................32 213 6.2.9. Method of deactivating private key..................32 214 6.2.10. Method of destroying private key...................32 215 6.2.11. Cryptographic Module Rating........................33 216 6.3. Other aspects of key pair management.....................33 217 6.3.1. Public key archival.................................33 218 6.3.2. Certificate operational periods and key pair usage 219 periods....................................................33 220 6.4. Activation data..........................................33 221 6.4.1. Activation data generation and installation.........33 222 6.4.2. Activation data protection..........................33 223 6.4.3. Other aspects of activation data....................33 224 6.5. Computer security controls...............................33 225 6.5.1. Specific computer security technical requirement....33 226 6.6. Life cycle technical controls............................34 227 6.6.1. System development controls.........................34 228 6.6.2. Security management controls........................34 229 6.6.3. Life cycle security controls........................34 230 6.7. Network security controls................................34 231 6.8. Time-stamping............................................34 232 7. Certificate and CRL Profiles..................................35 233 8. Compliance Audit and Other Assessments........................36 234 8.1. Frequency or circumstances of assessment.................36 235 8.2. Identity/qualifications of assessor......................36 236 8.3. Assessor's relationship to assessed entity...............36 237 8.4. Topics covered by assessment.............................36 238 8.5. Actions taken as a result of deficiency..................36 239 8.6. Communication of results.................................36 240 9. Other Business And Legal Matters..............................37 241 9.1. Fees.....................................................38 242 9.1.1. Certificate issuance or renewal fees................38 243 9.1.2. Fees for other services (if applicable).............38 244 9.1.3. Refund policy.......................................38 245 9.2. Financial responsibility.................................38 246 9.2.1. Insurance coverage..................................38 247 9.2.2. Other assets........................................38 248 9.2.3. Insurance or warranty coverage for end-entities.....38 249 9.3. Confidentiality of business information..................38 250 9.3.1. Scope of confidential information...................38 251 9.3.2. Information not within the scope of confidential 252 information................................................38 253 9.3.3. Responsibility to protect confidential information..38 254 9.4. Privacy of personal information..........................38 255 9.4.1. Privacy plan........................................38 256 9.4.2. Information treated as private......................38 257 9.4.3. Information not deemed private......................38 258 9.4.4. Responsibility to protect private information.......38 259 9.4.5. Notice and consent to use private information.......38 260 9.4.6. Disclosure pursuant to judicial or administrative 261 process....................................................38 262 9.4.7. Other information disclosure circumstances..........38 263 9.5. Intellectual property rights (if applicable).............38 264 9.6. Representations and warranties...........................38 265 9.6.1. CA representations and warranties...................38 266 9.6.2. Subscriber representations and warranties...........39 267 9.6.3. Relying party representations and warranties........39 268 9.7. Disclaimers of warranties................................39 269 9.8. Limitations of liability.................................39 270 9.9. Indemnities..............................................39 271 9.10. Term and termination....................................39 272 9.10.1. Term...............................................39 273 9.10.2. Termination........................................39 274 9.10.3. Effect of termination and survival.................39 275 9.11. Individual notices and communications with participants.39 276 9.12. Amendments..............................................39 277 9.12.1. Procedure for amendment............................39 278 9.12.2. Notification mechanism and period..................39 279 9.13. Dispute resolution provisions...........................39 280 9.14. Governing law...........................................39 281 9.15. Compliance with applicable law..........................39 282 9.16. Miscellaneous provisions................................39 283 9.16.1. Entire agreement...................................39 284 9.16.2. Assignment.........................................39 285 9.16.3. Severability.......................................39 286 9.16.4. Enforcement (attorneys' fees and waiver of rights).39 287 9.16.5. Force Majeure......................................39 288 10. Security Considerations......................................39 289 11. IANA Considerations..........................................40 290 12. Acknowledgments..............................................40 291 13. References...................................................41 292 13.1. Normative References....................................41 293 13.2. Informative References..................................41 294 Author's Addresses...............................................42 295 Pre-5378 Material Disclaimer.....................................42 296 Copyright Statement..............................................43 298 Preface 300 This document contains a template to be used for creating a 301 Certification Practice Statement (CPS) for an Internet Service 302 Provider that is part of the Resource Public Key Infrastructure 303 (RPKI). The user of this document should 305 1. substitute a title page for page 1 saying, e.g., '' 306 Certification Practice Statement for the Resource Public Key 307 Infrastructure (RPKI)'' with date, author, etc. 309 2. leave the table of contents 311 3. delete this Preface 313 4. fill in the information indicated below by 316 5. delete sections 10, 11, 12, 13.1, Acknowledgments, Author's 317 Addresses, Intellectual Property Statement, Disclaimer of 318 Validity, Copyright Statement, Acknowledgments; leaving a 319 reference section with just the references in 13.2 321 6. update the table of contents to reflect the changes required by 322 steps 4 and 5 above . 324 Note: This CPS is based on the template specified in RFC 3647. A 325 number of sections contained in the template were omitted from this 326 CPS because they did not apply to this PKI. However, we have retained 327 the section numbering scheme employed in the RFC to facilitate 328 comparison with the section numbering scheme employed in that RFC. 329 [There are 4 sub-sections that I haven't removed yet due to Word 330 problems.) 332 1. Introduction 334 This document is the Certification Practice Statement (CPS) of . It describes the practices employed by the 336 Certification Authority (CA) in the Resource Public Key 337 Infrastructure (RPKI). These practices are defined in accordance 338 with the requirements of the Certificate Policy (CP, [RFCxxxx]) of 339 this PKI. 341 The RPKI is designed to support validation of claims by current 342 holders of Internet Number Resources (INRs, see definition in 1.7) in 343 accordance with the records of the organizations that act as CAs in 344 this PKI. The ability to verify such claims is essential to ensuring 345 the unique, unambiguous distribution of these resources 347 This PKI parallels the existing INR distribution hierarchy. These 348 resources are distributed by the Internet Assigned Numbers Authority 349 (IANA) to the Regional Internet Registries. In some regions, National 350 Internet Registries (NIRs) form a tier of the hierarchy below the 351 RIRs for internet number resource (INR) distribution. ISPs and 352 network subscribers form additional tiers below registries. 354 1.1. Overview 356 This CPS describes: 358 . Participants 360 . Publication of the certificates and CRLs 362 . How certificates are issued, managed, and revoked 364 . Facility management (physical security, personnel, audit, etc.) 366 . Key management 368 . Audit procedures 370 . Business and legal issues 371 This PKI encompasses several types of certificates (see IETF document 372 draft-ietf-sidr-arch-xx [ARCH] for more details): 374 . CA certificates for each organization distributing INRs and for 375 each subscriber 377 . End entity (EE) certificates for organizations to use to validate 378 digital signatures on RPKI-signed objects (see definition in 1.7). 380 . In the future, the PKI also may include end entity certificates in 381 support of access control for the repository system as described in 382 2.4. 384 1.2. Document name and identification 386 The name of this document is '''s Certification Practice 387 Statement for the Resource Public Key Infrastructure (RPKI)''. 389 1.3. PKI participants 391 Note: In a PKI, the term ''subscriber'' refers to an individual or 392 organization that is a Subject of a certificate issued by a CA. The 393 term is used in this fashion throughout this document, without 394 qualification, and should not be confused with the networking use of 395 the term to refer to an individual or organization that receives 396 service from an ISP. In such cases the term ''network subscriber'' will 397 be used. Also note that, for brevity, this document always refers to 398 PKI participants as organizations or entities, even though some of 399 them are individuals. 401 1.3.1. Certification authorities 403 portion of the RPKI. It provides a secure revocation 407 and recovery capability in case the production CA is compromised or 408 becomes unavailable. Thus the offline CA issues certificates only to 409 instances of the production CA; and the CRLs it issues are used to 410 revoke only certificates issued to the production CA. The production 411 CA is used to issue RPKI certificates to members, to 412 whom INRs have been distributed.> 414 1.3.2. Registration authorities 416 426 1.3.3. Subscribers 428 The primary types of organizations that receive distributions of INRs 429 from this CA and thus are subscribers in the PKI sense are network 430 subscribers. 432 1.3.4. Relying parties 434 Entities or individuals that act in reliance on certificates or RPKI- 435 signed objects issued under this PKI are relying parties. Relying 436 parties may or may not be subscribers within this PKI. (See section 437 1.7 for the definition of an RPKI-signed object.) 439 1.3.5. Other participants 441 operates a repository that holds certificates, 442 CRLs, and other RPKI-signed objects, then indicate this here.> 444 1.4. Certificate usage 446 1.4.1. Appropriate certificate uses 448 The certificates issued under this hierarchy are for authorization in 449 support of validation of claims of current holdings of INRs. 451 Additional uses of the certificates, consistent with the basic goal 452 cited above, are also permitted under the RPKI certificate policy. 454 Some of the certificates that may be issued under this PKI could be 455 used to support operation of this infrastructure, e.g., access 456 control for the repository system as described in 2.4. Such uses also 457 are permitted under the RPKI certificate policy. 459 1.4.2. Prohibited certificate uses 461 Any uses other than those described in Section 1.4.1 are prohibited. 463 1.5. Policy administration 465 1.5.1. Organization administering the document 467 This CPS is administered by 469 1.5.2. Contact person 471 473 1.5.3. Person determining CPS suitability for the policy 475 Not applicable. Each organization issuing a certificate in this PKI 476 is attesting to the distribution of INRs to the holder of the private 477 key corresponding to the public key in the certificate. The issuing 478 organizations are the same organizations as the ones that perform the 479 distribution hence they are authoritative with respect to the 480 accuracy of this binding. 482 1.5.4. CPS approval procedures 484 Not applicable. Each organization issuing a certificate in this PKI 485 is attesting to the distribution of INRs to the holder of the private 486 key corresponding to the public key in the certificate. The issuing 487 organizations are the same organizations as the ones that perform the 488 distribution hence they are authoritative with respect to the 489 accuracy of this binding. 491 1.6. Definitions and acronyms 493 BPKI - Business PKI: A BPKI is an optional additional PKI used to 494 identify members to whom RPKI certificates can 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. 500 CPS - Certification Practice Statement. A CPS is a document that 501 specifies the practices that a Certification Authority employs 502 in issuing certificates. 504 Distribution of INRs - - A process of distribution of the INRs along the 505 respective number hierarchy. IANA distributes blocks of IP 506 addresses and Autonomous System Numbers to the five Regional 507 Internet Registries (RIRs). RIRs distribute smaller address 508 blocks and Autonomous System Numbers to organizations within 509 their service regions, who in turn distribute IP addresses to 510 their customers. 512 IANA - Internet Assigned Numbers Authority. IANA is responsible for 513 global coordination of the Internet Protocol addressing systems 514 and Autonomous System (AS) numbers used for routing internet 515 traffic. IANA distributes INRs to Regional Internet Registries 516 (RIRs). 518 INRs - Internet Number Resources. INRs are number values for three 519 protocol parameter sets, namely: 520 . IP Version 4 addresses, 522 . IP version 6 addresses, and 524 . Identifiers used in Internet inter-domain routing, currently 525 Border Gateway Protocol-4 Autonomous System numbers. 527 ISP - - Internet Service Provider. An ISP is an organization managing 528 and selling Internet services to other organizations. 530 NIR - - National Internet Registry. An NIR is an organization that 531 manages the distribution of INRs for a portion of the 532 geopolitical area covered by a Regional Registry. NIRs form an 533 optional second tier in the tree scheme used to manage INR 534 distribution. 536 RIR - Regional Internet Registry. An RIR is an organization that 537 manages the distribution of INRs for a geopolitical area. 539 RPKI-signed object - - An RPKI-signed object is a digitally signed data 540 object (other than a certificate or CRL) declared to be such by 541 a standards track RFC, and that can be validated using 542 certificates issued under this PKI. The content and format of 543 these data constructs depend on the context in which validation 544 of claims of current holdings of INRs takes place. Examples of 545 these objects are repository manifests and CRLs. 547 2. Publication And Repository Responsibilities 549 2.1. Repositories 551 As per the CP, certificates, CRLs and RPKI-signed objects MUST be 552 made available for downloading by all relying parties, to enable them 553 to validate this data. 555 RPKI CA will publish 557 certificates, CRLs, and RPKI-signed objects via a repository that is 558 accessible via RSYNC at rpki..net.''> 560 2.2. Publication of certification information 562 MUST publish certificates, CRLs and RPKI-signed objects 563 issued by it to a repository that operates as part of a world-wide 564 distributed system of repositories. will also publish 565 to this repository system any RPKI-signed objects that it creates. 567 2.3. Time or Frequency of Publication 569 578 As per the CP, the following standard exists for publication times 579 and frequency: 581 The CA MUST publish its CRL prior to the 582 nextScheduledUpdate value in the scheduled CRL previously issued by 583 the CA. 585 2.4. Access controls on repositories 587 Access to the repository system, for modification of entries, must be 588 controlled to prevent denial of service attacks. All data 589 (certificates, CRLs and RPKI-signed objects) published to a 590 repository are digitally signed RPKI items that 591 issues MUST be published to the repository that it runs by means not 592 accessible to the outside world. offers 593 repository services to its subscribers, then 596 3. Identification And Authentication 598 3.1. Naming 600 3.1.1. Types of names 602 The Subject of each certificate issued by this ISP is identified by 603 an X.500 Distinguished Name (DN). The distinguished name will 604 consist of a single Common Name (CN) attribute with a value 605 generated by . Optionally, the serialNumber attribute 606 may be included along with the common name (to form a terminal 607 relative distinguished name set), to distinguish among successive 608 instances of certificates associated with the same entity. 610 3.1.2. Need for names to be meaningful 612 The Subject name in each subscriber certificate will be unique 613 relative to all certificates issued by . However, there 614 is no guarantee that the subject name will be globally unique in this 615 PKI. Also, the name of the subscriber need not to be ''meaningful'' in 616 the conventional, human-readable sense. The certificates issued 617 under this PKI are used for authorization in support of applications 618 that make use of attestations of Internet resource holding, not for 619 identification 621 3.1.3. Anonymity or pseudonymity of subscribers 623 Although Subject names in certificates issued by this ISP need not be 624 meaningful, and may appear ''random,'' anonymity is not a function of 625 this PKI, and thus no explicit support for this feature is provided. 627 3.1.4. Rules for interpreting various name forms 629 None 631 3.1.5. Uniqueness of names 633 certifies Subject names that are unique among the 634 certificates that it issues. Although it is desirable that these 635 Subject names be unique throughout the PKI, to facilitate certificate 636 path discovery, such uniqueness is neither mandated nor enforced 637 through technical means. 639 3.1.6. Recognition, authentication, and role of trademarks 641 Because the Subject names are not intended to be meaningful, there is 642 no provision to either recognize or authenticate trademarks, service 643 marks, etc. 645 3.2. Initial identity validation 647 3.2.1. Method to prove possession of private key 649 issuing the certificate. One possible approach makes use of 653 the PKCS #10 format, as profiled in [RFCyyyy]. This request format 654 requires that the PKCS #10 request be signed using the (RSA) private 655 key corresponding to the public key in the certificate request. This 656 mechanism provides proof of possession by the requester.> 658 3.2.2. Authentication of organization identity 660 Certificates issued under this PKI do not attest to the 661 organizational identity of subscribers, with the exception of 662 registries. However, certificates are issued to subscribers in a 663 fashion that preserves the accuracy of distributions of INRs in this 664 records. 666 subscriber database that 672 maintains the resource distribution records. The certificate request 673 could be matched against the database record for the subscriber in 674 question, and an RPKI certificate would be issued only if the 675 resources requested were a subset of those held by the subscriber. 676 The specific procedures employed for this purpose should be 677 commensurate with those you already employ as an ISP in the 678 maintenance of INR distribution.> 680 3.2.3. Authentication of individual identity 682 Certificates issued under this PKI do not attest to the individual 683 identity of a subscriber. However, maintains contact 684 information for each subscriber in support of certificate renewal, 685 rekey, or revocation. 687 BPKI (see Section 3.2.6) issues certificates that MUST be used 692 to identify individuals who represent subscribers.'' The 693 procedures should be commensurate with those you already employ in 694 authenticating individuals as representatives for INR holders. Note 695 that this authentication is solely for use by you in dealing with the 696 organizations to which you distribute (or sub-distribute) INRs, and 697 thus must not be relied upon outside of this CA-subscriber 698 relationship.> 700 3.2.4. Non-verified subscriber information 702 No non-verified subscriber data is included in certificates issued 703 under this certificate policy except for SIA/AIA extensions. 705 3.2.5. Validation of authority 707 716 3.2.6. Criteria for interoperation 718 The RPKI is neither intended nor designed to interoperate with any 719 other PKI. 724 3.3. Identification and authentication for re-key requests 726 3.3.1. Identification and authentication for routine re-key 728 736 3.3.2. Identification and authentication for re-key after 737 revocation 739 749 3.4. Identification and authentication for revocation request 751 761 Note that if a subscriber requests a new INR distribution, an 762 existing RPKI certificate issued to the subscriber is NOT revoked, so 763 long as the set of INRs distributed to the subscriber did not 764 ''shrink,'' i.e., the new INRs are a superset of the old INR set. 765 However, if a new INR distribution results in ''shrinkage'' of the set 766 of INRs distributed to a subscriber, this triggers an implicit 767 revocation of the old RPKI certificate(s) associated with that 768 subscriber. 770 4. Certificate Life-Cycle Operational Requirements 772 4.1. Certificate Application 774 4.1.1. Who can submit a certificate application 776 Any subscriber who holds INRs distributed by this ISP may submit a 777 certificate application to this CA. 779 4.1.2. Enrollment process and responsibilities 781 789 4.2. Certificate application processing 791 798 4.2.1. Performing identification and authentication functions 800 806 4.2.2. Approval or rejection of certificate applications 808 817 4.2.3. Time to process certificate applications 819 822 4.3. Certificate issuance 824 4.3.1. CA actions during certificate issuance 826 829 4.3.2. Notification to subscriber by the CA of issuance of 830 certificate 832 MUST notify the subscriber when the certificate is 833 published. 836 4.3.3. Notification of certificate issuance by the CA to other 837 entities 839 842 4.4. Certificate acceptance 844 4.4.1. Conduct constituting certificate acceptance 846 When a certificate is issued, the CA MUST publish it to the 847 repository and notify the subscriber. This will be done without 848 subscriber review and acceptance. 850 4.4.2. Publication of the certificate by the CA 852 Certificates MUST be published in the RPKI distributed repository 853 system once issued following the conduct described in 4.4.1. This 854 will be done within . 859 4.5. Key pair and certificate usage 861 A summary of the use model for the RPKI is provided below. 863 4.5.1. Subscriber private key and certificate usage 865 The certificates issued by to subscribers are CA 866 certificates. The private key associated with each of these 867 certificates is used to sign subordinate (CA or EE) certificates and 868 CRLs. Subscribers who are ISPs will issue CA certificates to any 869 organizations to which they in turn distribute INRs, one or more end 870 entity (EE) certificates for use in verifying signatures on RPKI- 871 signed objects signed by the suscriber, and end entity certificates 872 to operators in support of repository access control. Non-ISP INR 873 holders will issue just the latter two kinds of certificates since 874 they will not be distributing INRs to other organizations. 876 4.5.2. Relying party public key and certificate usage 878 The primary relying parties in this PKI are organizations who will 879 use EE certificates to verify RPKI-signed objects. Repositories will 880 use operator certificates to verify the authorization of entities to 881 engage in repository maintenance activities, and thus repositories 882 represent a secondary type of relying party. 884 4.6. Certificate renewal 886 4.6.1. Circumstance for certificate renewal 888 As per the CP, a certificate will be processed for renewal based on 889 its expiration date or a renewal request from the certificate 890 Subject. If initiates the renewal process based on the 891 certificate expiration date, then will notify the 892 subscriber The validity 895 interval of the new (renewed) certificate will overlap that of the 896 previous certificate by , to ensure uninterrupted coverage. 899 Certificate renewal will incorporate the same public key as the 900 previous certificate, unless the private key has been reported as 901 compromised. If a new key pair is being used, the stipulations of 902 Section 4.7 will apply. 904 4.6.2. Who may request renewal 906 The subscriber or may initiate the renewal process. 907 918 4.6.3. Processing certificate renewal requests 920 924 4.6.4. Notification of new certificate issuance to subscriber 926 MUST notify the subscriber when the certificate is 927 published 931 4.6.5. Conduct constituting acceptance of a renewal certificate 933 When a renewal certificate is issued, the CA MUST 934 publish it to the repository and notify the subscriber. This will be 935 done without subscriber review and acceptance. 937 4.6.6. Publication of the renewal certificate by the CA 939 942 4.6.7. Notification of certificate issuance by the CA to other 943 entities 945 948 4.7. Certificate re-key 950 4.7.1. Circumstance for certificate re-key 952 As per the CP, re-key of a certificate will be performed only when 953 required, based on: 955 1. knowledge or suspicion of compromise or loss of the associated 956 private key, or 958 2. the expiration of the cryptographic lifetime of the associated key 959 pair 961 If a certificate is revoked to replace the RFC 3779 extensions, the 962 replacement certificate will incorporate the same public key, not a 963 new key, unless the subscriber requests a re-key at the same time. 965 If the re-key is based on a suspected compromise, then the previous 966 certificate will be revoked. 968 Section 5.6 of the Certificate Policy notes that when a CA signs a 969 certificate, the signing key should have a validity period that 970 exceeds the validity period of the certificate. This places 971 additional constraints on when a CA should request a re-key. 973 4.7.2. Who may request certification of a new public key 975 Only the subscriber may request a re-key. In addition, 976 may initiate a re-key based on a verified compromise report. BPKI. 979 Describe how a compromise report received from other than a 980 subscriber is verified.> 982 4.7.3. Processing certificate re-keying requests 984 988 4.7.4. Notification of new certificate issuance to subscriber 990 995 4.7.5. Conduct constituting acceptance of a re-keyed certificate 997 When a re-keyed certificate is issued, the CA will publish it in the 998 repository and notify the subscriber. This will be done without 999 subscriber review and acceptance. 1001 4.7.6. Publication of the re-keyed certificate by the CA 1003 1007 4.7.7. Notification of certificate issuance by the CA to other 1008 entities 1010 1013 4.8. Certificate modification 1015 4.8.1. Circumstance for certificate modification 1017 As per the CP, modification of a certificate occurs to implement 1018 changes to the RFC 3779 extension values in a certificate. A 1019 subscriber can request a certificate modification when this 1020 information in a currently valid certificate has changed, as a result 1021 of changes in the INR holdings of the subscriber. 1023 If a subscriber is to receive a distribution of INRs in addition to a 1024 current distribution, and if the subscriber does not request that a 1025 new certificate be issued containing only these additional INRs, then 1026 this is accomplished through a certificate modification. When a 1027 certificate modification is approved, a new certificate is issued. 1028 The new certificate will contain the same public key and the same 1029 expiration date as the original certificate, but with the incidental 1030 information corrected and/or the INR distribution expanded. When 1031 previously distributed INRs are to be removed from a certificate, 1032 then the old certificate MUST be revoked and a new certificate 1033 (reflecting the new distribution) issued. 1035 4.8.2. Who may request certificate modification 1037 The subscriber or may initiate the certificate 1038 modification process. 1042 4.8.3. Processing certificate modification requests 1044 1048 4.8.4. Notification of modified certificate issuance to 1049 subscriber 1051 1056 4.8.5. Conduct constituting acceptance of modified certificate 1058 When a modified certificate is issued, the CA will publish it to the 1059 repository and notify the subscriber. This will be done without 1060 subscriber review and acceptance. 1062 4.8.6. Publication of the modified certificate by the CA 1064 1068 4.8.7. Notification of certificate issuance by the CA to other 1069 entities 1071 or the subject may choose to end the 1080 relationship expressed in the certificate, thus creating cause to 1081 revoke the certificate. If one or more of the INRs bound to the 1082 public key in the certificate are no longer associated with the 1083 subject, that too constitutes a basis for revocation. A certificate 1084 also may be revoked due to loss or compromise of the private key 1085 corresponding to the public key in the certificate. Finally, a 1086 certificate may be revoked in order to invalidate data signed by the 1087 private key associated with that certificate. 1089 4.9.2. Who can request revocation 1091 The subscriber or may request a revocation. 1095 4.9.3. Procedure for revocation request 1097 .> 1105 4.9.4. Revocation request grace period 1107 A subscriber should request revocation as soon as possible after the 1108 need for revocation has been identified. 1110 4.9.5. Time within which CA must process the revocation request 1112 1115 4.9.6. Revocation checking requirement for relying parties 1117 As per the CP, a relying party is responsible for acquiring and 1118 checking the most recent, scheduled CRL from the issuer of the 1119 certificate, whenever the relying party validates a certificate. 1121 4.9.7. CRL issuance frequency 1123 < 1124 Each CRL will carry a nextScheduledUpdate value and a new CRL will be 1125 published at or before that time. will set the 1126 nextScheduledUpdate value when it issues a CRL, to signal when the 1127 next scheduled CRL will be issued. 1129 4.9.8. Maximum latency for CRLs 1131 A CRL will be published to the repository system within after generation. 1134 4.10. Certificate status services 1136 does not support OCSP or SCVP. issues 1137 CRLs. 1139 5. Facility, Management, and Operational Controls 1141 5.1. Physical controls 1143 1147 5.1.1. Site location and construction 1149 5.1.2. Physical access 1151 5.1.3. Power and air conditioning 1153 5.1.4. Water exposures 1155 5.1.5. Fire prevention and protection 1157 5.1.6. Media storage 1159 5.1.7. Waste disposal 1161 5.1.8. Off-site backup 1163 5.2. Procedural controls 1165 1169 5.2.1. Trusted roles 1171 5.2.2. Number of persons required per task 1173 5.2.3. Identification and authentication for each role 1175 5.2.4. Roles requiring separation of duties 1177 5.3. Personnel controls 1179 1183 5.3.1. Qualifications, experience, and clearance requirements 1185 5.3.2. Background check procedures 1187 5.3.3. Training requirements 1189 5.3.4. Retraining frequency and requirements 1191 5.3.5. Job rotation frequency and sequence 1193 5.3.6. Sanctions for unauthorized actions 1195 5.3.7. Independent contractor requirements 1197 5.3.8. Documentation supplied to personnel 1199 5.4. Audit logging procedures 1201 1204 5.4.1. Types of events recorded 1206 Audit records will be generated for the basic operations of the 1207 certification authority computing equipment. Audit records will 1208 include the date, time, responsible user or process, and summary 1209 content data relating to the event. Auditable events include: 1211 . Access to CA computing equipment (e.g., logon, logout) 1213 . Messages received requesting CA actions (e.g., certificate 1214 requests, certificate revocation requests, compromise 1215 notifications) 1217 . Certificate creation, modification, revocation, or renewal actions 1219 . Posting of any material to a repository 1221 . Any attempts to change or delete audit data 1222 1224 5.4.2. Frequency of processing log 1226 1227 5.4.3. Retention period for audit log 1229 1231 5.4.4. Protection of audit log 1233 1235 5.4.5. Audit log backup procedures 1237 1239 5.4.6. Audit collection system (internal vs. external) [OMITTED] 1241 5.4.7. Notification to event-causing subject [OMITTED] 1243 5.4.8. Vulnerability assessments 1245 1250 5.5. Records archival [OMITTED] 1252 5.6. Key changeover 1254 The CA certificate will contain a validity period that 1255 is at least as long as that of any certificate being issued under 1256 that certificate. When CA wishes to change keys, will create a new signature key pair, and acquire and publish 1258 a new certificate containing the public key of the pair, 1260 in advance of the scheduled change of the current signature key pair. 1262 5.7. Compromise and disaster recovery [OMITTED] 1264 5.8. CA or RA termination 1266 1269 6. Technical Security Controls 1271 This section describes the security controls used by . 1273 6.1. Key pair generation and installation 1275 6.1.1. Key pair generation 1277 1289 6.1.2. Private key delivery to subscriber 1291 1296 6.1.3. Public key delivery to certificate issuer 1298 RPKI CA. These procedures should 1300 ensure that the public key has not been altered during transit and 1301 that the subscriber possesses the private key corresponding to the 1302 transferred public key. > 1304 6.1.4. CA public key delivery to relying parties 1306 CA public keys for all entities (other than trust anchors) are 1307 contained in certificates issued by other CAs and MUST be published 1308 to the RPKI repository system. Relying parties MUST download these 1309 certificates from this system. Public key values and associated data 1310 for (putative) trust anchors MUST be distributed out of band and 1311 accepted by relying parties on the basis of locally-defined criteria, 1312 e.g., embedded in path validation software that will be made 1313 available to the Internet community. 1315 6.1.5. Key sizes 1317 The key sizes used in this PKI are as specified in RFC ZZZZ 1318 [RFCzzzz]. 1320 6.1.6. Public key parameters generation and quality checking 1322 The public key algorithms and parameters used in this PKI are as 1323 specified in RFC ZZZZ [RFCzzzz]. 1326 is not responsible for performing such checks for 1330 subscribers OR describe the procedures used by the CA for checking 1331 the quality of these subscriber key pairs.> 1333 6.1.7. Key usage purposes (as per X.509 v3 key usage field) 1335 The Key usage extension bit values will be consistent with RFC 5280. 1336 For 's CA certificates, the keyCertSign and cRLSign bits 1337 will be set TRUE. All other bits (including digitalSignature) will be 1338 set FALSE, and the extension will be marked critical. 1343 6.2. Private Key Protection and Cryptographic Module Engineering 1344 Controls 1346 6.2.1. Cryptographic module standards and controls 1348 The CA employs a cryptographic module evaluated under 1349 FIPS 140-2/3, at level 2 or 3 [FIPS]. 1351 6.2.2. Private key (n out of m) multi-person control 1353 out of multi-person 1356 control.''> 1358 6.2.3. Private key escrow 1360 No private key escrow procedures are required for this PKI. 1362 6.2.4. Private key backup 1364 1369 6.2.5. Private key archival 1371 See sections 6.2.3 and 6.2.4 1373 6.2.6. Private key transfer into or from a cryptographic module 1375 The private key for 's production CA MUST be 1377 generated by the cryptographic module specified in 6.2.1. The 1378 private keys will never leave the module except in encrypted form for 1379 backup and/or transfer to a new module. 1380 6.2.7. Private key storage on cryptographic module 1382 The private key for 's production CA MUST be 1384 stored in the cryptographic module and will be protected from 1385 unauthorized use in accordance with the FIPS 140-2/3 requirements 1386 applicable to the module. (See [FIPS]) 1388 6.2.8. Method of activating private key 1390 1393 6.2.9. Method of deactivating private key 1395 The cryptographic module, when activated, will not be left 1396 unattended. After use, it will be deactivated by The module will 1398 be stored securely when not in use. 1400 6.2.10. Method of destroying private key 1402 1404 6.2.11. Cryptographic Module Rating 1406 The cryptographic module will be certified FIPS 140-2/3, at level 2 1407 or 3 [FIPS]. 1409 6.3. Other aspects of key pair management 1411 6.3.1. Public key archival 1413 Because this PKI does not support non-repudiation, there is no need 1414 to archive public keys. 1416 6.3.2. Certificate operational periods and key pair usage 1417 periods 1419 The CA's key pair will have a validity interval of 1420 1424 6.4. Activation data 1426 6.4.1. Activation data generation and installation 1428 1430 6.4.2. Activation data protection 1432 Activation data for the CA private key will be protected by . 1435 6.4.3. Other aspects of activation data 1437 1440 6.5. Computer security controls 1442 6.5.1. Specific computer security technical requirement 1444 1449 6.6. Life cycle technical controls 1451 6.6.1. System development controls 1453 1457 6.6.2. Security management controls 1459 1464 6.6.3. Life cycle security controls 1466 1470 6.7. Network security controls 1472 1477 6.8. Time-stamping 1479 The RPKI does not make use of time stamping. 1481 7. Certificate and CRL Profiles 1483 Please refer to the Certificate and CRL Profile [RFCyyyy]. 1485 8. Compliance Audit and Other Assessments 1487 1491 8.1. Frequency or circumstances of assessment 1493 8.2. Identity/qualifications of assessor 1495 8.3. Assessor's relationship to assessed entity 1497 8.4. Topics covered by assessment 1499 8.5. Actions taken as a result of deficiency 1501 8.6. Communication of results 1502 9. Other Business And Legal Matters 1504 1511 9.1. Fees 1513 9.1.1. Certificate issuance or renewal fees 1515 9.1.2. Fees for other services (if applicable) 1517 9.1.3. Refund policy 1519 9.2. Financial responsibility 1521 9.2.1. Insurance coverage 1523 9.2.2. Other assets 1525 9.2.3. Insurance or warranty coverage for end-entities 1527 9.3. Confidentiality of business information 1529 9.3.1. Scope of confidential information 1531 9.3.2. Information not within the scope of confidential 1532 information 1534 9.3.3. Responsibility to protect confidential information 1536 9.4. Privacy of personal information 1538 9.4.1. Privacy plan 1540 9.4.2. Information treated as private 1542 9.4.3. Information not deemed private 1544 9.4.4. Responsibility to protect private information 1546 9.4.5. Notice and consent to use private information 1548 9.4.6. Disclosure pursuant to judicial or administrative process 1550 9.4.7. Other information disclosure circumstances 1552 9.5. Intellectual property rights (if applicable) 1554 9.6. Representations and warranties 1556 9.6.1. CA representations and warranties 1557 9.6.2. Subscriber representations and warranties 1559 9.6.3. Relying party representations and warranties 1561 9.7. Disclaimers of warranties 1563 9.8. Limitations of liability 1565 9.9. Indemnities 1567 9.10. Term and termination 1569 9.10.1. Term 1571 9.10.2. Termination 1573 9.10.3. Effect of termination and survival 1575 9.11. Individual notices and communications with participants 1577 9.12. Amendments 1579 9.12.1. Procedure for amendment 1581 9.12.2. Notification mechanism and period 1583 9.13. Dispute resolution provisions 1585 9.14. Governing law 1587 9.15. Compliance with applicable law 1589 9.16. Miscellaneous provisions 1591 9.16.1. Entire agreement 1593 9.16.2. Assignment 1595 9.16.3. Severability 1597 9.16.4. Enforcement (attorneys' fees and waiver of rights) 1599 9.16.5. Force Majeure 1601 10. Security Considerations 1602 The degree to which a relying party can trust the binding embodied in 1603 a certificate depends on several factors. These factors can include 1604 the practices followed by the certification authority (CA) in 1605 authenticating the subject; the CA's operating policy, procedures, 1606 and technical security controls, including the scope of the 1607 subscriber's responsibilities (for example, in protecting the private 1608 key), and the stated responsibilities and liability terms and 1609 conditions of the CA (for example, warranties, disclaimers of 1610 warranties, and limitations of liability). This document provides a 1611 framework to address the technical, procedural, personnel, and 1612 physical security aspects of Certification Authorities, Registration 1613 Authorities, repositories, subscribers, and relying party 1614 cryptographic modules, in order to ensure that the certificate 1615 generation, publication, renewal, re-key, usage, and revocation is 1616 done in a secure manner. Specifically, Section 3 Identification and 1617 Authentication (I&A); Section 4 Certificate Life-Cycle Operational 1618 Requirements; Section 5 Facility Management, and Operational 1619 Controls; Section 6 Technical Security Controls; Section 7 1620 Certificate and CRL Profiles; and Section 8 Compliance Audit and 1621 Other Assessments are oriented towards ensuring secure operation of 1622 the PKI entities such as CA, RA, repository, subscriber systems, and 1623 relying party systems. 1625 11. IANA Considerations 1627 None. 1629 12. Acknowledgments 1631 The authors would like to thank Matt Lepinski for his help with the 1632 formatting and Ron Watro for assistance with the editing of this 1633 document. 1635 13. References 1637 13.1. Normative References 1639 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1640 Requirement Levels", BCP 14, RFC 2119, March 1997. 1642 [RFC3280] Housley, R., Polk, W. Ford, W., Solo, D., "Internet X.509 1643 Public Key Infrastructure Certificate and Certificate 1644 Revocation List (CRL) Profile", BCP 14, RFC 2119, March 1645 1997. 1647 [RFCxxxx] Seo, K., Watro, R., Kong, D., and Kent, S., "Certificate 1648 Policy for the Resource PKI (RPKI)", work in progress. 1650 [RFCyyyy] Huston, G., Michaelson, G., and Loomans, R., ''A Profile for 1651 X.509 PKIX Resource Certificates'', work in progress. 1653 [RFCzzzz] Huston, G., ''A Profile for Algorithms and Key Sizes for use 1654 in the Resource Public Key Infrastructure,'' work in 1655 progress. 1657 13.2. Informative References 1659 [BGP4] Y. Rekhter, T. Li (editors), A Border Gateway Protocol 4 1660 (BGP-4). IETF RFC 1771, March 1995. 1662 [FIPS] Federal Information Processing Standards Publication 140-3 1663 (FIPS-140-3), "Security Requirements for Cryptographic 1664 Modules", Information Technology Laboratory, National 1665 Institute of Standards and Technology, work in progress. 1667 [RSA] Rivest, R., Shamir, A., and Adelman, L. M. 1978. A method 1668 for obtaining digital signatures and public-key 1669 cryptosystems. Commun. ACM 21, 2 (Feb.), 120-126. 1671 Author's Addresses 1673 Stephen Kent 1674 BBN Technologies 1675 10 Moulton Street 1676 Cambridge MA 02138 1677 USA 1679 Phone: +1 (617) 873-3988 1680 Email: skent@bbn.com 1682 Derrick Kong 1683 BBN Technologies 1684 10 Moulton Street 1685 Cambridge MA 02138 1686 USA 1688 Phone: +1 (617) 873-1951 1689 Email: dkong@bbn.com 1691 Karen Seo 1692 BBN Technologies 1693 10 Moulton Street 1694 Cambridge MA 02138 1695 USA 1697 Phone: +1 (617) 873-3152 1698 Email: kseo@bbn.com 1700 Pre-5378 Material Disclaimer 1702 This document may contain material from IETF Documents or IETF 1703 Contributions published or made publicly available before November 1704 10, 2008. The person(s) controlling the copyright in some of this 1705 material may not have granted the IETF Trust the right to allow 1706 modifications of such material outside the IETF Standards Process. 1707 Without obtaining an adequate license from the person(s) controlling 1708 the copyright in such materials, this document may not be modified 1709 outside the IETF Standards Process, and derivative works of it may 1710 not be created outside the IETF Standards Process, except to format 1711 it for publication as an RFC or to translate it into languages other 1712 than English. 1714 Copyright Statement 1716 Copyright (c) 2010 IETF Trust and the persons identified as the 1717 document authors. All rights reserved. 1719 This document is subject to BCP 78 and the IETF Trust's Legal 1720 Provisions Relating to IETF Documents 1721 (http://trustee.ietf.org/license-info) in effect on the date of 1722 publication of this document. Please review these documents 1723 carefully, as they describe your rights and restrictions with respect 1724 to this document. Code Components extracted from this document must 1725 include Simplified BSD License text as described in Section 4.e of 1726 the Trust Legal Provisions and are provided without warranty as 1727 described in the Simplified BSD License.