From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc7382.txt | 2131 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 2131 insertions(+)
 create mode 100644 doc/rfc/rfc7382.txt

(limited to 'doc/rfc/rfc7382.txt')

diff --git a/doc/rfc/rfc7382.txt b/doc/rfc/rfc7382.txt
new file mode 100644
index 0000000..520d7dc
--- /dev/null
+++ b/doc/rfc/rfc7382.txt
@@ -0,0 +1,2131 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           S. Kent
+Request for Comments: 7382                                       D. Kong
+BCP: 173                                                          K. Seo
+Category: Best Current Practice                         BBN Technologies
+ISSN: 2070-1721                                               April 2015
+
+
+         Template for a Certification Practice Statement (CPS)
+                      for the Resource PKI (RPKI)
+
+Abstract
+
+   This document contains a template to be used for creating a
+   Certification Practice Statement (CPS) for an organization that is
+   part of the Resource Public Key Infrastructure (RPKI), e.g., a
+   resource allocation registry or an ISP.
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   BCPs is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7382.
+
+Copyright Notice
+
+   Copyright (c) 2015 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                 [Page 1]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+Table of Contents
+
+   Preface ............................................................8
+   1. Introduction ....................................................9
+      1.1. Overview ..................................................10
+      1.2. Document Name and Identification ..........................10
+      1.3. PKI Participants ..........................................11
+           1.3.1. Certification Authorities ..........................11
+           1.3.2. Registration Authorities ...........................11
+           1.3.3. Subscribers ........................................11
+           1.3.4. Relying Parties ....................................11
+           1.3.5. Other Participants .................................12
+      1.4. Certificate Usage .........................................12
+           1.4.1. Appropriate Certificate Uses .......................12
+           1.4.2. Prohibited Certificate Uses ........................12
+      1.5. Policy Administration .....................................12
+           1.5.1. Organization Administering the Document ............12
+           1.5.2. Contact Person .....................................12
+           1.5.3. Person Determining CPS Suitability for the Policy ..12
+           1.5.4. CPS Approval Procedures ............................13
+      1.6. Definitions and Acronyms ..................................13
+   2. Publication and Repository Responsibilities ....................14
+      2.1. Repositories ..............................................14
+      2.2. Publication of Certification Information ..................14
+      2.3. Time or Frequency of Publication ..........................14
+      2.4. Access Controls on Repositories ...........................15
+   3. Identification and Authentication ..............................15
+      3.1. Naming ....................................................15
+           3.1.1. Types of Names .....................................15
+           3.1.2. Need for Names to Be Meaningful ....................15
+           3.1.3. Anonymity or Pseudonymity of Subscribers ...........15
+           3.1.4. Rules for Interpreting Various Name Forms ..........15
+           3.1.5. Uniqueness of Names ................................16
+           3.1.6. Recognition, Authentication, and Role of
+                  Trademarks .........................................16
+      3.2. Initial Identity Validation ...............................16
+           3.2.1. Method to Prove Possession of Private Key ..........16
+           3.2.2. Authentication of Organization Identity ............16
+           3.2.3. Authentication of Individual Identity ..............17
+           3.2.4. Non-verified Subscriber Information ................17
+           3.2.5. Validation of Authority ............................17
+           3.2.6. Criteria for Interoperation ........................17
+
+
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                 [Page 2]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+      3.3. Identification and Authentication for Re-key Requests .....18
+           3.3.1. Identification and Authentication for
+                  Routine Re-key .....................................18
+           3.3.2. Identification and Authentication for
+                  Re-key after Revocation ............................18
+      3.4. Identification and Authentication for Revocation Request ..18
+   4. Certificate Life Cycle Operational Requirements ................18
+      4.1. Certificate Application ...................................18
+           4.1.1. Who Can Submit a Certificate Application ...........18
+           4.1.2. Enrollment Process and Responsibilities ............19
+      4.2. Certificate Application Processing ........................19
+           4.2.1. Performing Identification and
+                  Authentication Functions ...........................19
+           4.2.2. Approval or Rejection of Certificate Applications ..19
+           4.2.3. Time to Process Certificate Applications ...........19
+      4.3. Certificate Issuance ......................................19
+           4.3.1. CA Actions during Certificate Issuance .............19
+           4.3.2. Notification to Subscriber by the CA of
+                  Issuance of Certificate ............................20
+           4.3.3. Notification of Certificate Issuance by the
+                  CA to Other Entities ...............................20
+      4.4. Certificate Acceptance ....................................20
+           4.4.1. Conduct Constituting Certificate Acceptance ........20
+           4.4.2. Publication of the Certificate by the CA ...........20
+           4.4.3. Notification of Certificate Issuance by the
+                  CA to Other Entities ...............................20
+      4.5. Key Pair and Certificate Usage ............................20
+           4.5.1. Subscriber Private Key and Certificate Usage .......20
+           4.5.2. Relying Party Public Key and Certificate Usage .....21
+      4.6. Certificate Renewal .......................................21
+           4.6.1. Circumstance for Certificate Renewal ...............21
+           4.6.2. Who May Request Renewal ............................21
+           4.6.3. Processing Certificate Renewal Requests ............22
+           4.6.4. Notification of New Certificate Issuance to
+                  Subscriber .........................................22
+           4.6.5. Conduct Constituting Acceptance of a
+                  Renewal Certificate ................................22
+           4.6.6. Publication of the Renewal Certificate by the CA ...22
+           4.6.7. Notification of Certificate Issuance by the
+                  CA to Other Entities ...............................22
+      4.7. Certificate Re-key ........................................22
+           4.7.1. Circumstance for Certificate Re-key ................22
+           4.7.2. Who May Request Certification of a New Public Key ..23
+           4.7.3. Processing Certificate Re-keying Requests ..........23
+           4.7.4. Notification of New Certificate Issuance to
+                  Subscriber .........................................23
+
+
+
+
+
+Kent, et al.              Best Current Practice                 [Page 3]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+           4.7.5. Conduct Constituting Acceptance of a
+                  Re-keyed Certificate ...............................23
+           4.7.6. Publication of the Re-keyed Certificate by the CA ..23
+           4.7.7. Notification of Certificate Issuance by the
+                  CA to Other Entities ...............................23
+      4.8. Certificate Modification ..................................23
+           4.8.1. Circumstance for Certificate Modification ..........23
+           4.8.2. Who May Request Certificate Modification ...........24
+           4.8.3. Processing Certificate Modification Requests .......24
+           4.8.4. Notification of Modified Certificate
+                  Issuance to Subscriber .............................24
+           4.8.5. Conduct Constituting Acceptance of Modified
+                  Certificate ........................................24
+           4.8.6. Publication of the Modified Certificate by the CA ..24
+           4.8.7. Notification of Certificate Issuance by the
+                  CA to Other Entities ...............................24
+      4.9. Certificate Revocation and Suspension .....................25
+           4.9.1. Circumstances for Revocation .......................25
+           4.9.2. Who Can Request Revocation .........................25
+           4.9.3. Procedure for Revocation Request ...................25
+           4.9.4. Revocation Request Grace Period ....................25
+           4.9.5. Time within Which CA Must Process the
+                  Revocation Request .................................25
+           4.9.6. Revocation Checking Requirement for Relying
+                  Parties ............................................25
+           4.9.7. CRL Issuance Frequency .............................26
+           4.9.8. Maximum Latency for CRLs ...........................26
+      4.10. Certificate Status Services ..............................26
+   5. Facility, Management, and Operational Controls .................26
+      5.1. Physical Controls .........................................26
+           5.1.1. Site Location and Construction .....................26
+           5.1.2. Physical Access ....................................26
+           5.1.3. Power and Air Conditioning .........................26
+           5.1.4. Water Exposures ....................................26
+           5.1.5. Fire Prevention and Protection .....................26
+           5.1.6. Media Storage ......................................26
+           5.1.7. Waste Disposal .....................................26
+           5.1.8. Off-Site Backup ....................................26
+      5.2. Procedural Controls .......................................27
+           5.2.1. Trusted Roles ......................................27
+           5.2.2. Number of Persons Required per Task ................27
+           5.2.3. Identification and Authentication for Each Role ....27
+           5.2.4. Roles Requiring Separation of Duties ...............27
+
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                 [Page 4]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+      5.3. Personnel Controls ........................................27
+           5.3.1. Qualifications, Experience, and Clearance
+                  Requirements .......................................27
+           5.3.2. Background Check Procedures ........................27
+           5.3.3. Training Requirements ..............................27
+           5.3.4. Retraining Frequency and Requirements ..............27
+           5.3.5. Job Rotation Frequency and Sequence ................27
+           5.3.6. Sanctions for Unauthorized Actions .................27
+           5.3.7. Independent Contractor Requirements ................27
+           5.3.8. Documentation Supplied to Personnel ................27
+      5.4. Audit Logging Procedures ..................................28
+           5.4.1. Types of Events Recorded ...........................28
+           5.4.2. Frequency of Processing Log ........................28
+           5.4.3. Retention Period for Audit Log .....................28
+           5.4.4. Protection of Audit Log ............................28
+           5.4.5. Audit Log Backup Procedures ........................28
+           5.4.6. Audit Collection System (Internal vs.
+                  External) [OMITTED] ................................29
+           5.4.7. Notification to Event-Causing Subject [OMITTED] ....29
+           5.4.8. Vulnerability Assessments ..........................29
+      5.5. Records Archival [OMITTED] ................................29
+      5.6. Key Changeover ............................................29
+      5.7. Compromise and Disaster Recovery ..........................29
+      5.8. CA or RA Termination ......................................29
+   6. Technical Security Controls ....................................29
+      6.1. Key Pair Generation and Installation ......................29
+           6.1.1. Key Pair Generation ................................29
+           6.1.2. Private Key Delivery to Subscriber .................30
+           6.1.3. Public Key Delivery to Certificate Issuer ..........30
+           6.1.4. CA Public Key Delivery to Relying Parties ..........30
+           6.1.5. Key Sizes ..........................................30
+           6.1.6. Public Key Parameter Generation and Quality
+                  Checking ...........................................30
+           6.1.7. Key Usage Purposes (as per X.509 v3 Key
+                  Usage Field) .......................................30
+      6.2. Private Key Protection and Cryptographic Module
+           Engineering Controls ......................................31
+           6.2.1. Cryptographic Module Standards and Controls ........31
+           6.2.2. Private Key (n out of m) Multi-Person Control ......31
+           6.2.3. Private Key Escrow .................................31
+           6.2.4. Private Key Backup .................................31
+           6.2.5. Private Key Archival ...............................31
+           6.2.6. Private Key Transfer into or from a
+                  Cryptographic Module ...............................31
+           6.2.7. Private Key Storage on Cryptographic Module ........31
+           6.2.8. Method of Activating Private Key ...................32
+
+
+
+
+
+Kent, et al.              Best Current Practice                 [Page 5]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+           6.2.9. Method of Deactivating Private Key .................32
+           6.2.10. Method of Destroying Private Key ..................32
+           6.2.11. Cryptographic Module Rating .......................32
+      6.3. Other Aspects of Key Pair Management ......................32
+           6.3.1. Public Key Archival ................................32
+           6.3.2. Certificate Operational Periods and Key
+                  Pair Usage Periods .................................32
+      6.4. Activation Data ...........................................32
+           6.4.1. Activation Data Generation and Installation ........32
+           6.4.2. Activation Data Protection .........................32
+           6.4.3. Other Aspects of Activation Data ...................33
+      6.5. Computer Security Controls ................................33
+      6.6. Life Cycle Technical Controls .............................33
+           6.6.1. System Development Controls ........................33
+           6.6.2. Security Management Controls .......................33
+           6.6.3. Life Cycle Security Controls .......................33
+      6.7. Network Security Controls .................................33
+      6.8. Time-Stamping .............................................33
+   7. Certificate and CRL Profiles ...................................33
+   8. Compliance Audit and Other Assessments .........................34
+   9. Other Business and Legal Matters ...............................34
+      9.1. Fees ......................................................34
+           9.1.1. Certificate Issuance or Renewal Fees ...............34
+           9.1.2. Certificate Access Fees [OMITTED] ..................34
+           9.1.3. Revocation or Status Information Access
+                  Fees [OMITTED] .....................................34
+           9.1.4. Fees for Other Services (if Applicable) ............34
+           9.1.5. Refund Policy ......................................34
+      9.2. Financial Responsibility ..................................34
+           9.2.1. Insurance Coverage .................................34
+           9.2.2. Other Assets .......................................34
+           9.2.3. Insurance or Warranty Coverage for End-Entities ....34
+      9.3. Confidentiality of Business Information ...................34
+           9.3.1. Scope of Confidential Information ..................34
+           9.3.2. Information Not within the Scope of
+                  Confidential Information ...........................34
+           9.3.3. Responsibility to Protect Confidential
+                  Information ........................................34
+      9.4. Privacy of Personal Information ...........................34
+           9.4.1. Privacy Plan .......................................34
+           9.4.2. Information Treated as Private .....................35
+           9.4.3. Information Not Deemed Private .....................35
+           9.4.4. Responsibility to Protect Private Information ......35
+           9.4.5. Notice and Consent to Use Private Information ......35
+           9.4.6. Disclosure Pursuant to Judicial or
+                  Administrative Process .............................35
+           9.4.7. Other Information Disclosure Circumstances .........35
+
+
+
+
+Kent, et al.              Best Current Practice                 [Page 6]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+      9.5. Intellectual Property Rights (if Applicable) ..............35
+      9.6. Representations and Warranties ............................35
+           9.6.1. CA Representations and Warranties ..................35
+           9.6.2. Subscriber Representations and Warranties ..........35
+           9.6.3. Relying Party Representations and Warranties .......35
+      9.7. Disclaimers of Warranties .................................35
+      9.8. Limitations of Liability ..................................35
+      9.9. Indemnities ...............................................35
+      9.10. Term and Termination .....................................35
+           9.10.1. Term ..............................................35
+           9.10.2. Termination .......................................35
+           9.10.3. Effect of Termination and Survival ................35
+      9.11. Individual Notices and Communications with Participants ..35
+      9.12. Amendments ...............................................35
+           9.12.1. Procedure for Amendment ...........................35
+           9.12.2. Notification Mechanism and Period .................35
+      9.13. Dispute Resolution Provisions ............................35
+      9.14. Governing Law ............................................35
+      9.15. Compliance with Applicable Law ...........................36
+      9.16. Miscellaneous Provisions .................................36
+           9.16.1. Entire Agreement ..................................36
+           9.16.2. Assignment ........................................36
+           9.16.3. Severability ......................................36
+           9.16.4. Enforcement (Attorneys' Fees and Waiver of
+                   Rights) ...........................................36
+           9.16.5. Force Majeure .....................................36
+   10. Security Considerations .......................................36
+   11. References ....................................................37
+      11.1. Normative References .....................................37
+      11.2. Informative References ...................................37
+   Acknowledgments ...................................................38
+   Authors' Addresses ................................................38
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                 [Page 7]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+Preface
+
+   This RFC contains text intended for use as a template as designated
+   below by the markers <BEGIN TEMPLATE TEXT> and <END TEMPLATE TEXT>.
+   Such Template Text is subject to the provisions of Section 9(b) of
+   the Trust Legal Provisions.
+
+   This document contains a template to be used for creating a
+   Certification Practice Statement (CPS) for an organization that is
+   part of the Resource Public Key Infrastructure (RPKI).  (Throughout
+   this document, the term "organization" is used broadly, e.g., the
+   entity in question might be a business unit of a larger
+   organization.)
+
+   There is no expectation that a CPS will be published as an RFC.  An
+   organization will publish the CPS in a manner appropriate for access
+   by the users of the RPKI, e.g., on the organization's web site.  As a
+   best current practice, organizations are expected to use this
+   template instead of creating one from scratch.  This template
+   contains both text that SHOULD appear in all Certification Practice
+   Statements and places for text specific to the organization in
+   question (indicated by <text in angle brackets>).
+
+   The user of this document should:
+
+   1. Extract the text between the <BEGIN TEMPLATE TEXT> and
+      <END TEMPLATE TEXT> delimiters.
+
+   2. Replace the instructions between the angle brackets with the
+      required information.
+
+   This document has been generated to complement the Certificate Policy
+   (CP) for the RPKI [RFC6484].  Like RFC 6484, it is based on the
+   template specified in RFC 3647 [RFC3647].  A number of sections
+   contained in the template were omitted from this CPS because they did
+   not apply to this PKI.  However, we have retained the section
+   numbering scheme employed in that RFC to facilitate comparison with
+   the section numbering scheme employed in that RFC and in RFC 6484.
+
+   Conventions Used in This Document:
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                 [Page 8]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+<BEGIN TEMPLATE TEXT>
+
+   <Create a title page saying, e.g., "<Name of organization>
+   Certification Practice Statement for the Resource Public Key
+   Infrastructure (RPKI)" with date, author, etc.>
+
+   <Create a table of contents.>
+
+1.  Introduction
+
+   This document is the Certification Practice Statement (CPS) of <name
+   of organization>.  It describes the practices employed by the <name
+   of organization> Certification Authority (CA) in the Resource Public
+   Key Infrastructure (RPKI).  These practices are defined in accordance
+   with the requirements of the Certificate Policy (CP) [RFC6484] for
+   the RPKI.
+
+   The RPKI is designed to support validation of claims by current
+   holders of Internet Number Resources (INRs) (Section 1.6) in
+   accordance with the records of the organizations that act as CAs in
+   this PKI.  The ability to verify such claims is essential to ensuring
+   the unique, unambiguous distribution of these resources.
+
+   This PKI parallels the existing INR distribution hierarchy.  These
+   resources are distributed by the Internet Assigned Numbers Authority
+   (IANA) to the Regional Internet Registries (RIRs).  In some regions,
+   National Internet Registries (NIRs) form a tier of the hierarchy
+   below the RIRs for INR distribution.  Internet Service Providers
+   (ISPs) and network subscribers form additional tiers below
+   registries.
+
+   Conventions Used in This Document:
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                 [Page 9]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+1.1.  Overview
+
+   This CPS describes:
+
+   o  Participants
+
+   o  Publication of the certificates and Certificate Revocation Lists
+      (CRLs)
+
+   o  How certificates are issued, managed, re-keyed, renewed, and
+      revoked
+
+   o  Facility management (physical security, personnel, audit, etc.)
+
+   o  Key management
+
+   o  Audit procedures
+
+   o  Business and legal issues
+
+   This PKI encompasses several types of certificates (see [RFC6480] for
+   more details):
+
+   o  CA certificates for each organization distributing INRs and for
+      each subscriber INR holder.
+
+   o  End-entity (EE) certificates for organizations to use to validate
+      digital signatures on RPKI-signed objects (see definition in
+      Section 1.6).
+
+   o  In the future, the PKI also may include end-entity certificates in
+      support of access control for the repository system as described
+      in Section 2.4.
+
+1.2.  Document Name and Identification
+
+   The name of this document is "<Name of organization> Certification
+   Practice Statement for the Resource Public Key Infrastructure
+   (RPKI)".  <If this document is available via the Internet, the CA can
+   provide the URI for the CPS here.  It SHOULD be the same URI as the
+   URI that appears as a policy qualifier in the CA certificate for the
+   CA, if the CA elects to make use of that feature.>
+
+
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 10]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+1.3.  PKI Participants
+
+   Note that in a PKI the term "subscriber" refers to an individual or
+   organization that is a subject of a certificate issued by a CA.  The
+   term is used in this fashion throughout this document, without
+   qualification, and should not be confused with the networking use of
+   the term to refer to an individual or organization that receives
+   service from an ISP.  In such cases, the term "network subscriber"
+   will be used.  Also note that, for brevity, this document always
+   refers to PKI participants as organizations or entities, even though
+   some of them are individuals.
+
+1.3.1.  Certification Authorities
+
+   <Describe the CAs that you will operate for the RPKI.  One approach
+   is to operate two CAs: one designated "offline" and the other
+   designated "production".  The offline CA is the top-level CA for the
+   <name of organization> portion of the RPKI.  It provides a secure
+   revocation and recovery capability in case the production CA is
+   compromised or becomes unavailable.  Thus, the offline CA issues
+   certificates only to instances of the production CA, and the CRLs it
+   issues are used to revoke only certificates issued to the production
+   CA.  The production CA is used to issue RPKI certificates to <name of
+   organization> members, to whom INRs have been distributed.>
+
+1.3.2.  Registration Authorities
+
+   <Describe how the Registration Authority (RA) function is handled for
+   the CA(s) that you operate.  The RPKI does not require establishment
+   or use of a separate Registration Authority in addition to the CA
+   function.  The RA function MUST be provided by the same entity
+   operating as a CA, e.g., entities listed in Section 1.3.1.  An entity
+   acting as a CA in this PKI already has a formal relationship with
+   each organization to which it distributes INRs.  These organizations
+   already perform the RA function implicitly, since they already assume
+   responsibility for distributing INRs.>
+
+1.3.3.  Subscribers
+
+   Organizations receiving INR allocations from this CA are subscribers
+   in the RPKI.
+
+1.3.4.  Relying Parties
+
+   Entities or individuals that act in reliance on certificates or
+   RPKI-signed objects issued under this PKI are relying parties.
+   Relying parties may or may not be subscribers within this PKI.
+   (See Section 1.6 for the definition of an RPKI-signed object.)
+
+
+
+Kent, et al.              Best Current Practice                [Page 11]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+1.3.5.  Other Participants
+
+   <Specify one or more entities that operate a repository holding
+   certificates, CRLs, and other RPKI-signed objects issued by this
+   organization, and provide a URL for the repository.>
+
+1.4.  Certificate Usage
+
+1.4.1.  Appropriate Certificate Uses
+
+   The certificates issued under this hierarchy are for authorization in
+   support of validation of claims of current holdings of INRs.
+
+   Additional uses of the certificates, consistent with the basic goal
+   cited above, are also permitted under RFC 6484.
+
+   Some of the certificates that may be issued under this PKI could be
+   used to support operation of this infrastructure, e.g., access
+   control for the repository system as described in Section 2.4.  Such
+   uses also are permitted under the RPKI certificate policy.
+
+1.4.2.  Prohibited Certificate Uses
+
+   Any uses other than those described in Section 1.4.1 are prohibited.
+
+1.5.  Policy Administration
+
+1.5.1.  Organization Administering the Document
+
+   This CPS is administered by <name of organization>.  <Include the
+   mailing address, email address, and similar contact info here.>
+
+1.5.2.  Contact Person
+
+   <Insert organization contact info here.>
+
+1.5.3.  Person Determining CPS Suitability for the Policy
+
+   Not applicable.  Each organization issuing a certificate in this PKI
+   is attesting to the distribution of INRs to the holder of the private
+   key corresponding to the public key in the certificate.  The issuing
+   organizations are the same organizations as the ones that perform the
+   distribution; hence, they are authoritative with respect to the
+   accuracy of this binding.
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 12]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+1.5.4.  CPS Approval Procedures
+
+   Not applicable.  Each organization issuing a certificate in this PKI
+   is attesting to the distribution of INRs to the holder of the private
+   key corresponding to the public key in the certificate.  The issuing
+   organizations are the same organizations as the ones that perform the
+   distribution; hence, they are authoritative with respect to the
+   accuracy of this binding.
+
+1.6.  Definitions and Acronyms
+
+   BPKI   Business PKI.  A BPKI is an optional additional PKI used by an
+          organization to identify members to whom RPKI certificates can
+          be issued.  If a BPKI is employed by a CA, it may have its own
+          CP, separate from the RPKI CP.
+
+   CP     Certificate Policy.  A CP is a named set of rules that
+          indicates the applicability of a certificate to a particular
+          community and/or class of applications with common security
+          requirements.  The CP for the RPKI is [RFC6484].
+
+   CPS    Certification Practice Statement.  A CPS is a document that
+          specifies the practices that a Certification Authority employs
+          in issuing certificates.
+
+   Distribution of INRs   A process of distribution of the INRs along
+          the respective number hierarchy.  IANA distributes blocks of
+          IP addresses and Autonomous System Numbers (ASNs) to the five
+          Regional Internet Registries (RIRs).  RIRs distribute smaller
+          address blocks and Autonomous System Numbers to organizations
+          within their service regions, who in turn distribute IP
+          addresses to their customers.
+
+   IANA   Internet Assigned Numbers Authority.  IANA is responsible for
+          global coordination of the Internet Protocol addressing
+          systems and ASNs used for routing Internet traffic.  IANA
+          distributes INRs to RIRs.
+
+   INRs   Internet Number Resources.  INRs are number values for three
+          protocol parameter sets, namely:
+
+          o  IP version 4 addresses,
+
+          o  IP version 6 addresses, and
+
+          o  Identifiers used in Internet inter-domain routing,
+             currently Border Gateway Protocol-4 ASNs.
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 13]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+   ISP    Internet Service Provider.  An ISP is an organization managing
+          and selling Internet services to other organizations.
+
+   NIR    National Internet Registry.  An NIR is an organization that
+          manages the distribution of INRs for a portion of the
+          geopolitical area covered by a Regional Internet Registry.
+          NIRs form an optional second tier in the tree scheme used to
+          manage INR distribution.
+
+   RIR    Regional Internet Registry.  An RIR is an organization that
+          manages the distribution of INRs for a geopolitical area.
+
+   RPKI-signed object   An RPKI-signed object is a digitally signed data
+          object (other than a certificate or CRL) declared to be such
+          an object by a Standards Track RFC.  An RPKI-signed object can
+          be validated using certificates issued under this PKI.  The
+          content and format of these data constructs depend on the
+          context in which validation of claims of current holdings of
+          INRs takes place.  Examples of these objects are repository
+          manifests [RFC6486] and Route Origin Authorizations (ROAs)
+          [RFC6482].
+
+2.  Publication and Repository Responsibilities
+
+2.1.  Repositories
+
+   As per the CP, certificates, CRLs, and RPKI-signed objects MUST be
+   made available for downloading by all relying parties, to enable them
+   to validate this data.
+
+   The <name of organization> RPKI CA will publish certificates, CRLs,
+   and RPKI-signed objects via a repository that is accessible via
+   <insert IETF-designated protocol name here> at <insert URL here>.
+   This repository will conform to the structure described in [RFC6481].
+
+2.2.  Publication of Certification Information
+
+   <Name of organization> will publish certificates, CRLs, and
+   RPKI-signed objects issued by it to a repository that operates as
+   part of a worldwide distributed system of RPKI repositories.
+
+2.3.  Time or Frequency of Publication
+
+   <Describe here your procedures for publication (to the global
+   repository system) of the certificates, CRLs, and RPKI-signed objects
+   that you issue.  If you choose to outsource publication of PKI data,
+   you still need to provide this information for relying parties.  This
+   MUST include the period of time within which a certificate will be
+
+
+
+Kent, et al.              Best Current Practice                [Page 14]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+   published after the CA issues the certificate, and the period of time
+   within which a CA will publish a CRL with an entry for a revoked
+   certificate, after the CA revokes that certificate.>
+
+   The <name of organization> CA will publish its CRL prior to the
+   nextUpdate value in the scheduled CRL previously issued by the CA.
+
+2.4.  Access Controls on Repositories
+
+   <Describe the access controls used by the organization to ensure that
+   only authorized parties can modify repository data, and any controls
+   used to mitigate denial-of-service attacks against the repository.
+   If the organization offers repository services to its subscribers,
+   then describe here the protocol(s) that it supports for publishing
+   signed objects from subscribers.>
+
+3.  Identification and Authentication
+
+3.1.  Naming
+
+3.1.1.  Types of Names
+
+   The subject of each certificate issued by this organization is
+   identified by an X.500 Distinguished Name (DN).  The distinguished
+   name will consist of a single Common Name (CN) attribute with a value
+   generated by <name of organization>.  Optionally, the serialNumber
+   attribute may be included along with the common name (to form a
+   terminal relative distinguished name set), to distinguish among
+   successive instances of certificates associated with the same entity.
+
+3.1.2.  Need for Names to Be Meaningful
+
+   The Subject name in each certificate SHOULD NOT be "meaningful", in
+   the conventional, human-readable sense.  The rationale here is that
+   these certificates are used for authorization in support of
+   applications that make use of attestations of INR holdings.  They are
+   not used to identify subjects.
+
+3.1.3.  Anonymity or Pseudonymity of Subscribers
+
+   Although Subject names in certificates issued by this organization
+   SHOULD NOT be meaningful and may appear "random", anonymity is not a
+   function of this PKI; thus, no explicit support for this feature is
+   provided.
+
+3.1.4.  Rules for Interpreting Various Name Forms
+
+   None
+
+
+
+Kent, et al.              Best Current Practice                [Page 15]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+3.1.5.  Uniqueness of Names
+
+   <Name of organization> certifies Subject names that are unique among
+   the certificates that it issues.  Although it is desirable that these
+   Subject names be unique throughout the PKI, to facilitate certificate
+   path discovery, such uniqueness is not required, nor is it enforced
+   through technical means.  <Name of organization> generates Subject
+   names to minimize the chances that two entities in the RPKI will be
+   assigned the same name.  Specifically, <insert Subject name
+   generation description here, or cite RFC 6487>.
+
+3.1.6.  Recognition, Authentication, and Role of Trademarks
+
+   Because the Subject names are not intended to be meaningful, <name of
+   organization> makes no provision either to recognize or to
+   authenticate trademarks, service marks, etc.
+
+3.2.  Initial Identity Validation
+
+3.2.1.  Method to Prove Possession of Private Key
+
+   <Describe the method whereby each subscriber will be required to
+   demonstrate proof-of-possession (PoP) of the private key
+   corresponding to the public key in the certificate, prior to
+   certificate issuance.>
+
+3.2.2.  Authentication of Organization Identity
+
+   Certificates issued under this PKI do not attest to the
+   organizational identity of subscribers.  However, certificates are
+   issued to subscribers in a fashion that preserves the accuracy of
+   distributions of INRs as represented in <name of organization>
+   records.
+
+   <Describe the procedures that will be used to ensure that each RPKI
+   certificate that is issued accurately reflects your records with
+   regard to the organization to which you have distributed (or
+   sub-distributed) the INRs identified in the certificate.  For
+   example, a BPKI certificate could be used to authenticate a
+   certificate request that serves as a link to the <name of
+   organization> subscriber database that maintains the INR distribution
+   records.  The certificate request could be matched against the
+   database record for the subscriber in question, and an RPKI
+   certificate would be issued only if the INRs requested were a subset
+   of those held by the subscriber.  The specific procedures employed
+   for this purpose should be commensurate with any you already employ
+   in the maintenance of INR distribution.>
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 16]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+3.2.3.  Authentication of Individual Identity
+
+   Certificates issued under this PKI do not attest to the individual
+   identity of a subscriber.  However, <name of organization> maintains
+   contact information for each subscriber in support of certificate
+   renewal, re-key, and revocation.
+
+   <Describe the procedures that are used to identify at least one
+   individual as a representative of each subscriber.  This is done in
+   support of issuance, renewal, and revocation of the certificate
+   issued to the organization.  For example, one might say "The <name of
+   organization> BPKI (see Section 3.2.6) issues certificates that MUST
+   be used to identify individuals who represent <name of organization>
+   subscribers."  The procedures should be commensurate with those you
+   already employ in authenticating individuals as representatives for
+   INR holders.  Note that this authentication is solely for use by you
+   in dealing with the organizations to which you distribute (or
+   sub-distribute) INRs and thus MUST NOT be relied upon outside of this
+   CA/subscriber relationship.>
+
+3.2.4.  Non-verified Subscriber Information
+
+   No non-verified subscriber data is included in certificates issued
+   under this certificate policy except for Subject Information Access
+   (SIA) extensions [RFC6487].
+
+3.2.5.  Validation of Authority
+
+   <Describe the procedures used to verify that an individual claiming
+   to represent a subscriber is authorized to represent that subscriber
+   in this context.  For example, one could say "Only an individual to
+   whom a BPKI certificate (see Section 3.2.6) has been issued may
+   request issuance of an RPKI certificate.  Each certificate issuance
+   request is verified using the BPKI."  The procedures should be
+   commensurate with those you already employ in authenticating
+   individuals as representatives of subscribers.>
+
+3.2.6.  Criteria for Interoperation
+
+   The RPKI is neither intended nor designed to interoperate with any
+   other PKI.  <If you operate a separate, additional PKI for business
+   purposes, e.g., a BPKI, then describe (or reference) how the BPKI is
+   used to authenticate subscribers and to enable them to manage their
+   resource distributions.>
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 17]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+3.3.  Identification and Authentication for Re-key Requests
+
+3.3.1.  Identification and Authentication for Routine Re-key
+
+   <Describe the conditions under which routine re-key is required and
+   the manner by which it is requested.  Describe the procedures that
+   are used to ensure that a subscriber requesting routine re-key is the
+   legitimate holder of the certificate to be re-keyed.  State the
+   approach for establishing PoP of the private key corresponding to the
+   new public key.  If you operate a BPKI, describe how that BPKI is
+   used to authenticate routine re-key requests.>
+
+3.3.2.  Identification and Authentication for Re-key after Revocation
+
+   <Describe the procedures used to ensure that an organization
+   requesting a re-key after revocation is the legitimate holder of the
+   INRs in the certificate being re-keyed.  This MUST also include the
+   method employed for verifying PoP of the private key corresponding to
+   the new public key.  If you operate a BPKI, describe how that BPKI is
+   used to authenticate re-key requests.  With respect to authentication
+   of the subscriber, the procedures should be commensurate with those
+   you already employ in the maintenance of INR distribution records.>
+
+3.4.  Identification and Authentication for Revocation Request
+
+   <Describe the procedures used by an RPKI subscriber to make a
+   revocation request.  Describe the manner by which it is ensured that
+   the subscriber requesting revocation is the subject of the
+   certificate (or an authorized representative thereof) to be revoked.
+   Note that there may be different procedures for the case where the
+   legitimate subject still possesses the original private key as
+   opposed to the case when it no longer has access to that key.  These
+   procedures should be commensurate with those you already employ in
+   the maintenance of subscriber records.>
+
+4.  Certificate Life Cycle Operational Requirements
+
+4.1.  Certificate Application
+
+4.1.1.  Who Can Submit a Certificate Application
+
+   Any subscriber in good standing who holds INRs distributed by <name
+   of organization> may submit a certificate application to this CA.
+   (The exact meaning of "in good standing" is in accordance with the
+   policy of <name of organization>.)
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 18]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+4.1.2.  Enrollment Process and Responsibilities
+
+   <Describe your enrollment process for issuing certificates both for
+   initial deployment of the PKI and as an ongoing process.  Note that
+   most of the certificates in this PKI are issued as part of your
+   normal business practices, as an adjunct to INR distribution, and
+   thus a separate application to request a certificate may not be
+   necessary.  If so, reference should be made to where these practices
+   are documented.>
+
+4.2.  Certificate Application Processing
+
+   <Describe the certificate request/response processing that you will
+   employ.  You should make use of existing standards for certificate
+   application processing (see [RFC6487]).>
+
+4.2.1.  Performing Identification and Authentication Functions
+
+   <Describe your practices for identification and authentication of
+   certificate applicants.  Often, existing practices employed by you to
+   identify and authenticate organizations can be used as the basis for
+   issuance of certificates to these subscribers.  Reference can be made
+   to documentation of such existing practices.>
+
+4.2.2.  Approval or Rejection of Certificate Applications
+
+   <Describe your practices for approval or rejection of applications,
+   and refer to documentation of existing business practices relevant to
+   this process.  Note that according to the CP, certificate
+   applications will be approved based on the normal business practices
+   of the entity operating the CA, based on the CA's records of
+   subscribers.  The CP also says that each CA will follow the procedure
+   specified in Section 3.2.1 to verify that the requester holds the
+   private key corresponding to the public key that will be bound to the
+   certificate the CA issues to the requester.>
+
+4.2.3.  Time to Process Certificate Applications
+
+   <Specify here your expected time frame for processing certificate
+   applications.>
+
+4.3.  Certificate Issuance
+
+4.3.1.  CA Actions during Certificate Issuance
+
+   <Describe your procedures for issuance and publication of a
+   certificate.>
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 19]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+4.3.2.  Notification to Subscriber by the CA of Issuance of Certificate
+
+   <Name of organization> will notify the subscriber when the
+   certificate is published.  <Describe here your procedures for
+   notifying a subscriber when a certificate has been published.>
+
+4.3.3.  Notification of Certificate Issuance by the CA to Other Entities
+
+   <Describe here any other entities that will be notified when a
+   certificate is published.>
+
+4.4.  Certificate Acceptance
+
+4.4.1.  Conduct Constituting Certificate Acceptance
+
+   When a certificate is issued, the <name of organization> CA will
+   publish it to the repository and notify the subscriber.  <This may be
+   done without subscriber review and acceptance.  State your policy
+   with respect to subscriber certificate acceptance here.>
+
+4.4.2.  Publication of the Certificate by the CA
+
+   Certificates will be published at <insert repository URL here> once
+   issued, following the conduct described in Section 4.4.1.  This will
+   be done within <specify the time frame within which the certificate
+   will be placed in the repository and the subscriber will be
+   notified>.  <Describe any additional procedures with respect to
+   publication of the certificate here.>
+
+4.4.3.  Notification of Certificate Issuance by the CA to Other Entities
+
+   <Describe here any other entities that will be notified when a
+   certificate is published.>
+
+4.5.  Key Pair and Certificate Usage
+
+   A summary of the use model for the RPKI is provided below.
+
+4.5.1.  Subscriber Private Key and Certificate Usage
+
+   The certificates issued by <name of organization> to subordinate INR
+   holders are CA certificates.  The private key associated with each of
+   these certificates is used to sign subordinate (CA or EE)
+   certificates and CRLs.
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 20]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+4.5.2.  Relying Party Public Key and Certificate Usage
+
+   The primary relying parties in this PKI are organizations that use
+   RPKI EE certificates to verify RPKI-signed objects.  Relying parties
+   are referred to Section 4.5.2 of [RFC6484] for additional guidance
+   with respect to acts of reliance on RPKI certificates.
+
+4.6.  Certificate Renewal
+
+4.6.1.  Circumstance for Certificate Renewal
+
+   As per RFC 6484, a certificate will be processed for renewal based on
+   its expiration date or a renewal request from the certificate
+   Subject.  The request may be implicit, a side effect of renewing a
+   resource holding agreement, or explicit.  If <name of organization>
+   initiates the renewal process based on the certificate expiration
+   date, then <name of organization> will notify the subscriber <insert
+   the period of advance warning, e.g., "2 weeks in advance of the
+   expiration date", or the general policy, e.g., "in conjunction with
+   notification of service expiration">.  The validity interval of the
+   new (renewed) certificate will overlap that of the previous
+   certificate by <insert length of overlap period, e.g., 1 week>, to
+   ensure uninterrupted coverage.
+
+   Certificate renewal will incorporate the same public key as the
+   previous certificate, unless the private key has been reported as
+   compromised (see Section 4.9.1).  If a new key pair is being used,
+   the stipulations of Section 4.7 will apply.
+
+4.6.2.  Who May Request Renewal
+
+   The subscriber or <name of organization> may initiate the renewal
+   process.  <For the case of the subscriber, describe the procedures
+   that will be used to ensure that the requester is the legitimate
+   holder of the INRs in the certificate being renewed.  This MUST also
+   include the method employed for verifying PoP of the private key
+   corresponding to the public key in the certificate being renewed or
+   the new public key if the public key is being changed.  With respect
+   to authentication of the subscriber, the procedures should be
+   commensurate with those you already employ in the maintenance of INR
+   distribution records.  If you operate a BPKI for this, describe how
+   that business-based PKI is used to authenticate renewal requests, and
+   refer to Section 3.2.6.>
+
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 21]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+4.6.3.  Processing Certificate Renewal Requests
+
+   <Describe your procedures for handling certificate renewal requests.
+   Describe how you verify that the requester is the subscriber or is
+   authorized by the subscriber, and that the certificate in question
+   has not been revoked.>
+
+4.6.4.  Notification of New Certificate Issuance to Subscriber
+
+   <Name of organization> will notify the subscriber when the
+   certificate is published.  <Describe your procedure for notification
+   of new certificate issuance to the subscriber.  This should be
+   consistent with Section 4.3.2.>
+
+4.6.5.  Conduct Constituting Acceptance of a Renewal Certificate
+
+   See Section 4.4.1.  <If you employ a different policy from that
+   specified in Section 4.4.1, describe it here.>
+
+4.6.6.  Publication of the Renewal Certificate by the CA
+
+   See Section 4.4.2.
+
+4.6.7.  Notification of Certificate Issuance by the CA to Other Entities
+
+   See Section 4.4.3.
+
+4.7.  Certificate Re-key
+
+4.7.1.  Circumstance for Certificate Re-key
+
+   As per RFC 6484, re-key of a certificate will be performed only when
+   required, based on:
+
+   1. knowledge or suspicion of compromise or loss of the associated
+      private key, or
+
+   2. the expiration of the cryptographic lifetime of the associated key
+      pair
+
+   If a certificate is revoked to replace the RFC 3779 extensions, the
+   replacement certificate will incorporate the same public key, not a
+   new key.
+
+   If the re-key is based on a suspected compromise, then the previous
+   certificate will be revoked.
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 22]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+4.7.2.  Who May Request Certification of a New Public Key
+
+   Only the holder of a certificate may request a re-key.  In addition,
+   <name of organization> may initiate a re-key based on a verified
+   compromise report.  <If the subscriber (certificate Subject) requests
+   the re-key, describe how authentication is effected, e.g., using the
+   <name of registry> BPKI.  Describe how a compromise report received
+   from other than a subscriber is verified.>
+
+4.7.3.  Processing Certificate Re-keying Requests
+
+   <Describe your process for handling re-keying requests.  As per the
+   RPKI CP, this should be consistent with the process described in
+   Section 4.3, so reference can be made to that section.>
+
+4.7.4.  Notification of New Certificate Issuance to Subscriber
+
+   <Describe your policy for notifying the subscriber regarding
+   availability of the new re-keyed certificate.  This should be
+   consistent with the notification process for any new certificate
+   issuance (see Section 4.3.2).>
+
+4.7.5.  Conduct Constituting Acceptance of a Re-keyed Certificate
+
+   When a re-keyed certificate is issued, the CA will publish it in the
+   repository and notify the subscriber.  See Section 4.4.1.
+
+4.7.6.  Publication of the Re-keyed Certificate by the CA
+
+   <Describe your policy regarding publication of the new certificate.
+   This should be consistent with the publication process for any new
+   certificate (see Section 4.4.2).>
+
+4.7.7.  Notification of Certificate Issuance by the CA to Other Entities
+
+   See Section 4.4.3.
+
+4.8.  Certificate Modification
+
+4.8.1.  Circumstance for Certificate Modification
+
+   As per RFC 6484, modification of a certificate occurs to implement
+   changes to the RFC 3779 extension values or the SIA extension in a
+   certificate.  A subscriber can request a certificate modification
+   when this information in a currently valid certificate has changed,
+   as a result of changes in the INR holdings of the subscriber, or as a
+   result of change of the repository publication point data.
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 23]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+   If a subscriber is to receive a distribution of INRs in addition to a
+   current distribution, and if the subscriber does not request that a
+   new certificate be issued containing only these additional INRs, then
+   this is accomplished through a certificate modification.  When a
+   certificate modification is approved, a new certificate is issued.
+   The new certificate will contain the same public key and the same
+   expiration date as the original certificate, but with the incidental
+   information corrected and/or the INR distribution expanded.  When
+   previously distributed INRs are to be removed from a certificate,
+   then the old certificate will be revoked and a new certificate
+   (reflecting the new distribution) issued.
+
+4.8.2.  Who May Request Certificate Modification
+
+   The subscriber or <name of organization> may initiate the certificate
+   modification process.  <For the case of the subscriber, state here
+   what steps will be taken to verify the identity and authorization of
+   the entity requesting the modification.>
+
+4.8.3.  Processing Certificate Modification Requests
+
+   <Describe your procedures for verification of the modification
+   request and procedures for the issuance of a new certificate.  These
+   should be consistent with the processes described in Sections 4.2
+   and 4.3.1.>
+
+4.8.4.  Notification of Modified Certificate Issuance to Subscriber
+
+   <Describe your procedure for notifying the subscriber about the
+   issuance of a modified certificate.  This should be consistent
+   with the notification process for any new certificate (see
+   Section 4.3.2).>
+
+4.8.5.  Conduct Constituting Acceptance of Modified Certificate
+
+   When a modified certificate is issued, <name of organization> will
+   publish it to the repository and notify the subscriber.  See
+   Section 4.4.1.
+
+4.8.6.  Publication of the Modified Certificate by the CA
+
+   <Describe your procedure for publication of a modified certificate.
+   This should be consistent with the publication process for any new
+   certificate (see Section 4.4.2).>
+
+4.8.7.  Notification of Certificate Issuance by the CA to Other Entities
+
+   See Section 4.4.3.
+
+
+
+Kent, et al.              Best Current Practice                [Page 24]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+4.9.  Certificate Revocation and Suspension
+
+4.9.1.  Circumstances for Revocation
+
+   As per RFC 6484, certificates can be revoked for several reasons.
+   Either <name of organization> or the subject may choose to end the
+   relationship expressed in the certificate, thus creating cause to
+   revoke the certificate.  If one or more of the INRs bound to the
+   public key in the certificate are no longer associated with the
+   subject, that too constitutes a basis for revocation.  A certificate
+   also may be revoked due to loss or compromise of the private key
+   corresponding to the public key in the certificate.  Finally, a
+   certificate may be revoked in order to invalidate data signed by the
+   private key associated with that certificate.
+
+4.9.2.  Who Can Request Revocation
+
+   The subscriber or <name of organization> may request a revocation.
+   <For the case of the subscriber, describe what steps will be taken to
+   verify the identity and authorization of the entity requesting the
+   revocation.>
+
+4.9.3.  Procedure for Revocation Request
+
+   <Describe your process for handling a certificate revocation request.
+   This should include:
+
+   o  Procedure to be used by the subscriber to request a revocation.
+
+   o  Procedure for notification of the subscriber when the revocation
+      is initiated by <name of organization>.>
+
+4.9.4.  Revocation Request Grace Period
+
+   A subscriber is required to request revocation as soon as possible
+   after the need for revocation has been identified.
+
+4.9.5.  Time within Which CA Must Process the Revocation Request
+
+   <Describe your policy on the time period within which you will
+   process a revocation request.>
+
+4.9.6.  Revocation Checking Requirement for Relying Parties
+
+   As per RFC 6484, a relying party is responsible for acquiring and
+   checking the most recent, scheduled CRL from the issuer of the
+   certificate, whenever the relying party validates a certificate.
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 25]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+4.9.7.  CRL Issuance Frequency
+
+   <State the CRL issuance frequency for the CRLs that you publish.>
+   Each CRL contains a nextUpdate value, and a new CRL will be published
+   at or before that time.  <Name of organization> will set the
+   nextUpdate value when it issues a CRL, to signal when the next
+   scheduled CRL will be issued.
+
+4.9.8.  Maximum Latency for CRLs
+
+   A CRL will be published to the repository system within <state the
+   maximum latency> after generation.
+
+4.10.  Certificate Status Services
+
+   <Name of organization> does not support the Online Certificate Status
+   Protocol (OCSP) or the Server-Based Certificate Validation Protocol
+   (SCVP).  <Name of organization> issues CRLs.
+
+5.  Facility, Management, and Operational Controls
+
+5.1.  Physical Controls
+
+   <As per RFC 6484, describe the physical controls that you employ for
+   certificate management.  These should be commensurate with those used
+   in the management of INR distribution.>
+
+5.1.1.  Site Location and Construction
+
+5.1.2.  Physical Access
+
+5.1.3.  Power and Air Conditioning
+
+5.1.4.  Water Exposures
+
+5.1.5.  Fire Prevention and Protection
+
+5.1.6.  Media Storage
+
+5.1.7.  Waste Disposal
+
+5.1.8.  Off-Site Backup
+
+
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 26]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+5.2.  Procedural Controls
+
+   <As per RFC 6484, describe the procedural security controls that you
+   employ for certificate management.  These should be commensurate with
+   those used in the management of INR distribution.>
+
+5.2.1.  Trusted Roles
+
+5.2.2.  Number of Persons Required per Task
+
+5.2.3.  Identification and Authentication for Each Role
+
+5.2.4.  Roles Requiring Separation of Duties
+
+5.3.  Personnel Controls
+
+   <As per RFC 6484, describe the personnel security controls that you
+   employ for individuals associated with certificate management.  These
+   should be commensurate with those used in the management of INR
+   distribution.>
+
+5.3.1.  Qualifications, Experience, and Clearance Requirements
+
+5.3.2.  Background Check Procedures
+
+5.3.3.  Training Requirements
+
+5.3.4.  Retraining Frequency and Requirements
+
+5.3.5.  Job Rotation Frequency and Sequence
+
+5.3.6.  Sanctions for Unauthorized Actions
+
+5.3.7.  Independent Contractor Requirements
+
+5.3.8.  Documentation Supplied to Personnel
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 27]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+5.4.  Audit Logging Procedures
+
+   <As per the CP, describe in the following sections the details of how
+   you implement audit logging.>
+
+5.4.1.  Types of Events Recorded
+
+   Audit records will be generated for the basic operations of the
+   Certification Authority computing equipment.  Audit records will
+   include the date, time, responsible user or process, and summary
+   content data relating to the event.  Auditable events include:
+
+   o  Access to CA computing equipment (e.g., logon, logout)
+
+   o  Messages received requesting CA actions (e.g., certificate
+      requests, certificate revocation requests, compromise
+      notifications)
+
+   o  Certificate creation, modification, revocation, or renewal actions
+
+   o  Posting of any material to a repository
+
+   o  Any attempts to change or delete audit data
+
+   o  Key generation
+
+   o  Software and/or configuration updates to the CA
+
+   o  Clock adjustments
+
+   <List here any additional types of events that will be audited.>
+
+5.4.2.  Frequency of Processing Log
+
+   <Describe your procedures for review of audit logs.>
+
+5.4.3.  Retention Period for Audit Log
+
+   <Describe your policies for retention of audit logs.>
+
+5.4.4.  Protection of Audit Log
+
+   <Describe your policies for protection of the audit logs.>
+
+5.4.5.  Audit Log Backup Procedures
+
+   <Describe your policies for backup of the audit logs.>
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 28]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+5.4.6.  Audit Collection System (Internal vs. External) [OMITTED]
+
+5.4.7.  Notification to Event-Causing Subject [OMITTED]
+
+5.4.8.  Vulnerability Assessments
+
+   <Describe any vulnerability assessments that you will apply (or have
+   already applied) to the PKI subsystems.  This should include whether
+   such assessments have taken place and any procedures or plans to
+   perform or repeat/reassess vulnerabilities in the future.>
+
+5.5.  Records Archival [OMITTED]
+
+5.6.  Key Changeover
+
+   The <name of organization> CA certificate will contain a validity
+   period that is at least as long as that of any certificate being
+   issued under that certificate.  When <name of organization> CA
+   changes keys, it will follow the procedures described in [RFC6489].
+
+5.7.  Compromise and Disaster Recovery
+
+   <Describe your plans for dealing with CA key compromise and how you
+   plan to continue/restore operation of your RPKI CA in the event of a
+   disaster.>
+
+5.8.  CA or RA Termination
+
+   <Describe your policy for management of your CA's INR distributions
+   in case of its own termination.>
+
+6.  Technical Security Controls
+
+   This section describes the security controls used by <name of
+   organization>.
+
+6.1.  Key Pair Generation and Installation
+
+6.1.1.  Key Pair Generation
+
+   <Describe the procedures used to generate the CA key pair and, if
+   applicable, key pairs for subscribers.  In most instances, public-key
+   pairs will be generated by the subscriber, i.e., the organization
+   receiving the distribution of INRs.  However, your procedures may
+   include one for generating key pairs on behalf of your subscribers if
+   they so request.>
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 29]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+6.1.2.  Private Key Delivery to Subscriber
+
+   <If the procedures in Section 6.1.1 include providing key pair
+   generation services for subscribers, describe the means by which
+   private keys are delivered to subscribers in a secure fashion.
+   Otherwise, say this is not applicable.>
+
+6.1.3.  Public Key Delivery to Certificate Issuer
+
+   <Describe the procedures that will be used to deliver a subscriber's
+   public keys to the <name of organization> RPKI CA.  These procedures
+   MUST ensure that the public key has not been altered during transit
+   and that the subscriber possesses the private key corresponding to
+   the transferred public key.>  See RFC 6487 for details.
+
+6.1.4.  CA Public Key Delivery to Relying Parties
+
+   CA public keys for all entities (other than trust anchors) are
+   contained in certificates issued by other CAs and will be published
+   to the RPKI repository system.  Relying parties will download these
+   certificates from this system.  Public key values and associated data
+   for (putative) trust anchors will be distributed out of band and
+   accepted by relying parties on the basis of locally defined criteria,
+   e.g., embedded in path validation software that will be made
+   available to the Internet community.
+
+6.1.5.  Key Sizes
+
+   The key sizes used in this PKI are as specified in [RFC6485].
+
+6.1.6.  Public Key Parameter Generation and Quality Checking
+
+   The public key algorithms and parameters used in this PKI are as
+   specified in [RFC6485].
+
+   <If the procedures in Section 6.1.1 include subscriber key pair
+   generation, EITHER insert here text specifying that the subscriber is
+   responsible for performing checks on the quality of its key pair and
+   saying that <name of organization> is not responsible for performing
+   such checks for subscribers OR describe the procedures used by the CA
+   for checking the quality of these subscriber key pairs.>
+
+6.1.7.  Key Usage Purposes (as per X.509 v3 Key Usage Field)
+
+   The KeyUsage extension bit values employed in RPKI certificates are
+   specified in [RFC6487].
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 30]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+6.2.  Private Key Protection and Cryptographic Module Engineering
+      Controls
+
+6.2.1.  Cryptographic Module Standards and Controls
+
+   <Describe the standards and controls employed for the CA
+   cryptographic module, e.g., it was evaluated under FIPS 140-2/3, at
+   level 2 or 3.  See [FIPS] for details.>
+
+6.2.2.  Private Key (n out of m) Multi-Person Control
+
+   <If you choose to use multi-person controls to constrain access to
+   your CA's private keys, then insert the following text.  "There will
+   be private key <insert here n> out of <insert here m> multi-person
+   control.">
+
+6.2.3.  Private Key Escrow
+
+   <No private key escrow procedures are required for the RPKI, but if
+   the CA chooses to employ escrow, state so here.>
+
+6.2.4.  Private Key Backup
+
+   <Describe the procedures used for backing up your CA's private key.
+   The following aspects should be included.  (1) The copying should be
+   done under the same multi-party control as is used for controlling
+   the original private key.  (2) At least one copy should be kept at an
+   off-site location for disaster recovery purposes.>
+
+6.2.5.  Private Key Archival
+
+   See Sections 6.2.3 and 6.2.4.
+
+6.2.6.  Private Key Transfer into or from a Cryptographic Module
+
+   The private key for the <name of organization> production CA <if
+   appropriate, change "production CA" to "production and offline CAs">
+   will be generated by the cryptographic module specified in
+   Section 6.2.1.  The private keys will never leave the module except
+   in encrypted form for backup and/or transfer to a new module.
+
+6.2.7.  Private Key Storage on Cryptographic Module
+
+   The private key for the <name of organization> production CA <if
+   appropriate, change "production CA" to "production and offline CAs">
+   will be stored in the cryptographic module.  It will be protected
+   from unauthorized use <say how here>.
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 31]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+6.2.8.  Method of Activating Private Key
+
+   <Describe the mechanisms and data used to activate your CA's private
+   key.>
+
+6.2.9.  Method of Deactivating Private Key
+
+   <Describe the process and procedure for private key deactivation
+   here.>
+
+6.2.10.  Method of Destroying Private Key
+
+   <Describe the method used for destroying your CA's private key, e.g.,
+   when it is superseded.  This will depend on the particular module.>
+
+6.2.11.  Cryptographic Module Rating
+
+   <Describe the rating of the cryptographic module used by the CA, if
+   applicable.>
+
+6.3.  Other Aspects of Key Pair Management
+
+6.3.1.  Public Key Archival
+
+   <Because this PKI does not support non-repudiation, there is no need
+   to archive public keys.  If keys are not archived, say so.  If they
+   are, describe the archive processes and procedures.>
+
+6.3.2.  Certificate Operational Periods and Key Pair Usage Periods
+
+   The <name of organization> CA's key pair will have a validity
+   interval of <insert number of years>.  <These key pairs and
+   certificates should have reasonably long validity intervals, e.g.,
+   10 years, to minimize the disruption caused by key changeover.  Note
+   that the CA's key lifetime is under the control of its issuer, so the
+   CPS MUST reflect the key lifetime imposed by the issuer.>
+
+6.4.  Activation Data
+
+6.4.1.  Activation Data Generation and Installation
+
+   <Describe how activation data for your CA will be generated.>
+
+6.4.2.  Activation Data Protection
+
+   Activation data for the CA private key will be protected by <describe
+   your procedures here>.
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 32]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+6.4.3.  Other Aspects of Activation Data
+
+   <Add here any details you wish to provide with regard to the
+   activation data for your CA.  If there are none, say "None".>
+
+6.5.  Computer Security Controls
+
+   <Describe your security requirements for the computers used to
+   support this PKI, e.g., requirements for authenticated logins, audit
+   capabilities, etc.  These requirements should be commensurate with
+   those used for the computers used for managing distribution of INRs.>
+
+6.6.  Life Cycle Technical Controls
+
+6.6.1.  System Development Controls
+
+   <Describe any system development controls that apply to the PKI
+   systems, e.g., use of Trusted System Development Methodology (TSDM).>
+
+6.6.2.  Security Management Controls
+
+   <Describe the security management controls that will be used for the
+   RPKI software and equipment employed by the CA.  These security
+   measures should be commensurate with those used for the systems used
+   by the CAs for managing and distributing INRs.>
+
+6.6.3.  Life Cycle Security Controls
+
+   <Describe how the equipment (hardware and software) used for RPKI
+   functions will be procured, installed, maintained, and updated.  This
+   should be done in a fashion commensurate with the way in which
+   equipment for the management and distribution of INRs is handled.>
+
+6.7.  Network Security Controls
+
+   <Describe the network security controls that will be used for CA
+   operation.  These should be commensurate with the network security
+   controls employed for the computers used for managing distribution of
+   INRs.>
+
+6.8.  Time-Stamping
+
+   The RPKI does not make use of time-stamping.
+
+7.  Certificate and CRL Profiles
+
+   See [RFC6487].
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 33]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+8.  Compliance Audit and Other Assessments
+
+   <List here any audit and other assessments used to ensure the
+   security of the administration of INRs.  These are sufficient for the
+   RPKI systems.  However, additional forms of security assessments are
+   a good idea and should be listed if performed.>
+
+9.  Other Business and Legal Matters
+
+   <The sections below are optional.  Fill them in as appropriate for
+   your organization.  The CP says that CAs should cover Sections 9.1
+   to 9.11 and 9.13 to 9.16, although not every CA will choose to do so.
+   Note that the manner in which you manage your business and legal
+   matters for this PKI should be commensurate with the way in which you
+   manage business and legal matters for the distribution of INRs.>
+
+9.1.  Fees
+
+9.1.1.  Certificate Issuance or Renewal Fees
+
+9.1.2.  Certificate Access Fees [OMITTED]
+
+9.1.3.  Revocation or Status Information Access Fees [OMITTED]
+
+9.1.4.  Fees for Other Services (if Applicable)
+
+9.1.5.  Refund Policy
+
+9.2.  Financial Responsibility
+
+9.2.1.  Insurance Coverage
+
+9.2.2.  Other Assets
+
+9.2.3.  Insurance or Warranty Coverage for End-Entities
+
+9.3.  Confidentiality of Business Information
+
+9.3.1.  Scope of Confidential Information
+
+9.3.2.  Information Not within the Scope of Confidential Information
+
+9.3.3.  Responsibility to Protect Confidential Information
+
+9.4.  Privacy of Personal Information
+
+9.4.1.  Privacy Plan
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 34]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+9.4.2.  Information Treated as Private
+
+9.4.3.  Information Not Deemed Private
+
+9.4.4.  Responsibility to Protect Private Information
+
+9.4.5.  Notice and Consent to Use Private Information
+
+9.4.6.  Disclosure Pursuant to Judicial or Administrative Process
+
+9.4.7.  Other Information Disclosure Circumstances
+
+9.5.  Intellectual Property Rights (if Applicable)
+
+9.6.  Representations and Warranties
+
+9.6.1.  CA Representations and Warranties
+
+9.6.2.  Subscriber Representations and Warranties
+
+9.6.3.  Relying Party Representations and Warranties
+
+9.7.  Disclaimers of Warranties
+
+9.8.  Limitations of Liability
+
+9.9.  Indemnities
+
+9.10.  Term and Termination
+
+9.10.1.  Term
+
+9.10.2.  Termination
+
+9.10.3.  Effect of Termination and Survival
+
+9.11.  Individual Notices and Communications with Participants
+
+9.12.  Amendments
+
+9.12.1.  Procedure for Amendment
+
+9.12.2.  Notification Mechanism and Period
+
+9.13.  Dispute Resolution Provisions
+
+9.14.  Governing Law
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 35]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+9.15.  Compliance with Applicable Law
+
+9.16.  Miscellaneous Provisions
+
+9.16.1.  Entire Agreement
+
+9.16.2.  Assignment
+
+9.16.3.  Severability
+
+9.16.4.  Enforcement (Attorneys' Fees and Waiver of Rights)
+
+9.16.5.  Force Majeure
+
+<END TEMPLATE TEXT>
+
+10.  Security Considerations
+
+   The degree to which a relying party can trust the binding embodied in
+   a certificate depends on several factors.  These factors can include
+
+   o  the practices followed by the Certification Authority (CA) in
+      authenticating the subject
+
+   o  the CA's operating policy, procedures, and technical security
+      controls, including the scope of the subscriber's responsibilities
+      (for example, in protecting the private key)
+
+   o  the stated responsibilities and liability terms and conditions of
+      the CA (for example, warranties, disclaimers of warranties, and
+      limitations of liability)
+
+   This document provides a framework to address the technical,
+   procedural, personnel, and physical security aspects of Certification
+   Authorities, Registration Authorities, repositories, subscribers, and
+   relying party cryptographic modules, in order to ensure that the
+   certificate generation, publication, renewal, re-key, usage, and
+   revocation are done in a secure manner.  Specifically, the following
+   sections are oriented towards ensuring the secure operation of the
+   PKI entities such as CA, RA, repository, subscriber systems, and
+   relying party systems:
+
+      Section 3 ("Identification and Authentication" (I&A))
+      Section 4 ("Certificate Life Cycle Operational Requirements")
+      Section 5 ("Facility, Management, and Operational Controls")
+      Section 6 ("Technical Security Controls")
+      Section 7 ("Certificate and CRL Profiles")
+      Section 8 ("Compliance Audit and Other Assessments")
+
+
+
+Kent, et al.              Best Current Practice                [Page 36]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC6484]  Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate
+              Policy (CP) for the Resource Public Key Infrastructure
+              (RPKI)", BCP 173, RFC 6484, February 2012,
+              <http://www.rfc-editor.org/info/rfc6484>.
+
+   [RFC6485]  Huston, G., "The Profile for Algorithms and Key Sizes for
+              Use in the Resource Public Key Infrastructure (RPKI)",
+              RFC 6485, February 2012, <http://www.rfc-editor.org/
+              info/rfc6485>.
+
+   [RFC6487]  Huston, G., Michaelson, G., and R. Loomans, "A Profile for
+              X.509 PKIX Resource Certificates", RFC 6487,
+              February 2012, <http://www.rfc-editor.org/info/rfc6487>.
+
+11.2.  Informative References
+
+   [FIPS]     Federal Information Processing Standards Publication 140-3
+              (FIPS-140-3), "Security Requirements for Cryptographic
+              Modules", Information Technology Laboratory, National
+              Institute of Standards and Technology, Work in Progress.
+
+   [RFC3647]  Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
+              Wu, "Internet X.509 Public Key Infrastructure Certificate
+              Policy and Certification Practices Framework", RFC 3647,
+              November 2003, <http://www.rfc-editor.org/info/rfc3647>.
+
+   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
+              Secure Internet Routing", RFC 6480, February 2012,
+              <http://www.rfc-editor.org/info/rfc6480>.
+
+   [RFC6481]  Huston, G., Loomans, R., and G. Michaelson, "A Profile for
+              Resource Certificate Repository Structure", RFC 6481,
+              February 2012, <http://www.rfc-editor.org/info/rfc6481>.
+
+   [RFC6482]  Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
+              Origin Authorizations (ROAs)", RFC 6482, February 2012,
+              <http://www.rfc-editor.org/info/rfc6482>.
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 37]
+
+RFC 7382                Template CPS for the RPKI             April 2015
+
+
+   [RFC6486]  Austein, R., Huston, G., Kent, S., and M. Lepinski,
+              "Manifests for the Resource Public Key Infrastructure
+              (RPKI)", RFC 6486, February 2012,
+              <http://www.rfc-editor.org/info/rfc6486>.
+
+   [RFC6489]  Huston, G., Michaelson, G., and S. Kent, "Certification
+              Authority (CA) Key Rollover in the Resource Public Key
+              Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012,
+              <http://www.rfc-editor.org/info/rfc6489>.
+
+Acknowledgments
+
+   The authors would like to thank Matt Lepinski for help with the
+   formatting, Ron Watro for assistance with the editing, and other
+   members of the SIDR working group for reviewing this document.
+
+Authors' Addresses
+
+   Stephen Kent
+   BBN Technologies
+   10 Moulton Street
+   Cambridge, MA  02138
+   United States
+
+   Phone: +1 (617) 873-3988
+   EMail: skent@bbn.com
+
+
+   Derrick Kong
+   BBN Technologies
+   10 Moulton Street
+   Cambridge, MA  02138
+   United States
+
+   Phone: +1 (617) 873-1951
+   EMail: dkong@bbn.com
+
+
+   Karen Seo
+   BBN Technologies
+   10 Moulton Street
+   Cambridge, MA  02138
+   United States
+
+   Phone: +1 (617) 873-3152
+   EMail: kseo@bbn.com
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 38]
+
-- 
cgit v1.2.3