doc: Add RFC documents

1 files changed, 1963 insertions, 0 deletions

diff --git a/doc/rfc/rfc6484.txt b/doc/rfc/rfc6484.txt
new file mode 100644
index 0000000..ea900e6
--- /dev/null
+++ b/doc/rfc/rfc6484.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           S. Kent
+Request for Comments: 6484                                       D. Kong
+BCP: 173                                                          K. Seo
+Category: Best Current Practice                                 R. Watro
+ISSN: 2070-1721                                         BBN Technologies
+                                                           February 2012
+
+
+                      Certificate Policy (CP) for
+             the Resource Public Key Infrastructure (RPKI)
+
+Abstract
+
+   This document describes the certificate policy for a Public Key
+   Infrastructure (PKI) used to support attestations about Internet
+   Number Resource (INR) holdings.  Each organization that distributes
+   IP addresses or Autonomous System (AS) numbers to an organization
+   will, in parallel, issue a (public key) certificate reflecting this
+   distribution.  These certificates will enable verification that the
+   resources indicated in the certificate have been distributed to the
+   holder of the associated private key and that this organization is
+   the current, unique holder of these resources.
+
+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/rfc6484.
+
+Copyright Notice
+
+   Copyright (c) 2012 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
+
+
+
+Kent, et al.              Best Current Practice                 [Page 1]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+   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
+
+   1. Introduction ....................................................6
+      1.1. Overview ...................................................7
+      1.2. Document Name and Identification ...........................7
+      1.3. PKI Participants ...........................................7
+           1.3.1. Certification Authorities ...........................8
+           1.3.2. Registration Authorities ............................8
+           1.3.3. Subscribers .........................................8
+           1.3.4. Relying Parties .....................................8
+           1.3.5. Other Participants ..................................8
+      1.4. Certificate Usage ..........................................9
+           1.4.1. Appropriate Certificate Uses ........................9
+           1.4.2. Prohibited Certificate Uses .........................9
+      1.5. Policy Administration ......................................9
+           1.5.1. Organization Administering the Document .............9
+           1.5.2. Contact Person ......................................9
+           1.5.4. CP Approval Procedures ..............................9
+      1.6. Definitions and Acronyms ..................................10
+   2. Publication and Repository Responsibilities ....................11
+      2.1. Repositories ..............................................11
+      2.2. Publication of Certification Information ..................11
+      2.3. Time or Frequency of Publication ..........................12
+      2.4. Access Controls on Repositories ...........................12
+   3. Identification and Authentication ..............................12
+      3.1. Naming ....................................................12
+           3.1.1. Types of Names .....................................12
+           3.1.2. Need for Names to Be Meaningful ....................12
+           3.1.3. Anonymity or Pseudonymity of Subscribers ...........13
+           3.1.4. Rules for Interpreting Various Name Forms ..........13
+           3.1.5. Uniqueness of Names ................................13
+      3.2. Initial Identity Validation ...............................13
+           3.2.1. Method to Prove Possession of the Private Key ......13
+           3.2.2. Authentication of Organization Identity ............13
+           3.2.3. Authentication of Individual Identity ..............14
+           3.2.4. Non-Verified Subscriber Information ................14
+           3.2.5. Validation of Authority ............................14
+           3.2.6. Criteria for Interoperation ........................14
+      3.3. Identification and Authentication for Re-Key Requests .....14
+           3.3.1. Identification and Authentication for
+                  Routine Re-Key .....................................14
+           3.3.2. Identification and Authentication for
+                  Re-Key after Revocation ............................15
+      3.4. Identification and Authentication for Revocation Request ..15
+
+
+
+Kent, et al.              Best Current Practice                 [Page 2]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+   4. Certificate Life-Cycle Operational Requirements ................16
+      4.1. Certificate Application ...................................16
+           4.1.1. Who Can Submit a Certificate Application ...........16
+           4.1.2. Enrollment Process and Responsibilities ............16
+      4.2. Certificate Application Processing ........................16
+           4.2.1. Performing Identification and
+                  Authentication Functions ...........................16
+           4.2.2. Approval or Rejection of Certificate Applications ..16
+           4.2.3. Time to Process Certificate Applications ...........17
+      4.3. Certificate Issuance ......................................17
+           4.3.1. CA Actions during Certificate Issuance .............17
+           4.3.2. Notification to Subscriber by the CA of
+                  Issuance of Certificate ............................17
+      4.4. Certificate Acceptance ....................................17
+           4.4.1. Conduct Constituting Certificate Acceptance ........17
+           4.4.2. Publication of the Certificate by the CA ...........17
+           4.4.3. Notification of Certificate Issuance by the
+                  CA to Other Entities ...............................17
+      4.5. Key Pair and Certificate Usage ............................18
+           4.5.1. Subscriber Private Key and Certificate Usage .......18
+           4.5.2. Relying Party Public Key and Certificate Usage .....18
+      4.6. Certificate Renewal .......................................18
+           4.6.1. Circumstance for Certificate Renewal ...............19
+           4.6.2. Who May Request Renewal ............................19
+           4.6.3. Processing Certificate Renewal Requests ............19
+           4.6.4. Notification of New Certificate Issuance to
+                  Subscriber .........................................19
+           4.6.5. Conduct Constituting Acceptance of a
+                  Renewal Certificate ................................19
+           4.6.6. Publication of the Renewal Certificate by the CA ...20
+           4.6.7. Notification of Certificate Issuance by the
+                  CA to Other Entities ...............................20
+      4.7. Certificate Re-Key ........................................20
+           4.7.1. Circumstance for Certificate Re-Key ................20
+           4.7.2. Who May Request Certification of a New Public Key ..20
+           4.7.3. Processing Certificate Re-Keying Requests ..........21
+           4.7.4. Notification of New Certificate Issuance to
+                  Subscriber .........................................21
+           4.7.5. Conduct Constituting Acceptance of a
+                  Re-Keyed Certificate ...............................21
+           4.7.6. Publication of the Re-Keyed Certificate by the CA ..21
+           4.7.7. Notification of Certificate Issuance by the
+                  CA to Other Entities ...............................21
+      4.8. Certificate Modification ..................................21
+           4.8.1. Circumstance for Certificate Modification ..........21
+           4.8.2. Who May Request Certificate Modification ...........21
+           4.8.3. Processing Certificate Modification Requests .......22
+
+
+
+
+Kent, et al.              Best Current Practice                 [Page 3]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+           4.8.4. Notification of New Certificate Issuance to
+                  Subscriber .........................................22
+           4.8.5. Conduct Constituting Acceptance of Modified
+                  Certificate ........................................22
+           4.8.6. Publication of the Modified Certificate by the CA ..22
+           4.8.7. Notification of Certificate Issuance by the
+                  CA to Other Entities ...............................22
+      4.9. Certificate Revocation and Suspension .....................22
+           4.9.1. Circumstances for Revocation .......................22
+           4.9.2. Who Can Request Revocation .........................22
+           4.9.3. Procedure for Revocation Request ...................23
+           4.9.4. Revocation Request Grace Period ....................23
+           4.9.5. Time within which CA Must Process the
+                  Revocation Request .................................23
+           4.9.6. Revocation Checking Requirement for Relying
+                  Parties ............................................23
+           4.9.7. CRL Issuance Frequency .............................23
+           4.9.8. Maximum Latency for CRLs ...........................23
+      4.10. Certificate Status Services ..............................24
+   5. Facility, Management, and Operational Controls .................24
+      5.1. Physical Controls .........................................24
+           5.1.1. Site Location and Construction .....................24
+           5.1.2. Physical Access ....................................24
+           5.1.3. Power and Air Conditioning .........................24
+           5.1.4. Water Exposures ....................................24
+           5.1.5. Fire Prevention and Protection .....................24
+           5.1.6. Media Storage ......................................24
+           5.1.7. Waste Disposal .....................................24
+           5.1.8. Off-Site Backup ....................................24
+      5.2. Procedural Controls .......................................24
+           5.2.1. Trusted Roles ......................................25
+           5.2.2. Number of Persons Required per Task ................25
+           5.2.3. Identification and Authentication for Each Role ....25
+           5.2.4. Roles Requiring Separation of Duties ...............25
+      5.3. Personnel Controls ........................................25
+      5.4. Audit Logging Procedures ..................................25
+           5.4.1. Types of Events Recorded ...........................25
+           5.4.2. Frequency of Processing Log ........................25
+           5.4.3. Retention Period for Audit Log .....................26
+           5.4.4. Protection of Audit Log ............................26
+           5.4.5. Audit Log Backup Procedures ........................26
+           5.4.8. Vulnerability Assessments ..........................26
+      5.6. Key Changeover ............................................26
+      5.7. CA or RA Termination ......................................26
+   6. Technical Security Controls ....................................26
+      6.1. Key Pair Generation and Installation ......................27
+           6.1.1. Key Pair Generation ................................27
+           6.1.2. Private Key Delivery to Subscriber .................27
+
+
+
+Kent, et al.              Best Current Practice                 [Page 4]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+           6.1.3. Public Key Delivery to Certificate Issuer ..........27
+           6.1.4. CA Public Key Delivery to Relying Parties ..........27
+           6.1.5. Key Sizes ..........................................27
+           6.1.6. Public Key Parameters Generation and
+                  Quality Checking ...................................28
+           6.1.7. Key Usage Purposes (as per X.509 v3 Key
+                  Usage Field) .......................................28
+      6.2. Private Key Protection and Cryptographic Module
+           Engineering Controls ......................................28
+           6.2.1. Cryptographic Module Standards and Controls ........28
+           6.2.2. Private Key (N out of M) Multi-Person Control ......28
+           6.2.3. Private Key Escrow .................................28
+           6.2.4. Private Key Backup .................................28
+           6.2.5. Private Key Archival ...............................28
+           6.2.6. Private Key Transfer into or from a
+                  Cryptographic Module ...............................29
+           6.2.7. Private Key Storage on Cryptographic Module ........29
+           6.2.8. Method of Activating a Private Key .................29
+           6.2.9. Method of Deactivating a Private Key ...............29
+           6.2.10. Method of Destroying a Private Key ................29
+           6.2.11. Cryptographic Module Rating .......................29
+      6.3. Other Aspects of Key Pair Management ......................29
+           6.3.1. Public Key Archival ................................29
+           6.3.2. Certificate Operational Periods and Key
+                  Pair Usage Periods .................................29
+      6.4. Activation Data ...........................................30
+      6.5. Computer Security Controls ................................30
+      6.6. Life-Cycle Technical Controls .............................30
+           6.6.1. System Development Controls ........................30
+           6.6.2. Security Management Controls .......................30
+           6.6.3. Life-Cycle Security Controls .......................30
+      6.7. Network Security Controls .................................30
+      6.8. Timestamping ..............................................30
+   7. Certificate and CRL Profiles ...................................31
+   8. Compliance Audit and Other Assessments .........................31
+   9. Other Business and Legal Matters ...............................31
+      9.12.  Amendments ..............................................31
+           9.12.1. Procedure for Amendment ...........................31
+           9.12.2. Notification Mechanism and Period .................31
+           9.12.3. Circumstances under Which OID Must Be Changed .....32
+   10. Security Considerations .......................................32
+   11. Acknowledgments ...............................................33
+   12. References ....................................................33
+      12.1. Normative References .....................................33
+      12.2. Informative References ...................................33
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                 [Page 5]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+1.  Introduction
+
+   This document describes the certificate policy for a Public Key
+   Infrastructure (PKI) used to attest to Internet Number Resource (INR)
+   holdings (IP addresses or Autonomous System (AS) numbers).  An
+   organization that distributes INRs to another organization MAY, in
+   parallel, issue a (public key) certificate reflecting this
+   distribution.  These certificates will enable verification that the
+   resources indicated in the certificate have been distributed to the
+   holder of the associated private key and that this organization is
+   the current holder of these resources.
+
+   The most important and distinguishing aspect of the PKI for which
+   this policy was created is that it does not purport to identify an
+   INR holder via the subject name contained in the certificate issued
+   to that entity.  Rather, each certificate issued under this policy is
+   intended to enable an entity to assert, in a verifiable fashion, that
+   it is the current holder of an INR based on the current records of
+   the entity responsible for the resources in question.  Verification
+   of the assertion is based on two criteria: the ability of the entity
+   to digitally sign data that is verifiable using the public key
+   contained in the corresponding certificate, and validation of that
+   certificate in the context of this PKI.
+
+   This PKI is designed exclusively for use in support of validation of
+   claims related to current INR holdings.  This includes any
+   certificates issued in support of operation of this infrastructure,
+   e.g., for integrity or access control of the repository system
+   described in Section 2.4.  Such transitive uses of certificates also
+   are permitted under this policy.  Use of the certificates and
+   Certificate Revocation Lists (CRLs) managed under this PKI for any
+   other purpose is a violation of this CP, and relying parties (RPs)
+   SHOULD reject certificates presented for such uses.
+
+   Note: This document is based on the template specified in RFC 3647
+   [RFC3647], a product of the Internet Engineering Task Force (IETF)
+   stream.  In the interest of keeping the document as short as
+   reasonable, a number of sections contained in the template have been
+   omitted from this policy because they do not apply to this PKI.
+   However, we have retained the section numbering scheme employed in
+   RFC 3647 to facilitate comparison with the outline in Section 6 of
+   RFC 3647.  Each of these omitted sections should be read as "No
+   stipulation" in Certificate Policy (CP) / Certification Practice
+   Statement (CPS) parlance.
+
+   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 RFC 2119 [RFC2119].
+
+
+
+Kent, et al.              Best Current Practice                 [Page 6]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+1.1.  Overview
+
+   This PKI is designed to support validation of claims by current
+   holders of INRs, in accordance with the records of the organizations
+   that act as Certification Authorities (CAs) in this PKI.  The ability
+   to verify such claims is essential to ensuring the unambiguous
+   distribution of these resources [RFC6480].
+
+   The structure of the RPKI is congruent with the number resource
+   allocation framework of the Internet.  The IANA allocates number
+   resources to Regional Internet Registries (RIRs), to others, and for
+   special purposes [RFC5736].  The RIRs, in turn, manage the allocation
+   of number resources to end users, Internet Service Providers, and
+   others.
+
+   This PKI encompasses several types of certificates (see [RFC6487] for
+   more details):
+
+   o  CA certificates for each organization distributing INRs and for
+      INR holders
+
+   o  End-entity (EE) certificates for organizations to validate digital
+      signatures on RPKI signed objects
+
+1.2.  Document Name and Identification
+
+   The name of this document is "Certificate Policy (CP) for the
+   Resource PKI (RPKI)".
+
+   This policy has been assigned the following OID:
+
+   id-cp-ipAddr-asNumber OBJECT IDENTIFIER ::= { iso(1)
+
+                         identified-organization(3) dod(6) internet(1)
+
+                         security(5) mechanisms(5) pkix(7) cp(14) 2 }
+
+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.
+
+
+
+Kent, et al.              Best Current Practice                 [Page 7]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+1.3.1.  Certification Authorities
+
+   The organizations that distribute IP addresses and AS numbers (IANA,
+   RIRs, NIRs, ISPs) act as CAs in this PKI.
+
+   Organizations that do not distribute INRs but hold such resources
+   also act as CAs when they create EE certificates.
+
+1.3.2.  Registration Authorities
+
+   This PKI does not require establishment or use of a registration
+   authority (RA) function separate from the one provided inherently in
+   conjunction with 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 entities (the CAs) already perform the RA function
+   implicitly since they already assume responsibility for distributing
+   INRs.
+
+1.3.3.  Subscribers
+
+   These are the organizations receiving distributions of INRs: RIRs,
+   NIRs, ISPs, and other organizations.
+
+   Note that any of these organizations may have received distributions
+   from more than one source over time.  This is true even for RIRs,
+   which participate in inter-registry exchanges of address space.  This
+   PKI accommodates such relationships.
+
+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
+
+   Every organization that undertakes a role as a CA in this PKI is
+   responsible for populating the RPKI distributed repository system
+   with the certificates, CRLs, and RPKI signed objects that it issues.
+   The organization MAY operate its own publication point, or it MAY
+   outsource this function (see Sections 2.1 and 2.2).
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                 [Page 8]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+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, also are permitted under this policy.  For example,
+   certificates may be issued in support of integrity and access control
+   for the repository system described in Section 2.4.  Such transitive
+   uses are permitted under this policy.
+
+1.4.2.  Prohibited Certificate Uses
+
+   Any uses other than those described in Section 1.4.1 are prohibited
+   under this policy.
+
+1.5.  Policy Administration
+
+1.5.1.  Organization Administering the Document
+
+   This CP is administered by
+
+   Internet Engineering Steering Group
+   c/o Internet Society
+   1775 Wiehle Avenue, Suite 201
+   Reston, VA 20190-5108
+   U.S.A.
+
+1.5.2.  Contact Person
+
+   The contact information is
+
+   EMail: iesg@ietf.org
+   Phone: +1-703-439-2120 (Internet Society)
+
+1.5.4.  CP Approval Procedures
+
+   If a replacement BCP is needed that updates or obsoletes the current
+   BCP, then the replacement BCP MUST be approved by the IESG following
+   the procedures of the IETF Standards Process as defined in RFC 2026
+   [RFC2026].
+
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                 [Page 9]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+1.6.  Definitions and Acronyms
+
+   CPS -  Certification Practice Statement.  A CPS is a document that
+          specifies the practices that a Certification Authority (CA)
+          employs in issuing certificates in this PKI.
+
+   Distribution of INRs - A process of distribution of the INRs along
+          the respective number hierarchy.  IANA distributes blocks of
+          IP addresses and AS numbers to the five Regional Internet
+          Registries (RIRs).  RIRs distribute smaller address blocks and
+          AS 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 IP addressing system and AS numbers
+          used for routing Internet traffic.  IANA distributes INRs to
+          Regional Internet Registries (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 AS numbers.
+
+   ISP -  Internet Service Provider.  This is an organization managing
+          and providing Internet services to other organizations.
+
+   LIR -  Local Internet Registry.  In some regions, this term is used
+          to refer to what is called an ISP in other regions.
+
+   NIR -  National Internet Registry.  This is an organization that
+          manages the distribution of INRs for a portion of the
+          geopolitical area covered by a Regional Registry.  NIRs form
+          an optional second tier in the tree scheme used to manage
+          INRs.
+
+   RIR -  Regional Internet Registry.  This is an organization that
+          manages the distribution of INRs for a geopolitical area.
+
+
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 10]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+   RPKI signed object - An RPKI signed object is a digitally signed data
+          object (other than a certificate or CRL) that is declared to
+          be such by a Standards Track RFC, and that 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
+
+   Certificates, CRLs, and RPKI signed objects (intended for public
+   consumption) MUST be made available for downloading by all relying
+   parties, to enable them to validate this data.  This motivates use of
+   a robust, distributed repository system.  Each CA MUST maintain a
+   publicly accessible online repository and publish all RPKI-signed
+   objects (intended for public consumption) via this repository in a
+   manner that conforms with "A Profile for Resource Certificate
+   Repository Structure" [RFC6481].  (This function MAY be outsourced,
+   as noted in Section 2.2 below.)  The collection of repositories forms
+   the RPKI distributed repository system.
+
+2.2.  Publication of Certification Information
+
+   Each CA MUST publish the certificates (intended for public
+   consumption) that it issues via the repository system.
+
+   Each CA MUST publish the CRLs (intended for public consumption) that
+   it issues via the repository system.
+
+   Each CA MUST publish its RPKI signed objects (intended for public
+   consumption) via the repository system.
+
+   Each CA that issues certificates to entities outside of its
+   administrative domain SHOULD create and publish a CPS that meets the
+   requirements set forth in this CP.  Publication means that the
+   entities to which the CA issues certificates MUST be able to acquire
+   a copy of the CPS, and MUST be able to ascertain when the CPS
+   changes.  (An organization that does not allocate or assign INRs does
+   not need to create or publish a CPS.)
+
+   An organization MAY choose to outsource publication of RPKI data --
+   certificates, CRLs, and other RPKI signed objects.
+
+   The CP will be published as an IETF-stream RFC and will be available
+   from the RFC repository.
+
+
+
+Kent, et al.              Best Current Practice                [Page 11]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+2.3.  Time or Frequency of Publication
+
+   The CPS for each CA MUST specify the following information:
+
+   The period of time within which a certificate will be published after
+   the CA issues the certificate.
+
+   The period of time within which a CA will publish a CRL with an entry
+   for a revoked certificate after it revokes that certificate.
+
+   Expired and revoked certificates SHOULD be removed from the RPKI
+   repository system, upon expiration or revocation, respectively.
+   Also, please note that each CA MUST publish its CRL prior to the
+   nextUpdate value in the scheduled CRL previously issued by the CA.
+
+2.4.  Access Controls on Repositories
+
+   Each CA or repository operator MUST implement access controls to
+   prevent unauthorized persons from adding, modifying, or deleting
+   repository entries.  A CA or repository operator MUST NOT
+   intentionally use technical means of limiting read access to its CPS,
+   certificates, CRLs, or RPKI signed objects.  This data is intended to
+   be accessible to the public.
+
+3.  Identification and Authentication
+
+3.1.  Naming
+
+3.1.1.  Types of Names
+
+   The distinguished name for every CA and end-entity consists of a
+   single CommonName (CN) attribute with a value generated by the issuer
+   of the certificate.  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",
+   i.e., the name is not intended to convey the identity of the subject
+   to relying parties.  The rationale here is that certificates issued
+   under this PKI are used for authorization in support of applications
+   that make use of attestations of INR holdings.  They are not used to
+   identify subjects.
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 12]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+3.1.3.  Anonymity or Pseudonymity of Subscribers
+
+   Although subject (and issuer) names need 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
+
+   There is no guarantee that subject names are globally unique in this
+   PKI.  Each CA certifies subject names that MUST be unique among the
+   certificates it issues.  Although it is desirable that these subject
+   names be unique throughout the PKI, name uniqueness within the RPKI
+   cannot be guaranteed.
+
+   However, subject names in certificates SHOULD be constructed in a way
+   that minimizes the chances that two entities in the RPKI will be
+   assigned the same name.  The RPKI Certificate Profile [RFC6487]
+   provides an example of how to generate (meaningless) subject names in
+   a way that minimizes the likelihood of collisions.
+
+3.2.  Initial Identity Validation
+
+3.2.1.  Method to Prove Possession of the Private Key
+
+   Each CA operating within the context of this PKI MUST require each
+   subject to demonstrate proof of possession (PoP) of the private key
+   corresponding to the public key in the certificate, prior to issuing
+   the certificate.  The means by which PoP is achieved is determined by
+   each CA and MUST be declared in the CPS of that CA.
+
+3.2.2.  Authentication of Organization Identity
+
+   Each CA operating within the context of this PKI MUST employ
+   procedures to ensure that each certificate it issues accurately
+   reflects its records with regard to the organization to which the CA
+   has distributed the INRs identified in the certificate.  The specific
+   procedures employed for this purpose MUST be described by the CPS for
+   each CA.  Relying parties can expect each CA to employ procedures
+   commensurate with those it already employs as a registry or ISP in
+   the management of the INRs.  This authentication is solely for use by
+   each CA in dealing with the organizations to which it distributes
+   INRs, and thus should not be relied upon outside of this
+   CA-subscriber relationship.
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 13]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+3.2.3.  Authentication of Individual Identity
+
+   Each CA operating within the context of this PKI MUST employ
+   procedures to identify at least one individual as a representative of
+   each organization that is an INR holder.  The specific means by which
+   each CA authenticates individuals as representatives for an
+   organization MUST be described by the CPS for each CA.  Relying
+   parties can expect each CA to employ procedures commensurate with
+   those it already employs as a registry or ISP in authenticating
+   individuals as representatives for INR holders.
+
+3.2.4.  Non-Verified Subscriber Information
+
+   A CA MUST NOT include any non-verified subscriber data in
+   certificates issued under this certificate policy except for Subject
+   Information Access (SIA) extensions.
+
+3.2.5.  Validation of Authority
+
+   Each CA operating within the context of this PKI MUST employ
+   procedures to verify that an individual claiming to represent an
+   organization to which a certificate is issued is authorized to
+   represent that organization in this context.  The procedures MUST be
+   described by the CPS for the CA.  Relying parties can expect each CA
+   to employ procedures commensurate with those it already employs as a
+   registry or ISP, in authenticating individuals as representatives for
+   INR holders.
+
+3.2.6.  Criteria for Interoperation
+
+   This PKI is neither intended nor designed to interoperate with any
+   other PKI.
+
+3.3.  Identification and Authentication for Re-Key Requests
+
+3.3.1.  Identification and Authentication for Routine Re-Key
+
+   Each CA operating within the context of this PKI MUST employ
+   procedures to ensure that an organization requesting a re-key is the
+   legitimate holder of the certificate to be re-keyed and the
+   associated INRs, and MUST require PoP of the private key
+   corresponding to the new public key.  The procedures employed for
+   these purposes MUST be described in the CPS for the CA.  With respect
+   to authentication of the holder of the INRs, relying parties can
+   expect each CA to employ procedures commensurate with those it
+   already employs as a registry or ISP, in the management of INRs.
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 14]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+   Note: An issuer MAY choose to require periodic re-keying consistent
+   with contractual agreements with the recipient.  If so, this MUST be
+   described by the CPS for the CA.
+
+3.3.2.  Identification and Authentication for Re-Key after Revocation
+
+   Each CA operating within the context of this PKI MUST employ
+   procedures to ensure that an organization requesting a re-key after
+   revocation is the same entity to which the revoked certificate was
+   issued and is the legitimate holder of the associated INR.  The CA
+   MUST require PoP of the private key corresponding to the new public
+   key.  The specific procedures employed for these purposes MUST be
+   described by the CPS for the CA.  With respect to authentication of
+   the holder of the INRs, relying parties can expect each CA to employ
+   procedures commensurate with those it already employs as a registry
+   or ISP, in the management of INRs.  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.
+
+3.4.  Identification and Authentication for Revocation Request
+
+   Each CA operating within the context of this PKI MUST employ
+   procedures to ensure that:
+
+   o  an organization requesting revocation is the legitimate holder of
+      the certificate to be revoked.
+
+   o  each certificate it revokes accurately reflects its records with
+      regard to the organization to which the CA has distributed the
+      INRs identified in the certificate.
+
+   o  an individual claiming to represent an organization for which a
+      certificate is to be revoked is authorized to represent that
+      organization in this context.
+
+   The specific procedures employed for these purposes MUST be described
+   by the CPS for the CA.  Relying parties can expect each CA to employ
+   procedures commensurate with those it already employs as a registry
+   or ISP, in the management of INRs.
+
+
+
+
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 15]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+4.  Certificate Life-Cycle Operational Requirements
+
+4.1.  Certificate Application
+
+4.1.1.  Who Can Submit a Certificate Application
+
+   Any entity that distributes INRs SHOULD acquire a certificate.  This
+   includes Internet Registries and ISPs.  Additionally, entities that
+   hold INRs from an Internet Registry, or that are multi-homed, MAY
+   acquire a certificate under this PKI.  The (CA) certificates issued
+   to these entities MUST include one or both of the extensions defined
+   by RFC 3779 [RFC3779], "X.509 Extensions for IP Addresses and AS
+   Identifiers", as appropriate.
+
+   The application procedure MUST be described in the CPS for each CA.
+
+4.1.2.  Enrollment Process and Responsibilities
+
+   The enrollment process and procedures MUST be described by the CPS
+   for each CA.  An entity that desires one or more certificates should
+   contact the organization from which it receives its INRs.
+
+4.2.  Certificate Application Processing
+
+   CAs SHOULD make use of existing standards for certificate application
+   processing.  Section 6 of the Resource Certificate Profile [RFC6487]
+   defines the standard certificate request formats that MUST be
+   supported.
+
+   Each CA MUST define via its CPS, the certificate request/response
+   standards that it employs.
+
+4.2.1.  Performing Identification and Authentication Functions
+
+   Existing practices employed by registries and ISPs to identify and
+   authenticate organizations that receive INRs form the basis for
+   issuance of certificates to these subscribers.  It is important to
+   note that the Resource PKI SHOULD NOT be used to authenticate the
+   identity of an organization, but rather to bind subscribers to the
+   INRs they hold.  Because identity is not being vouched for by this
+   PKI, certificate application procedures need not verify legal
+   organization names, etc.
+
+4.2.2.  Approval or Rejection of Certificate Applications
+
+   Certificate applications MUST be approved based on the normal
+   business practices of the entity operating the CA, based on the CA's
+   records of INR holders.  Each CA MUST follow the procedures specified
+
+
+
+Kent, et al.              Best Current Practice                [Page 16]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+   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.  The details of how certificate
+   applications are approved MUST be described in the CPS for the CA in
+   question.
+
+4.2.3.  Time to Process Certificate Applications
+
+   No stipulation.  As part of its CPS, each CA MUST declare its
+   expected time frame to process (approve, issue, and publish) a
+   certificate application.
+
+4.3.  Certificate Issuance
+
+4.3.1.  CA Actions during Certificate Issuance
+
+   If a CA determines that the request is acceptable, it MUST issue the
+   corresponding certificate and publish it in the RPKI distributed
+   repository system via publication of the certificate at the CA's
+   repository publication point.
+
+4.3.2.  Notification to Subscriber by the CA of Issuance of Certificate
+
+   The CA MUST notify the subscriber when the certificate is published.
+   The means by which a subscriber is notified MUST be defined by each
+   CA in its CPS.
+
+4.4.  Certificate Acceptance
+
+4.4.1.  Conduct Constituting Certificate Acceptance
+
+   Within the timeframe specified in its CPS, the CA MUST place the
+   certificate in the repository and notify the subscriber.  This MAY be
+   done without subscriber review and acceptance.  Each CA MUST state in
+   its CPS the procedures it follows for publishing of the certificate
+   and notification to the subscriber.
+
+4.4.2.  Publication of the Certificate by the CA
+
+   Certificates MUST be published in the RPKI distributed repository
+   system via publication of the certificate at the CA's repository
+   publication point as per the conduct described in Section 4.4.1.  The
+   procedures for publication MUST be defined by each CA in its CPS.
+
+4.4.3.  Notification of Certificate Issuance by the CA to Other Entities
+
+   The CPS of each CA MUST indicate whether any other entities will be
+   notified when a certificate is issued.
+
+
+
+Kent, et al.              Best Current Practice                [Page 17]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+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
+
+   Each holder of an INR is eligible to request an X.509 [X.509] CA
+   certificate containing appropriate RFC 3779 extensions.  Holders of
+   CA resource certificates also MAY issue EE certificates to themselves
+   to enable verification of RPKI signed objects that they generate.
+
+4.5.2.  Relying Party Public Key and Certificate Usage
+
+   Reliance on a certificate must be reasonable under the circumstances.
+   If the circumstances indicate a need for additional assurances, the
+   relying party must obtain such assurances in order for such reliance
+   to be deemed reasonable.
+
+   Before any act of reliance, relying parties MUST independently (1)
+   verify that the certificate will be used for an appropriate purpose
+   that is not prohibited or otherwise restricted by this CP (see
+   Section 1.4), and (2) assess the status of the certificate and all
+   the certificates in the chain (terminating at a trust anchor (TA)
+   accepted by the RP) that issued the certificates relevant to the
+   certificate in question.  If any of the certificates in the
+   certificate chain have been revoked or have expired, the relying
+   party is solely responsible for determining whether reliance on a
+   digital signature to be verified by the certificate in question is
+   acceptable.  Any such reliance is made solely at the risk of the
+   relying party.
+
+   If a relying party determines that use of the certificate is
+   appropriate, the relying party must utilize appropriate software
+   and/or hardware to perform digital signature verification as a
+   condition of relying on the certificate.  Moreover, the relying party
+   MUST validate the certificate in a manner consistent with the RPKI
+   Certificate Profile [RFC6487], which specifies the extended
+   validation algorithm for RPKI certificates.
+
+4.6.  Certificate Renewal
+
+   This section describes the procedures for certificate renewal.
+   Certificate renewal is the issuance of a new certificate to replace
+   an old one prior to its expiration.  Only the validity dates and the
+   serial number (the field in the certificate, not the DN attribute)
+   are changed.  The public key and all other information remain the
+   same.
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 18]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+4.6.1.  Circumstance for Certificate Renewal
+
+   A certificate MUST be processed for renewal based on its expiration
+   date or a renewal request from the subscriber.  Prior to the
+   expiration of an existing subscriber's certificate, it is the
+   responsibility of the subscriber to renew the certificate to maintain
+   continuity of certificate usage.  If the issuing CA initiates the
+   renewal process based on the certificate expiration date, then that
+   CA MUST notify the holder in advance of the renewal process.  The
+   validity interval of the new (renewed) certificate SHOULD overlap
+   that of the previous certificate to ensure continuity of certificate
+   usage.  It is RECOMMENDED that the renewed certificate be issued and
+   published at least 1 week prior to the expiration of the certificate
+   it replaces.
+
+   Certificate renewal SHOULD incorporate the same public key as the
+   previous certificate, unless the private key has been reported as
+   compromised.  If a new key pair is being used, the stipulations of
+   Section 4.7 apply.
+
+4.6.2.  Who May Request Renewal
+
+   Only the certificate holder or the issuing CA may initiate the
+   renewal process.  The certificate holder MAY request an early
+   renewal, for example, if it expects to be unavailable to support the
+   renewal process during the normal expiration period.  An issuing CA
+   MAY initiate the renewal process based on the certificate expiration
+   date.
+
+4.6.3.  Processing Certificate Renewal Requests
+
+   Renewal procedures MUST ensure that the person or organization
+   seeking to renew a certificate is in fact the subscriber (or
+   authorized by the subscriber) of the certificate and the legitimate
+   holder of the INR associated with the renewed certificate.  Renewal
+   processing MUST verify that the certificate in question has not been
+   revoked.
+
+4.6.4.  Notification of New Certificate Issuance to Subscriber
+
+   No additional stipulations beyond those of Section 4.3.2.
+
+4.6.5.  Conduct Constituting Acceptance of a Renewal Certificate
+
+   No additional stipulations beyond those of Section 4.4.1.
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 19]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+4.6.6.  Publication of the Renewal Certificate by the CA
+
+   No additional stipulations beyond those of Section 4.4.2.
+
+4.6.7.  Notification of Certificate Issuance by the CA to Other Entities
+
+   No additional stipulations beyond those of Section 4.4.3.
+
+4.7.  Certificate Re-Key
+
+   This section describes the procedures for certificate re-key.
+   Certificate re-key is the issuance of a new certificate to replace an
+   old one because the key needs to be replaced.  Unlike with
+   certificate renewal, the public key is changed.
+
+4.7.1.  Circumstance for Certificate Re-Key
+
+   Re-key of a certificate SHOULD 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
+
+   A CA re-key operation has dramatic consequences, requiring the
+   reissuance of all certificates issued by the re-keyed entity.  So it
+   should be performed only when necessary and in a way that preserves
+   the ability of relying parties to validate certificates whose
+   validation path includes the re-keyed entity.  CA key rollover MUST
+   follow the procedures defined in "CA Key Rollover in the RPKI"
+   [RFC6489].
+
+   Note that if a certificate is revoked to replace the RFC 3779
+   extensions, the replacement certificate MUST incorporate the same
+   public key rather than a new key.  This applies when one is adding
+   INRs (revocation not required) and when one is removing INRs
+   (revocation required (see Section 4.8.1)).
+
+   If the re-key is based on a suspected compromise, then the previous
+   certificate MUST be revoked.
+
+4.7.2.  Who May Request Certification of a New Public Key
+
+   The holder of the certificate may request a re-key.  In addition, the
+   CA that issued the certificate MAY choose to initiate a re-key based
+   on a verified compromise report.
+
+
+
+Kent, et al.              Best Current Practice                [Page 20]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+4.7.3.  Processing Certificate Re-Keying Requests
+
+   The re-key process follows the general procedures of certificate
+   generation as defined in Section 4.3.
+
+4.7.4.  Notification of New Certificate Issuance to Subscriber
+
+   No additional stipulations beyond those of Section 4.3.2.
+
+4.7.5.  Conduct Constituting Acceptance of a Re-Keyed Certificate
+
+   No additional stipulations beyond those of Section 4.4.1.
+
+4.7.6.  Publication of the Re-Keyed Certificate by the CA
+
+   No additional stipulations beyond those of Section 4.4.2.
+
+4.7.7.  Notification of Certificate Issuance by the CA to Other Entities
+
+   No additional stipulations beyond those of Section 4.4.3.
+
+4.8.  Certificate Modification
+
+4.8.1.  Circumstance for Certificate Modification
+
+   Modification of a certificate occurs to implement changes to selected
+   attribute values in a certificate.  In the context of the RPKI, the
+   only changes that are accommodated by certificate modification are
+   changes to the INR holdings described by the RFC 3779 extension(s)
+   and changes to the SIA extension.
+
+   When a certificate modification is approved, a new certificate is
+   issued.  If no INR holdings are removed from the certificate, the new
+   certificate MUST contain the same public key and the same expiration
+   date as the original certificate, but with the SIA extension and/or
+   the INR set expanded.  In this case, revocation of the previous
+   certificate is not required.
+
+   When previously distributed INRs are removed from a certificate, then
+   the old certificate MUST be revoked and a new certificate MUST be
+   issued, reflecting the changed INR holdings.  (The SIA extension in
+   the new certificate will be unchanged, unless the affected INR holder
+   supplies a new SIA value.)
+
+4.8.2.  Who May Request Certificate Modification
+
+   Either the certificate holder or the issuer may initiate the
+   certificate modification process.
+
+
+
+Kent, et al.              Best Current Practice                [Page 21]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+4.8.3.  Processing Certificate Modification Requests
+
+   The CA MUST determine that the requested modification is appropriate
+   and that the procedures for the issuance of a new certificate are
+   followed (see Section 4.3).
+
+4.8.4.  Notification of New Certificate Issuance to Subscriber
+
+   No additional stipulations beyond those of Section 4.3.2.
+
+4.8.5.  Conduct Constituting Acceptance of Modified Certificate
+
+   No additional stipulations beyond those of Section 4.4.1.
+
+4.8.6.  Publication of the Modified Certificate by the CA
+
+   No additional stipulations beyond those of Section 4.4.2.
+
+4.8.7.  Notification of Certificate Issuance by the CA to Other Entities
+
+   No additional stipulations beyond those of Section 4.4.3.
+
+4.9.  Certificate Revocation and Suspension
+
+4.9.1.  Circumstances for Revocation
+
+   A certificate MUST be revoked (and published on a CRL) if there is
+   reason to believe that there has been a compromise of a subscriber's
+   private key.  A certificate also MAY be revoked to invalidate a data
+   object signed by the private key associated with that certificate.
+   Other circumstances that justify revocation of a certificate MAY be
+   specified in a CA's CPS.
+
+   Note:  If new INRs are being added to an organization's existing
+   distribution, the old certificate need not be revoked.  Instead, a
+   new certificate MAY be issued with both the old and the new resources
+   and the old key.  If INRs are being removed or if there has been a
+   key compromise, then the old certificate MUST be revoked (and a
+   re-key MUST be performed in the event of key compromise).
+
+4.9.2.  Who Can Request Revocation
+
+   This MUST be defined in the CPS of the organization that issued the
+   certificate.
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 22]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+4.9.3.  Procedure for Revocation Request
+
+   A subscriber MAY submit a request to the certificate issuer for a
+   revocation.  This request MUST identify the certificate to be revoked
+   and MUST be authenticated.  The procedures for making the request
+   MUST be described in the CPS for each CA.  The RPKI provisioning
+   document [RFC6492] describes a protocol that MAY be used to make
+   revocation requests.
+
+   A certificate issuer MUST notify the subscriber when revoking a
+   certificate.  The notification requirement is satisfied by CRL
+   publication.  The CPS for a CA MUST indicate the means by which the
+   CA will inform a subscriber of certificate revocation.
+
+4.9.4.  Revocation Request Grace Period
+
+   A subscriber SHOULD request revocation as soon as possible after the
+   need for revocation has been identified.  There is no specified grace
+   period for the subscriber in this process.
+
+4.9.5.  Time within which CA Must Process the Revocation Request
+
+   No stipulation.  Each CA SHOULD specify its expected revocation
+   processing time in its CPS.
+
+4.9.6.  Revocation Checking Requirement for Relying Parties
+
+   A relying party MUST acquire and check the most recent, scheduled CRL
+   from the issuer of the certificate, whenever the relying party
+   validates a certificate.
+
+4.9.7.  CRL Issuance Frequency
+
+   The CRL issuance frequency MUST be determined by each CA and stated
+   in its CPS.  Each CRL carries a nextScheduledUpdate value, and a new
+   CRL MUST be published at or before that time.  A CA MUST 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
+
+   The CPS for each CA MUST specify the maximum latency associated with
+   posting its CRL to the repository system.
+
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 23]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+4.10.  Certificate Status Services
+
+   This PKI does not make provision for use of the Online Certificate
+   Status Protocol (OCSP) [RFC2560] or Server-Based Certificate
+   Validation Protocol (SCVP) [RFC5055].  This is because it is
+   anticipated that the primary RPs (ISPs) will acquire and validate
+   certificates for all participating resource holders.  These protocols
+   are not designed for such large-scale, bulk certificate status
+   checking.  RPs MUST check for new CRLs at least daily.  It is
+   RECOMMENDED that RPs perform this check several times per day, but no
+   more than 8-12 times per day (to avoid excessive repository
+   accesses).
+
+5.  Facility, Management, and Operational Controls
+
+5.1.  Physical Controls
+
+   Each CA MUST maintain physical security controls for its operation
+   that are commensurate with those employed by the organization in the
+   management of INR distribution.  The physical controls employed for
+   CA operation MUST be specified in its CPS.  Possible topics to be
+   covered in the CPS are shown below.  (These sections are taken from
+   [RFC3647].)
+
+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
+
+5.2.  Procedural Controls
+
+   Each CA MUST maintain procedural security controls that are
+   commensurate with those employed by the organization in the
+   management of INR distribution.  The procedural security controls
+   employed for CA operation MUST be specified in its CPS.  Possible
+   topics to be covered in the CPS are shown below.  (These sections are
+   taken from [RFC3647].)
+
+
+
+Kent, et al.              Best Current Practice                [Page 24]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+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
+
+   Each CA MUST maintain personnel security controls that are
+   commensurate with those employed by the organization in the
+   management of INR distribution.  The details for each CA MUST be
+   specified in its CPS.
+
+5.4.  Audit Logging Procedures
+
+   Details of how a CA implements the audit logging described in
+   Sections 5.4.1 to 5.4.8 MUST be addressed in its CPS.
+
+5.4.1.  Types of Events Recorded
+
+   Audit records MUST be generated for the basic operations of the
+   certification authority computing equipment.  Audit records MUST
+   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
+
+5.4.2.  Frequency of Processing Log
+
+   Each CA MUST establish its own procedures for review of audit logs.
+
+
+
+Kent, et al.              Best Current Practice                [Page 25]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+5.4.3.  Retention Period for Audit Log
+
+   Each CA MUST establish its own polices for retention of audit logs.
+
+5.4.4.  Protection of Audit Log
+
+   The audit log SHOULD be protected based on current industry
+   standards.
+
+5.4.5.  Audit Log Backup Procedures
+
+   The audit log SHOULD be backed up based on current industry
+   standards.
+
+5.4.8.  Vulnerability Assessments
+
+   The RPKI subsystems of a registry or ISP SHOULD participate in any
+   vulnerability assessments that these organizations run as part of
+   their normal business practice.
+
+5.6.  Key Changeover
+
+   When a CA wishes to change keys, it MUST acquire a new certificate
+   containing its new public key.  See [RFC6489] for a description of
+   how key changeover is effected in the RPKI.
+
+5.7.  CA or RA Termination
+
+   In the RPKI, each subscriber acts as a CA for the specified INRs that
+   were distributed to that entity.  Procedures associated with the
+   termination of a CA MUST be described in the CPS for that CA.  These
+   procedures MUST include a provision to notify each entity that issued
+   a certificate to the organization that is operating the CA that is
+   terminating.
+
+   Since the RA function MUST be provided by the same entity operating
+   as the CA (see Section 1.3.2), there are no separate stipulations for
+   RAs.
+
+6.  Technical Security Controls
+
+   The organizations that distribute INRs to network subscribers are
+   authoritative for these distributions.  This PKI is designed to
+   enable ISPs and network subscribers to demonstrate that they are the
+   holders of the INRs that have been distributed to them.  Accordingly,
+   the security controls used by CAs and subscribers for this PKI need
+   only to be as secure as those that apply to the procedures for
+   administering the distribution of INR data by the extant
+
+
+
+Kent, et al.              Best Current Practice                [Page 26]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+   organizations.  Details of each CA's security controls MUST be
+   described in the CPS issued by the CA.
+
+6.1.  Key Pair Generation and Installation
+
+6.1.1.  Key Pair Generation
+
+   In most instances, public key pairs will be generated by the subject,
+   i.e., the organization receiving the distribution of INRs.  However,
+   some CAs MAY offer to generate key pairs on behalf of their subjects
+   at the request of the subjects, e.g., to accommodate subscribers who
+   do not have the ability to perform key generation in a secure
+   fashion.  (The CA has to check the quality of the keys only if it
+   generates them; see Section 6.1.6.)  Since the keys used in this PKI
+   are not for non-repudiation purposes, generation of key pairs by CAs
+   does not inherently undermine the security of the PKI.  Each CA MUST
+   describe its key pair generation procedures in its CPS.
+
+6.1.2.  Private Key Delivery to Subscriber
+
+   If a CA provides key pair generation services for subscribers, its
+   CPS MUST describe the means by which private keys are delivered to
+   subscribers in a secure fashion.
+
+6.1.3.  Public Key Delivery to Certificate Issuer
+
+   When a public key is transferred to the issuing CA to be certified,
+   it MUST be delivered through a mechanism ensuring that the public key
+   has not been altered during transit and that the subscriber possesses
+   the private key corresponding to the transferred public key.
+
+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.  These certificates
+   MUST be published in the RPKI distributed repository system.  Relying
+   parties download these certificates from the repositories.  Public
+   key values and associated data for (putative) trust anchors are
+   distributed out of band and accepted by relying parties on the basis
+   of locally defined criteria.
+
+6.1.5.  Key Sizes
+
+   The algorithms and key sizes used in the RPKI are specified in "A
+   Profile for Algorithms and Key Sizes for Use in the Resource Public
+   Key Infrastructure" [RFC6485].
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 27]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+6.1.6.  Public Key Parameters Generation and Quality Checking
+
+   The public key parameters used in the RPKI are specified in
+   [RFC6485].  Each subscriber is responsible for performing checks on
+   the quality of its key pair.  A CA is not responsible for performing
+   such checks for subscribers except in the case where the CA generates
+   the key pair on behalf of the subscriber.
+
+6.1.7.  Key Usage Purposes (as per X.509 v3 Key Usage Field)
+
+   The Key usage extension bit values used in the RPKI are specified in
+   RPKI Certificate Profile [RFC6487].
+
+6.2.  Private Key Protection and Cryptographic Module Engineering
+      Controls
+
+6.2.1.  Cryptographic Module Standards and Controls
+
+   The cryptographic module standards and controls employed by each CA
+   MUST be described in the CPS issued by that CA.
+
+6.2.2.  Private Key (N out of M) Multi-Person Control
+
+   CAs MAY employ multi-person controls to constrain access to their
+   private keys, but this is not a requirement for all CAs in the PKI.
+   The CPS for each CA MUST describe which, if any, multi-person
+   controls it employs.
+
+6.2.3.  Private Key Escrow
+
+   No private key escrow procedures are required for the RPKI.
+
+6.2.4.  Private Key Backup
+
+   Because of the adverse operational implications associated with the
+   loss of use of a CA private key in the PKI, each CA MUST employ a
+   secure means to back up its private keys.  The details of the
+   procedures for backing up a CA's private key MUST be described in the
+   CPS issued by the CA.
+
+6.2.5.  Private Key Archival
+
+   The details of the process and procedures used to archive the CA's
+   private key MUST be described in the CPS issued by the CA.
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 28]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+6.2.6.  Private Key Transfer into or from a Cryptographic Module
+
+   The details of the process and procedures used to transfer the CA's
+   private key into or from a cryptographic module MUST be described in
+   the CPS issued by the CA.
+
+6.2.7.  Private Key Storage on Cryptographic Module
+
+   The details of the process and procedures used to store the CA's
+   private key on a cryptographic module and protect it from
+   unauthorized use MUST be described in the CPS issued by the CA.
+
+6.2.8.  Method of Activating a Private Key
+
+   The details of the process and procedures used to activate the CA's
+   private key MUST be described in the CPS issued by the CA.
+
+6.2.9.  Method of Deactivating a Private Key
+
+   The details of the process and procedures used to deactivate the CA's
+   private key MUST be described in the CPS issued by the CA.
+
+6.2.10.  Method of Destroying a Private Key
+
+   The details of the process and procedures used to destroy the CA's
+   private key MUST be described in the CPS issued by the CA.
+
+6.2.11.  Cryptographic Module Rating
+
+   The security rating of the cryptographic module MUST be described in
+   the CPS issued by the CA.
+
+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.
+
+6.3.2.  Certificate Operational Periods and Key Pair Usage Periods
+
+   The INRs held by a CA may periodically change when it receives new
+   distributions.  To minimize disruption, the CA key pair MUST NOT
+   change when INRs are added to its certificate.
+
+   If ISP and network-subscriber certificates are tied to the duration
+   of service agreements, these certificates should have validity
+   periods commensurate with the duration of these agreements.  In any
+
+
+
+Kent, et al.              Best Current Practice                [Page 29]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+   case, the validity period for certificates MUST be chosen by the
+   issuing CA and described in its CPS.
+
+6.4.  Activation Data
+
+   Each CA MUST document in its CPS how it will generate, install, and
+   protect its activation data.
+
+6.5.  Computer Security Controls
+
+   Each CA MUST document the technical security requirements it employs
+   for CA computer operation in its CPS.
+
+6.6.  Life-Cycle Technical Controls
+
+6.6.1.  System Development Controls
+
+   The CPS for each CA MUST document any system development controls
+   required by that CA, if applicable.
+
+6.6.2.  Security Management Controls
+
+   The CPS for each CA MUST document the security controls applied to
+   the software and equipment used for this PKI.  These controls MUST be
+   commensurate with those used for the systems used by the CAs for
+   managing the INRs.
+
+6.6.3.  Life-Cycle Security Controls
+
+   The CPS for each CA MUST document how the equipment (hardware and
+   software) used for this PKI will be procured, installed, maintained,
+   and updated.  This MUST 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
+
+   The CPS for each CA MUST document the network security controls
+   employed for CA operation.  These MUST be commensurate with the
+   protection it employs for the computers used for managing
+   distribution of INRs.
+
+6.8.  Timestamping
+
+   The RPKI does not make use of timestamping.
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 30]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+7.  Certificate and CRL Profiles
+
+   Please refer to the RPKI Certificate and CRL Profile [RFC6487].
+
+8.  Compliance Audit and Other Assessments
+
+   The certificate policy for a typical PKI defines the criteria against
+   which prospective CAs are evaluated and establishes requirements that
+   they must meet.  In this PKI, the CAs are already authoritative for
+   the management of INRs, and the PKI simply supports verification of
+   the distribution of these resources to network subscribers.
+   Accordingly, whatever audit and other assessments are already used to
+   ensure the security of the management of INRs is sufficient for this
+   PKI.  The CPS for each CA MUST describe what audits and other
+   assessments are used.
+
+9.  Other Business and Legal Matters
+
+   As noted throughout this certificate policy, the organizations
+   managing the distribution of INRs are authoritative in their roles as
+   managers of this data.  They MUST operate this PKI to allow the
+   holders of INRs to generate digitally signed data that attest to
+   these distributions.  Therefore, the manner in which the
+   organizations in question manage their business and legal matters for
+   this PKI MUST be commensurate with the way in which they already
+   manage business and legal matters in their existing roles.  Since
+   there is no single set of responses to this section that would apply
+   to all organizations, the topics listed in Sections 4.9.1 to 4.9.11
+   and 4.9.13 to 4.9.17 of RFC 3647 SHOULD be covered in the CPS issued
+   by each CA, although not every CA may choose to address all of these
+   topics.  Please note that the topics in the above sections of RFC
+   3647 become sections 9.1 to 9.11 and 9.13 to 9.17 in the CPS.
+
+9.12.  Amendments
+
+9.12.1.  Procedure for Amendment
+
+   The procedure for amending this CP is via written notice from the
+   IESG in the form of a new (BCP) RFC that updates or obsoletes this
+   document.
+
+9.12.2.  Notification Mechanism and Period
+
+   Successive versions of the CP will be published with the following
+   statement:
+
+      This CP takes effect on MM/DD/YYYY.
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 31]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+   MM/DD/YYYY MUST be a minimum of 6 months from the date of
+   publication.
+
+9.12.3.  Circumstances under Which OID Must Be Changed
+
+   If the IESG judges that changes to the CP do not materially reduce
+   the acceptability of certificates issued for RPKI purposes, there
+   will be no change to the CP OID.  If the IESG judges that changes to
+   the CP do materially change the acceptability of certificates for
+   RPKI purposes, then there MUST be a new CP OID.
+
+10.  Security Considerations
+
+   According to X.509, a certificate policy (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." A CP may be used by a relying party to help
+   in deciding whether a certificate and the binding therein are
+   sufficiently trustworthy and otherwise appropriate for a particular
+   application.  This document describes the CP for the Resource Public
+   Key Infrastructure (RPKI).  There are separate documents (CPSs) that
+   cover the factors that determine the degree to which a relying party
+   can trust the binding embodied in a certificate.  The degree to which
+   such a binding can be trusted depends on several factors, e.g., the
+   practices followed by the CA in authenticating the subject; 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), and the stated
+   responsibilities and liability terms and conditions of the CA (for
+   example, warranties, disclaimers of warranties, and limitations of
+   liability).
+
+   Since name uniqueness within the RPKI cannot be guaranteed, there is
+   a risk that two or more CAs in the RPKI will issue certificates and
+   CRLs under the same issuer name.  Path validation implementations
+   that conform to the resource certification path validation algorithm
+   (see [RFC6487]) verify that the same key was used to sign both the
+   target (the resource certificate) and the corresponding CRL.  So, a
+   name collision will not change the result.  Use of the basic X.509
+   path validation algorithm, which assumes name uniqueness, could
+   result in a revoked certificate being accepted as valid or a valid
+   certificate being rejected as revoked.  Relying parties must ensure
+   that the software they use to validate certificates issued under this
+   policy verifies that the same key was used to sign both the
+   certificate and the corresponding CRL, as specified in [RFC6487].
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 32]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+11.  Acknowledgments
+
+   The authors would like to thank Geoff Huston, Randy Bush, Andrei
+   Robachevsky, and other members of the RPKI community for reviewing
+   this document and Matt Lepinski for his help with the formatting.
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2026]   Bradner, S., "The Internet Standards Process -- Revision
+               3", BCP 9, RFC 2026, October 1996.
+
+   [RFC3779]   Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
+               Addresses and AS Identifiers", RFC 3779, June 2004.
+
+   [RFC6481]   Huston, G., Loomans, R., and G. Michaelson, "A Profile
+               for Resource Certificate Repository Structure", RFC 6481,
+               February 2012.
+
+   [RFC6485]   Huston, G., "The Profile for Algorithms and Key Sizes for
+               Use in the Resource Public Key Infrastructure (RPKI)",
+               RFC 6485, February 2012.
+
+   [RFC6487]   Huston, G., Michaelson, G., and R. Loomans, "A Profile
+               for X.509 PKIX Resource Certificates", RFC 6487, February
+               2012.
+
+   [RFC6489]   Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover
+               in the RPKI", BCP 174, RFC 6489, February 2012.
+
+12.2.  Informative References
+
+   [RFC2560]   Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
+               Adams, "X.509 Internet Public Key Infrastructure Online
+               Certificate Status Protocol - OCSP", RFC 2560, June 1999.
+
+   [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.
+
+   [RFC5055]   Freeman, T., Housley, R., Malpani, A., Cooper, D., and W.
+               Polk, "Server-Based Certificate Validation Protocol
+               (SCVP)", RFC 5055, December 2007.
+
+
+
+Kent, et al.              Best Current Practice                [Page 33]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+   [RFC5736]   Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special
+               Purpose Address Registry", RFC 5736, January 2010.
+
+   [RFC6480]   Lepinski, M. and S. Kent, "An Infrastructure to Support
+               Secure Internet Routing", RFC 6480, February 2012.
+
+   [RFC6482]   Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
+               Origin Authorizations (ROAs)", RFC 6482, February 2012.
+
+   [RFC6486]   Austein, R., Huston, G., Kent, S., and M. Lepinski,
+               "Manifests for the Resource Public Key Infrastructure
+               (RPKI)", RFC 6486, February 2012.
+
+   [RFC6492]   Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A
+               Protocol for Provisioning Resource Certificates", RFC
+               6492, February 2012.
+
+   [X.509]     ITU-T Recommendation X.509 | ISO/IEC 9594-8, "Information
+               technology -- Open systems interconnection -- The
+               Directory: Public-key and attribute certificate
+               frameworks", November 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 34]
+
+RFC 6484             Certificate Policy for the RPKI       February 2012
+
+
+Authors' Addresses
+
+   Stephen Kent
+   BBN Technologies
+   10 Moulton Street
+   Cambridge MA 02138
+   USA
+
+   Phone: +1 617 873 3988
+   EMail: skent@bbn.com
+
+
+   Derrick Kong
+   BBN Technologies
+   Moulton Street
+   Cambridge MA 02138
+   USA
+
+   Phone: +1 617 873 1951
+   EMail: dkong@bbn.com
+
+
+   Karen Seo
+   BBN Technologies
+   10 Moulton Street
+   Cambridge MA 02138
+   USA
+
+   Phone: +1 617 873 3152
+   EMail: kseo@bbn.com
+
+
+   Ronald Watro
+   BBN Technologies
+   10 Moulton Street
+   Cambridge MA 02138
+   USA
+
+   Phone: +1 617 873 2551
+   EMail: rwatro@bbn.com
+
+
+
+
+
+
+
+
+
+
+
+Kent, et al.              Best Current Practice                [Page 35]
+