RFC 7382
Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)
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.
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
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
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
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
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
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
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].
<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].
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.>
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.)
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.
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.
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
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
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.>
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.>
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.>
(page 18 continued on part 2)
