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