1. Introduction

As per Certification Policy (CP)

[RFC 6484 Link: https://tools.ietf.org/html/rfc6484 ]:This document is the Certification Practice Statement of the RIPE NCC. It describes the practices employed by the RIPE NCC Certification Authority (CA) in the Resource [RFCxxxx]:This

(RPKI). These practices are defined in accordance with the requirements of the Certificate Policy (CP) [RFC 6484 Link: https://tools.ietf.org/html/rfc6484 ] for RPKI.RPKI

The structure of the Resource PKI (RPKI) is congruent with the number resource allocation framework of the Internet and parallels the existing INR distribution hierarchy. These INRs are distributed by the Internet Assigned Numbers Authority (IANA) to the Internet. The IANA allocates Internet number resources to Regional Internet Registries (RIRs), among others, as well as for special purposes [RFC 8190 Link: https://tools.ietf.org/html/rfc8190 ]. The RIRs [RFC5736]. The RIRs, in turn, manage the allocation of number resources to End Users, Internet Service Providers (ISPs), and others.

In some regions, National Internet Registries (NIRs) are an additional tier in the INR distribution hierarchy, beneath the RIRs. Internet Service Providers (ISPs) and network subscribers then form further tiers below these registries.

This PKI encompasses several types of certificates (see IETF document draft-ietf-sidr-arch-xx Link: http://tools.ietf.org/wg/sidr/draft-ietf-sidr-arch/ for more details):

• CA certificates for each organisation distributing INRs and for the INR holder
• End-entity (EE) certificates for organisations to validate digital signatures on RPKI-signed objects

In addition to the CP [RFC 6484] Link: https://tools.ietf.org/html/rfc6484 , [RFCxxxx], relevant information about general PKI concepts may be found in [RFC 5280 Link: https://tools.ietf.org/html/rfc5280 ], RFC5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile".

Conventions used in this document:

The keywords "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 Link: https://tools.ietf.org/html/rfc2119 ].

1.1. 1. 1. Overview

This CPS describes:

• Participants
• Publication Distribution of the certificates and Certificate Revocation Lists (CRLs)
• How certificates are issued, managed, re-keyed, renewed, managed and revoked
• Facility management (physical security, personnel, audit, etc.)
• Key management
• Audit procedures

The

Certification Practice Statement (CPS) is for convenience and informational purposes only. The RIPE NCC Certification Service Terms and Conditions Link: /manage-ips-and-asns/resource-management/rpki/legal/ripe-ncc-certification-service-terms-and-conditions/ and the RIPE NCC Certification Repository Terms and Conditions Link: /manage-ips-and-asns/resource-management/rpki/legal/ripe-ncc-certification-repository-terms-and-conditions/ prevail over the CPS. The CPS does not affect the interpretation of these Terms and Conditions.This

• CA certificates for each organisation distributing INRs and
• for each subscriber INR holder;End-entity INR holdersEnd entity
(EE) certificates for organisations to validate digital signatures on RPKI-signed

objects.

1.2. Document Name and Identification

The name of this document is "RIPE NCC objectsThe

http://www.ripe.net/certification/legal/index.html Link: http://www.ripe.net/certification/legal/index.html

The RIPE NCC Certification Service Terms and Conditions prevail over the CPS and the CPS does not affect the interpretation of these Terms and Conditions.

1. 2. Document Name and Identification

Public Key Infrastructure".1.3. PKI".1. 3. PKI Participants

As per

the CP [RFC 6484 Link: https://tools.ietf.org/html/rfc6484 ]:Note that in CP [RFCxxxx]:Note: In

1.3.1. Certification Authorities (CAs)

1. 3. 1. Certification Authorities

This CPS covers five three types of CAs for the RPKI: one Offline CA for the RIPE NCC, one All Resources CA (ACA) Online CA for the RIPE NCC, one Production CA, and a number of Hosted CAs, and a number of Delegated hosted member CAs, which are all equivalent and may be described as a single CA for the purpose of this document.

The Offline CA is the top-level CA for the RIPE NCC portion of RPKI, top level CA allowing the RIPE NCC to act as a Trust Anchor in the RPKI.

The ACA Online CA allows the RIPE NCC to act as parent of the Production CA, which in turn acts as a parent CA to RIPE NCC Members and the Delegated CA. This three-layer CA to RIPE NCC Contributors. This two layer approach provides a secure revocation and recovery capability in case the ACA Online CA is compromised or becomes unavailable. Thus, the The Offline CA issues certificates only to instances of the ACA, and the CRLs it issues Online CA. The CRLs issued by the Offline CA are used to revoke only certificates a certificate issued to the

ACA.The ACA 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

Although we can describe the production CA logically as a single unit, it may use additional intermediate CA certificate layers to improve performance by reducing the number of CA children, issued certificates and manifest and CRL entries.In addition,

See section 1.6 also section 1. 6 for definitions and acronyms used in this document.

1.3.2. 1. 3. 2. Registration Authorities

There is no distinct Registration Authority (RA) for either the Offline CA, ACA, and the Production CA or the Online CA operating under this CPS. The former needs no distinct RA capability because it issues certificates only to the Online CA. The Online CA depends on the single sign-on (SSO) sign-on mechanism used by the LIR Portal to identify individuals authorised to make requests. One of the possible sign-on mechanisms is by using an X.509 client certificate issued by the RIPE NCC Business PKI (see section 3. 2. 6 for more details). The RIPE NCC already establishes a contractual relationship with each subscriber (RIPE NCC member) Contributor) and assumes responsibility for distributing and tracking the current allocation of address space and AS Numbers. Since the RIPE NCC operates the LIR Portal sign-on service and BPKI CA, no distinct RA is used.

1.3.3. Subscribers

1. 3. 3. Subscribers

1.3.4. Relying parties

1. 3. 4. Relying parties

As per CP [RFCxxxx]:

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 See section 1. 6 for the definition of an RPKI-signed

object).1.3.5. object.1. 3. 5. Other participants

The RIPE NCC operates a repository that holds certificates, CRLs and other RPKI-signed objects, such as Route Origin Authorisation (ROA) objects.

RIPE NCC Repository is regulated by the RIPE NCC Certification Repository Terms and Conditions Link: /manage-ips-and-asns/resource-management/rpki/legal/ripe-ncc-certification-repository-terms-and-conditions/ .

1.4. Certificate Usage

1. 4. Certificate Usage

The certificates issued under this hierarchy are for authorisation in support of validation of claims of current holdings of INRs. Additional uses, consistent with the basic goal cited above, are also permitted under [RFC 6484 Link: https://tools.ietf.org/html/rfc6484 ].

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 are also permitted under the RPKI certificate policy.

With regard to routing security, an initial goal of this PKI is to enable allow the holder of a set of address blocks to be able to declare, in a secure fashion, the AS Number of each entity that is authorised to originate a route to these addresses, including the context of ISP proxy aggregation. Additional uses of the PKI, consistent with the basic goal cited above, are also permitted under this policy.

1.4.2. 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. CPS Administration

This CPS is administered by

RIPE NCC
Stationsplein 11
1012 AB Amsterdam
The Netherlands

Since this CPS describes the implementation of the Offline CA, Online CA and hosted member CAs maintained by the RIPE NCC, this CPS is also administered by the RIPE NCC. However, it should be noted that approval procedures described in section 1. 5. 3-4 apply.

Whenever the implementation is changed, this CPS will be modified and republished as a RIPE Document. This When this happens this will be announced through the appropriate channels, such communication channels (such as the RIPE NCC's

Membership Announce mailing list (ncc-announce@ripe.net).1.5.2. ncc-announce mailing list).1. 5. 2. Contact person

The

contact information is:

Email: ncc@ripe.net
Phone: +31 20 535 4444

1.5.3. RPKI CPS point of contact is the RIPE NCC, Singel 258, 1016AB, Amsterdam, Netherlands.1. 5. 3. Person determining CPS suitability for the policy

This document is reviewed

by qualified RIPE NCC staff, as well as by an external party during the review process.1.5.4. on behalf of the RIPE community by the Certification Authority Task Force (CA-TF). It is expected that the role of the CA-TF will be transferred to an appropriate RIPE Working Group when the RPKI becomes established as a RIPE NCC service.1. 5. 4. CPS approval procedures

A RIPE certification policy dealing with issues such as validity times, revocation, re-issuance and access to the services involved is currently being developed by the RIPE community. The implementation of the various CAs (Offline, Online and hosted member CAs) will reflect this policy.

This CPS is not subject to the RIPE Policy Development Process (PDP). Process. It provides a detailed outline of the implementation of the RPKI by the RIPE NCC. The CPS is publicly available. When available and when necessary, additional reporting mechanisms, such as mailing lists or presentations at RIPE Meetings, will be are used to communicate its contents. In the event that RPKI implementation becomes the contents. When the RIPE NCC RPKI implementation is found to be inconsistent with applicable policies, the RIPE NCC will policies the RIPE NCC is committed to update the implementation

of this CPS.1.6. and this CPS.1. 6. Definitions and Acronyms

RPKI Objects and

Certificates Certificates: ROA

[res-certificate-profile].ROA Route Origin Authorisation. This is a digitally signed object that provides a means of verifying that an IP address block holder has authorised an Autonomous System (AS) identifies a network operator, identified by an AS Number, that is authorised to originate routes to one or more prefixes within the address block. See [RFC 6482 Link: https://tools.ietf.org/html/rfc6482 ]. a specified set of address blocks. See [RFCroa]. as described in [res-certificate-profile].

Term	Description
Certificate	An X.509 PKIX Resource Certificate as described in [RFC 7318 Link: https://tools.ietf.org/html/rfc7318 ]. There are two types of certificates: Certification Authority (CA): Certificates [res-certificate-profile]. Certificates come in two flavors: Certificate Authority (CA) Certificates are used by Certification Certificate Authorities to issue subordinate certificates and EE certificates. End Entity (EE): (EE) Certificates are embedded in RPKI-signed objects such as Manifests and ROAs and are used to sign these objects (see [RFC 6488 Link: https://tools.ietf.org/html/rfc6488 ]). [RFCsignedobject]). Note the CAs described in this CPS do not currently issue any multi-use End Entity Certificates as described in
[RFC 7318 Link: https://tools.ietf.org/html/rfc7318 ].	ROA
CRL	Certificate Revocation List is a time-stamped list identifying revoked certificates that are signed by a CA or CRL issuer and made freely available in a public repository. See [RFC 7318 Link: https://tools.ietf.org/html/rfc7318 ].
Manifest	A signed object under the RPKI listing all subordinate signed objects and certificates for a CA certificate. See [RFC 6486 Link: https://tools.ietf.org/html/rfc6484 ]. 2. Publication and Repository Responsibilities 2.1.

[RFCmanifest].

file	description
ripe-ncc-ta.cer	RIPE NCC Offline CA (Trust Anchor) Certificate.
ripe-ncc-ta.crl	The Certificate Revocation List (CRL) for the RIPE NCC Offline CA (Trust Anchor).
ripe-ncc-ta.mft	The Manifest object listing all subordinate objects and certificates signed by the RIPE NCC Offline CA (Trust Anchor).
online.cer	The Online CA certificate that is signed and published by the RIPE NCC Offline CA (Trust Anchor).
online.crl	The Certificate Revocation List (CRL) for the Online CA.
online.mft	The Manifest object listing all subordinate objects and certificates signed by the Online CA.
member.cer	The member CA certificate that is signed and published by the Online CA.
member.crl	The Certificate Revocation List (CRL) for the member CA.
member.mft	The Manifest object listing all subordinate objects and certificates signed by the member CA.
roa1.roa	A ROA RPKI-signed object for the member CA.

2. Publication And Repository Responsibilities

2. 1.

As per the CP [RFC 6484 Link: https://tools.ietf.org/html/rfc6484 ], [RFCxxxx], certificates, CRLs and RPKI-signed objects MUST be made available for downloading by all relying parties, are made available to all network operators to download, to enable them to validate this data.

The RIPE NCC will publish this via a repository that is accessible via rsync and RRDP. This repository conforms to the structure described in [RFC 6481 Link: https://tools.ietf.org/html/rfc6481 ].2.2. 2. 2. Publication of Certification Information

The RIPE NCC publishes RIPE NCC uploads the certificates, CRLs and RPKI-signed objects that are issued to a repository it issues to a local repository system that operates as part of a world-wide distributed system of RPKI repositories.

Offline CA

The CA certificate for the RIPE NCC Offline CA is intended to be used as a Trust Anchor by relying parties. The Trust Anchor Locator, as per [RFC 6490 Link: https://tools.ietf.org/html/rfc6490 ], follows:

https://rpki.ripe.net/ta/ripe-ncc-ta.cer

rsync://rpki.ripe.net/ta/ripe-ncc-ta.cer

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0URYSGqUz2myBsOzeW1jQ6NsxNvlLMyhWknvnl8NiBCs/T/S2XuNKQNZ+wBZxIgPPV2pFBFeQAvoH/WK83HwA26V2siwm/MY2nKZ+Olw+wlpzlZ1p3Ipj2eNcKrmit8BwBC8xImzuCGaV0jkRB0GZ0hoH6Ml03umLprRsn6v0xOP0+l6Qc1ZHMFVFb385IQ7FQQTcVIxrdeMsoyJq9eMkE6DoclHhF/NlSllXubASQ9KUWqJ0+Ot3QCXr4LXECMfkpkVR2TZT+v5v658bHVs6ZxRD1b6Uk1uQKAyHUbn/tXvP8lrjAibGzVsXDT2L0x4Edx+QdixPgOji3gBMyL2VwIDAQAB

rsync://rpki.ripe.net/ta/ripe-ncc-ta.cer

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0URYSGqU

z2myBsOzeW1jQ6NsxNvlLMyhWknvnl8NiBCs/T/S2XuNKQNZ+wBZ

xIgPPV2pFBFeQAvoH/WK83HwA26V2siwm/MY2nKZ+Olw+wlpzlZ1

p3Ipj2eNcKrmit8BwBC8xImzuCGaV0jkRB0GZ0hoH6Ml03umLprR

sn6v0xOP0+l6Qc1ZHMFVFb385IQ7FQQTcVIxrdeMsoyJq9eMkE6D

oclHhF/NlSllXubASQ9KUWqJ0+Ot3QCXr4LXECMfkpkVR2TZT+v5

v658bHVs6ZxRD1b6Uk1uQKAyHUbn/tXvP8lrjAibGzVsXDT2L0x4

Edx+QdixPgOji3gBMyL2VwIDAQAB

Online CA

The Online CA publishes subordinate certificates, CRLs and RPKI-signed objects under:

rsync://rpki.ripe.net/repository/33/36711f-25e1-4b5c-9748-e6c58bef82a5/1/

Hosted member CAs

The hosted member CAs publish subordinate signed objects in the repository that is hosted by the RIPE NCC:

rsync://rpki.ripe.net/repository

The exact URI of the publication point is unique per hosted CA. This member CA and can be found in the hosted member CA certificate as described in [RFC 7318 Link: https://tools.ietf.org/html/rfc7318 ]. [res-certificate-profile].

Note the repository structure is defined in

[RFC 6481 Link: https://tools.ietf.org/html/rfc6481 ].2.3. [RFCrepos].2. 3. Time or Frequency of Publication

A certificate will be published within

eight hours of being issued (or deleted).

The RIPE NCC will publish its CRL prior to the next “Update value” in the scheduled CRL previously issued by the CA.

2.4. 24 hours after issuance.2. 4. Access Controls on Repositories

Write access to the repositories is limited to the systems running the ACA, Production CA, and hosted Offline CA, Online CA and hosted member CAs.

3. Identification

and Authentication

3.1. Naming

3. 1. Naming

The Subject of each certificate issued by the RIPE NCC 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 the RIPE NCC. Optionally, the Serial Number attribute may be indicated along with the common name (to form a terminal relative distinguished name set), to distinguish between successive instances of certificates associated with the same entity.

For the Offline CA, CA the self-signed CA certificate is published as a Trust Anchor, as described in Section 2.2. section 2. 2. The subject is “CN=ripe-ncc-ta”. ‘CN=ripe-ncc-ta'.

For all other certificates controlled by the ACA, Production CA, and hosted CAs, Offline CA, Online CA and hosted member CAs the subject has the format CN=<pub key hash>, where the public key hash is a Base64 encoded form of the public key SHA-1 hash, as described in section 2.1 of

[RFC 4387 Link: https://tools.ietf.org/pdf/rfc6487.pdf ].3.1.2. [RFC4387].3. 1. 2. Need for names to be meaningful

The Subject name in each subscriber certificate will be unique to the public key found

in the certificates.The Subject name should on the certificates.Note: The name of the holder of an address block or AS Number is intended to

of INR holdings. They are not used to identify subjects.3.1.3. regarding INR holdings, not for identification.3. 1. 3. Anonymity or pseudonymity of subscribers

Although Subject subject names in certificates issued by this registry should not be are not meaningful, and may appear "random,", anonymity is not a function of this PKI. No PKI, and thus no explicit support for this feature is provided.

3.1.4. 3. 1. 4. Rules for interpreting various name forms

None.

3.1.5. 3. 1. 5. Uniqueness of names

The RIPE NCC certifies Subject names that are unique among the certificates that it issues. Although it is desirable that Subject names be unique throughout the PKI (to facilitate certificate path discovery), uniqueness is not required and is not enforced through technical means. The RIPE NCC generates Subject names to minimise the chance that two entities in the RPKI will be assigned the same name. Specifically, the generated subject based on the public key hash (described in Section 3.1.1.) keeps hash, as described in 3.1.1, reduces the likelihood of accidental collisions to a negligible minimum.

3.1.6. 3. 1. 6. Recognition, authentication, and role of trademarks

Since Because the subject names are not intended to be meaningful, the RIPE NCC makes no provision either there is no provision to recognise or to authenticate trademarks, service marks, etc.

3.2. 3. 2. Initial Identity Validation

3.2.1. 3. 2. 1. Method to prove possession of private key

For the Offline CA, proof of possession of the private keys used for the self-signed certificate can be determined internally.

For the ACA, which acts as a Online CA that acts as subscriber to the Offline CA, and for the Production CA, which acts as a subscriber to the ACA, possession of the private keys is affected effected via the procedures used to generate and manage these keys. Specifically, the RIPE NCC uses a hardware security module (HSM) to generate the key pairs for each of these CAs. This CAs and thus assures that the private key is appropriately associated with the public key in the certificates issued by each of these CAs. CAs

For the hosted member CAs that act as subscribers to the Production Online CA, possession of the private keys is affected effected by the system. Note that the hosted member CAs are managed systems and operators do not access the keys directly. These CAs will contact the Production CA as needed, Online CA as needed via protocols internal to the RIPE NCC. These protocols also cover proof of possession of the private keys.

The Delegated CA, which acts as a subscriber to the Production CA, holds its own key pair. The issuing or renewal of Certificates is performed via the provisioning protocol. See [RFC 6492 Link: https://tools.ietf.org/html/rfc6492 ].

3.2.2. 3. 2. 2. Authentication of organisation identity

Certificates

The hosted Member CA is available only to RIPE NCC Contributors. The RIPE NCC has already established procedures to verify the identity of the RIPE NCC Contributors. These procedures are explained here:

http://www.ripe.net/info/faq/membership/newlir-setup.html#1 Link: http://www.ripe.net/info/faq/membership/newlir-setup.html#1

organisational identity of subscribers. However, certificates are issued to subscribers in a fashion that preserves the accuracy of INR registrations as represented in the RIPE NCC’s records.

The RIPE NCC has already established procedures to verify the identity of Certificate Holders. See section 3.2.3. below.

3.2.3. 3. 2. 3. Authentication of individual identity

Certificates issued under this PKI do not attest to the individual identity of a subscriber. However, the RIPE NCC maintains contact information for each subscriber to support certificate renewal, re-key, and revocation.

Offline CA

Hosted CAs

“Admin” and “Regular” users in the RIPE NCC’s LIR Portal. New users can be added by the current admin user and granted either “Admin” or “Regular” status. This user can then also maintain their CA.

For hosted End User CAs, individual identity is delegated to the LIR Portal account associated with the organisation object referenced in the PI assignment. For more information, please refer to the documentation on RPKI for End Users Link: /manage-ips-and-asns/resource-management/rpki/resource-certification-rpki-for-provider-independent-end-users/ .

Production CA and ACA

The admin user's identity can be (re-)established using the admin password reset procedure:

https://lirportal.ripe.net/lirportal/activation/activation_request.html Link: https://lirportal.ripe.net/lirportal/activation/activation_request.html

The reset procedure involves two halves of a code that are sent via two separate paths, email and fax, that need to be combined in order to reset the "admin" account's password.

Maintenance can also be performed through the internal admin interface.3.2.4. 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 [RFC 6487 Link: https://tools.ietf.org/html/rfc6487 ].3.2.5. policy.3. 2. 5. Validation of authority

The procedure to verify that an individual claiming to represent the subscriber is authorised to represent the subscriber for different CAs is as follows:

• Access to the Offline CA is restricted to a RIPE NCC engineer with Developer that has access to the UNIX Unix account on the server. In addition, the HSM key cards are protected by pass phrases known only to the individual CA Operators (see Section 5.2.3. section 5. 2. 3 for a description of the CA Operator role).
• Access to the Production CA and ACA Online CA is restricted to RIPE NCC CA Operators using
• internal admin interface.For access
the LIR Portal to log in and having an additional role enabled by the administrators of the single sign-on system (this role can not be set by others).Access to the hosted

CA, see Section 3.2.3. above.3.2.6.

The RPKI is not intended or designed to interoperate with any other

PKI.3.3. PKI at this stage.

The function of the Online CA will be extended in the future to interoperate with the other four RIRs and RIPE NCC Contributors operating their own CAs.

3. 3. Identification and Authentication for

Re-key Requests3.3.1. Re-Key Requests3. 3. 1.

The procedure to ensure that a subscriber requesting routine re-key is the legitimate holder of the Certificate is as follows:

• For the Offline CA and ACA, Online CA the same identification and authentication mechanisms apply as described in
• Section 3.2.3.For hosted CAs,
section 3. 2. 3.For hosted member CAs routine re-keys are automated by the software and no explicit authentication is required. A routine re-key is initiated whenever the current key for a hosted member CA is older than five years. The key rollover roll over algorithm is described in

[RFC 6489 Link: https://tools.ietf.org/html/rfc6489 ].

Non-hosted CAs will have to handle re-keys on their own, as the private key is unknown to the RIPE NCC.

3.3.2.

The old key can be revoked as the final step in key rollover algorithm [RFC 6489 Link: https://tools.ietf.org/html/rfc6489 ], once [RFCkeyroll], after a new key has been activated.

In the RIPE NCC’s our implementation, old keys are not automatically revoked after a routine re-key. Explicit revocation of old keys can be done by CA Operators of the Offline CA and the Online CA. CA Operators for the Online CA can also revoke old keys for hosted specific hosted member CAs. Identification and authentication for these roles

is described in Section 3.2.3.This may change after further has been described in section 3. 2. 3.The RIPE NCC implementation may change following

3.4. 3. 4. Identification and Authentication for Revocation Request

For hosted CAs, the holder of the INRs can contact the RIPE NCC Registry Services Department to request the certificate revocation. It should be also member CAs it should be noted that user actions in the interface may result in the revocation of EE certificates used for objects (such as ROAs) that should be invalidated.

For non-hosted CAs, the holder can request the revocation in the user interface.

4. Certificate Life-Cycle Operational Requirements

4.1. Certificate Application

4. 1. Certificate Application

Any RIPE NCC

member or End User holding INRs distributed by the RIPE NCC may submit a certificate application to this CA.4.1.2. Contributor may request a certificate.4. 1. 2. Enrolment process and responsibilities

For the Offline CA, an Engineer CA a Developer can configure and initialise the CA on a server controlled by the RIPE NCC (see Section 5.2.1. section 5. 2. 1 for a description of the Engineer Developer role).

For the ACA and the Production CA, an Engineer Online CA a Developer can install and initialise the application. When this has been done, done a CA Operator can log in and initialise the ACA and the Production Online CA.

For hosted CAs, any RIPE NCC member or End User may choose to use a RIPE NCC-hosted Certification Authority or may choose to set up their own non-hosted CA.

In order to activate the hosted CA, an "Admin" or “Regular” member CA an "admin" user must log in to the LIR Portal. and grant the "certification" role to a normal user. This user must then log in and ensure that a client certificate has been generated for them (or generate one if this is missing).

The user that has the "certification" role will then be able to click through on a link labeled "RPKI Dashboard". This "Certification". This link will take the user to a page where they must explicitly opt in to the hosted CA service. The user does member CA service - they do this by clicking "Yes, I want to activate my hosted member CA". After activation, an automated hosted a mostly automated hosted member CA will be created. Authentication and authorisation for further automated processes should be considered transitive from the moment that user

opts-in and activates the hosted CA.4.2. opted-in and activated the hosted member CA, as described here.4. 2. Certificate Application Processing

For hosted CAs, member CAs an initial CA certificate

should be requested by an authorised representative through the RPKI Dashboard in the LIR Portal.

The requester will be asked to choose the type of the CA as described in Section 4.1.2. and agree to the RIPE NCC Certification Service Terms and Conditions Link: /manage-ips-and-asns/resource-management/rpki/legal/ripe-ncc-certification-service-terms-and-conditions/ .

In the case of a hosted CA, the system will automatically create the certificate in the LIR Portal. The subscriber will need to accept the RIPE NCC Certification Service Terms and Conditions by clicking “I accept. Create my Certification Authority”. This way, the subscriber confirms that they have read, understood, and agree to be bound by these terms and conditions.

For non-hosted CA, the requester will need to upload the identity .xml file generated by their CA software.

4.2.1. is requested automatically by the system when the authorised user chooses to opt in to the service.4. 2. 1. Performing identification and authentication functions

See

Section 3.2.3. for identification and authentication practice of certificate applicants.4.2.2. Approval or rejection section 3. 2. 3.4. 2. 2. Approval of certificate applications

The online CA will issue certificates to hosted CAs that are valid until member CAs with a validity time to the end of the calendar year, plus a further six-month six months grace period to allow for renewal before the certificate expires.

All Provider Aggregatable (PA) resources registered to a RIPE NCC member the RIPE NCC Contributor at the time of issuance will be included in the certificate.

All Provider Independent (PI) resources registered to the End User at the time of issuance will be included in the certificate.

Certificates cannot be issued when:

• The RIPE NCC member does not hold any Internet number resources;
• Service level for a RIPE NCC member has been suspended (e.g. due to non-payment Link: /about-us/financial-information/current-billing-procedure/ ).

4.2.3.

For hosted member CAs, the system will automatically request renewal of the CA certificate that lists all eligible resources when new resources are received by the RIPE NCC Contributor and/or a new validity time is applicable.

4. 2. 3. Time to process certificate applications

Certificates are generated automatically upon request by a RIPE NCC member or End User

and processed immediately.

day.

4.3. Certificate Issuance

The Offline CA will produce a response message that includes all publishable certificates and other objects after the certificate has been issued. This message can be physically transferred to the Production CA and the ACA, Online CA, where it is published.

The Production CA and the ACA, as well as hosted CAs, Online CA and hosted member CAs make all subordinate certificates and objects available for publication. While In practice, the system will make a best effort to publish these materials as soon as possible, but as described in section 2. 3, publication should happen

no later than eight hours after issuance (as described in Section 2.3.)4.3.2. within no more than 24 hours of issuance.4. 3. 2. Notification to subscriber by the CA of issuance of certificate

For RIPE NCC member and End User CAs, there is no active notification to a subscriber about certificate issuance. The approved and published certificate is visible in the RPKI Dashboard in the LIR Portal and in the RIPE NCC-hosted repository.

4.3.3.

Publication of a certificate in the repository operated by RIPE NCC is the means by which a subscriber is notified of certificate issuance. This procedure is employed by all CAs covered by this CPS.

4. 3. 3. Notification of certificate issuance by the CA to other entities

Publication of a certificate in the repository operated by the RIPE NCC is the means by which other entities are notified of certificate issuance.

4.4. Certificate Acceptance

4. 4. Certificate Acceptance

When a certificate is issued, the RIPE NCC CA will publish it in the repository. After the Certificate is issued, the subscriber can see the updated number of issued certificates under “Certified Resources” in the RPKI Dashboard in the LIR Portal.

Certificate acceptance by the subscriber is not part of the process.

4.4.2.

A subscriber is presumed to have accepted a certificate issued by any of the Certificate Authorities covered by this CPS and published in the RIPE NCC repository unless the subscriber contacts the RIPE NCC.

4. 4. 2. Publication of the certificate by the CA

Certificates will be published in the repository system within eight hours one business day of being issued by any of the CAs covered by this CPS.

4.4.3. Notification of certificate issuance by the CA to other entities

There are no entities other than the subscriber who are notified when a certificate is issued.

A summary of the use model for the RPKI IP Address and AS Number PKI is provided below.

4.5.1. 4. 5. 1. Subscriber private key and certificate usage

The hosted member CAs receive CA certificates from the Online CA. This means that these certificates could in principal be used to issue subordinate CA certificates. However, the hosted system does not provide this functionality. The hosted member CA certificates will only be used (by the system) to issue EE certificates used for RPKI-signed objects (such as ROAs) and manifests.

The private key associated with each of these certificates is used to sign subordinate (CA or EE) certificates and CRLs.4.5.2. 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:Verify independently (1) verify that the certificate will be used for an appropriate purpose that is not prohibited or otherwise restricted by this CPS (see section
• 1.4.)Assess
1. 5), and (2) assess the status of the certificate and all the CAs in the chain that issued certificates relevant to the certificate in question (terminating at the RIPE NCC Trust Anchor accepted by the Relying Party). Anchor) that issued the certificates relevant to the certificate in question. If any of the certificates in this the certificate chain have been revoked or have expired, revoked, 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, as defined by the RIPE NCC Certification Repository Terms and Conditions Link: /manage-ips-and-asns/resource-management/rpki/legal/ripe-ncc-certification-repository-terms-and-conditions/ .

If a relying party determines that use of the certificate is appropriate, the relying party must utilise appropriate software and/or hardware to perform digital signature verification as a condition of relying on the certificate. Moreover, Moreover the relying party must MUST validate the certificate in a manner consistent with the RPKI certificate profile [RFC 6487 Link: https://tools.ietf.org/html/rfc6487 ], [RFCyyyy], which specifies the extended validation algorithm for RPKI certificates.

4.6. 4. 6. Certificate Renewal

Note that the hosted member CAs do not issue CA certificates to subordinate CAs and there is no need for certificate renewal for EE certificates used for signed objects. However, hosted member CAs are mentioned a few times in this section as children of the

Production CA and the ACA.4.6.1. Circumstances Online CA.4. 6. 1. Circumstance for certificate renewal

A For hosted member CAs: When new Internet number resources are associated with a RIPE NCC Contributor or a new validity time is applicable (see section 4. 2. 2) a certificate will be

renewed for hosted CAs when new INRs are associated with a RIPE NCC member or End User, or a new validity period is applied (see Section 4.2.2).Note that if INRs renewed.Note that in case Internet number resources

Section 4.9.4.6.2. section 4. 9.4. 6. 2. Who may request renewal

For hosted

CAs, the renewal process is fully automated, which means that the subscriber cannot initiate renewal.For the Production CA and the ACA, a RIPE NCC Engineer member CAs, requests for renewal are fully automated.For the Online CA, RIPE NCC staff with the Online CA Administrator role

For the Offline CA, Internet number resources may have to be added to the self-signed certificate. A RIPE NCC Engineer RIPE NCC staff with the appropriate role may perform this action.

4.6.3. 4. 6. 3. Processing certificate renewal requests

See 4.6.1.

For hosted CAs, the system will automatically request renewal of the CA certificate that lists all eligible INRs when new resources are received by a RIPE NCC member or End User, or a new validity period is applicable.

4.6.4.

The same stipulations listed in section 4. 2. 2 apply here.

4. 6. 4. Notification of new certificate issuance to subscriber

See

Section 4.3.2. (Notification to Subscriber by the CA of Issuance of Certificate).4.6.5. section 4. 3. 2.4. 6. 5. Conduct constituting acceptance of a renewal certificate

See

Section 4.4.1. (Conduct Constituting Certificate Acceptance).4.6.6. section 4. 4. 1.4. 6. 6. Publication of the renewal certificate by the CA

The Offline CA, Production CA, and the ACA, will all Both the Offline CA and Online CA will publish renewed subordinate CA certificates within

eight hours of issuance.4.6.7. one business day of issuance.4. 6. 7. Notification of certificate issuance by the CA to other entities

See

Section 4.3.2. (Notification to Subscriber by the CA of Issuance of Certificate).

4.7. Certificate Re-Key

4. 7. Certificate Re-Key

4.7.1. 4. 7. 1. Circumstance for certificate re-key

Re-key As per the RPKI CP, re-key of a certificate should will be performed only when

• required, based on:Confirmed/suspected requested, based on:Knowledge or suspicion of compromise or loss of the associated private key key, or
• Expiration of the cryptographic lifetime of the associated key pair

If a certificate is revoked to replace the resource extensions (see RFC 3779 Link: https://tools.ietf.org/pdf/rfc3779.pdf ), [res-certificate-profile], the replacement certificate will incorporate the same public key (not a new key). key, not a new key, unless the subscriber requests a re-key at the same time. If the re-key is based on a suspected compromise, then the previous certificate will be revoked.

Section 5.6 of [RFC 6484 Link: https://tools.ietf.org/html/rfc6484 ] the Certificate Policy notes that when a CA signs a certificate, the signing key should have a validity period which exceeds that that exceeds the validity period of the certificate. This places additional constraints on when a CA should request a re-key.

4.7.2. 4. 7. 2. Who may request certification of a new public key

For the RIPE NCC Hosted CA, Production CA, and the ACA, there is no scheduled manual key rollover. This hosted member CAs, an automated key roll over is performed when the key has been in use for five years. Authentication and authorisation for this is considered transitive from opt in (see section 4. 1. 2).For the RIPE NCC Online CA, a manual key rollover is planned to be performed every five years. This manual rollover can be initiated by

a RIPE NCC Engineer in the event of an outage.

The RIPE NCC may also initiate a re-key based on a verified compromise report.

4.7.3. RIPE NCC staff in the Online CA Administrator role.4. 7. 3. Processing certificate re-keying requests

The

procedure in Section 4.2.2 applies here.4.7.4. same stipulations listed in section 4. 2. 2 apply here.4. 7. 4. Notification of new certificate issuance to subscriber

See section

4.3.2.4.7.5. 4. 3. 2.4. 7. 5. Conduct constituting acceptance of a re-keyed certificate

See section

4.4.1.4.7.6. 4. 4. 1.4. 7. 6. Publication of the re-keyed certificate by the CA

For all CAs Certificate Authorities covered by this CPS, a re-keyed certificate will be published in the repository system within eight hours one business day of being issued by this CA.

4.7.7. 4. 7. 7. Notification of certificate issuance by the CA to other entities

See section

4.3.3.

4.8. Certificate Modification

4. 8. Certificate Modification

Certificate modification is not applicable to the CAs described here. Renewal is used when new resources are being to be certified, or a new validity period is applicable (Section 4.6). time is applicable, as described in section 4. 6. Re-issuance and revocation is used when resources are no longer held by an

entity (Section 4.9.).4.9. entity, as described in section 4. 9.4. 9. Certificate Revocation and Suspension

4.9.1. 4. 9. 1. Circumstances for revocation

Certificates must can be revoked for several reasons:

• A signed object needs to be invalidated
• One or more listed INRs Internet number resources are no longer associated with the RIPE NCC
• member or End UserAs a last step ContributorAs the last steps
when doing a planned re-key (clean up)
• As a last step the last steps when doing an unplanned re-key because a loss or compromise of the old key has come to light

The RIPE NCC member violates the RIPE NCC Certification Service Terms and Conditions

A certificate may be revoked if a signed object needs to be invalidated.

4.9.2.

For Hosted and Delegated the hosted member CAs, revocation of their CA certificate can be performed automatically via the RPKI Dashboard in the LIR Portal, by RIPE NCC staff on request or when RIPE NCC staff have reason to believe the keys have been compromised. In this latter case, this would are compromised. In the latter case this will always be performed as the final step of an emergency key rollover for the hosted CA.

For Delegated CAs, the revocation request can be done via the RPKI Dashboard in the LIR Portal.

The other circumstances for revocation, most notably when ROA objects need to be invalidated because a user of the hosted member CA changes the specification, are managed automatically by the system.

For the Production CA and the ACA, Online CA, the RIPE NCC may manually request revocation of the old CA certificate as soon as a key rollover has been performed. Related events, most notably the revocation of the EE certificates used for manifests, are managed by the system.

4.9.3. 4. 9. 3. Procedure for revocation request

When one or more of the INRs Internet number resources listed in a certificate are no longer associated with a RIPE NCC member or End User, Contributor, the Online CA will:

• Re-issue a new certificate that retains certificate, minus the lost Internet number resources, but maintaining all other properties (minus the affected INRs)
• Publish the new certificate using the same publication point as before, thus replacing the old certificate
• Revoke any non-expired certificates held by the hosted member CA that list the affected INRs, lost Internet number resources, thus invalidating any signed objects (such as ROAs) that refer to these

  resources

  For Delegated CAs, a new certificate not be issued automatically once the revocation request has been completed. This will have to be requested again via the LIR Portal.

  4.9.4. Internet number resources.4. 9. 4.

Any party or operators who can identify a that is able to identify the need for revocation that is not already handled by the system are and operators is expected to notify the RIPE NCC

as soon as possible.4.9.5. within one business day.4. 9. 5. Time within which CA must process the revocation request

The RIPE NCC will process a revocation request within eight hours one business day of receipt and validation of the request.

4.9.6. 4. 9. 6. Revocation checking requirement for relying parties

As per [RFC 6484 Link: https://tools.ietf.org/html/rfc6484 ], whenever the CP, a relying party validates a certificate, it is responsible for acquiring and checking the most recent, scheduled CRL from the issuer of the

certificate4.9.7. certificate, whenever that relying party validates a certificate.4. 9. 7. CRL issuance frequency

Each CRL contains a “Next Update” value, will carry a nextScheduledUpdate value and a new CRL will be published at or before that time. The RIPE NCC will set the “Next Update” nextScheduledUpdate value when it issues a CRL to signal when the next scheduled CRL will be issued.

The CAs covered by this CPS use different values:

As a matter of good operational practice, sense, all CAs covered by this CPS will aim strive to republish and re-issue a new CRL before the next scheduled update value, to allow value in time to deal with any operational problems.

It should be noted that the values listed here may be used by relying parties to determine the need to fetch an updated CRL.

4.9.8. In particular this means that a possible revocation by the Offline CA may go unnoticed for three months - this should not be a problem since the production keys are protected by an HSM. A revoked ROA for a hosted member CA may not be noticed for 24 hours. The values here should be regarded as a compromise between various aspects, including the operational burden of re-signing (for Offline CA), time needed to be able to do an emergency restore, efficiency of caching in the global RPKI, propagation time of revocation in the global RPKI.4. 9. 8. Maximum latency for CRLs

A CRL will be published posted to the repository system within

eight hours of their generation.4.10. one hour of issuance.

4. 9. 9. On-line revocation/status checking availability [OMITTED]

4. 9. 10. On-line revocation checking requirements [OMITTED]

4. 9. 11. Other forms of revocation advertisements available [OMITTED]

4. 9. 12. Special requirements re key compromise [OMITTED]

4. 9. 13. Circumstances for suspension [OMITTED]

4. 9. 14. Who can request suspension [OMITTED]

4. 9. 15. Procedure for suspension request [OMITTED]

4. 9. 16. Limits on suspension period [OMITTED]

The RIPE NCC will only issue CRLs and does These CAs do not support Online Certificate Status Protocol (OCSP) or the Server-Based Certificate Validation Protocol (SCVP).

5. Facility, Management and Operational Controls

5.1. Physical Controls

5. 1. Physical Controls

For the Offline CA, operations are conducted

at the RIPE NCC office:RIPE NCC
Stationsplein 11
1012 AB within a physically protected area of an office building in which the RIPE NCC is a tenant. This building is located at:

Singel 258

The RIPE NCC space within this facility includes offices and meeting spaces and two machine rooms.

For the Production CA and hosted member CAs, core cryptographic operations are performed by virtual machines and their respective HSMs two machines physically located in two different data centres centers in a load balanced (and fail-over) fail over) set up. The two data

centres are:Equinix AM3
Science Park 610
1098 XH centers are:

Nikhef:

Science Park 105

Equinix AM5
Schepenbergweg 42
1105 AT

Telecity 2:

Kuiperbergweg 13

5.1.2. Physical access

The offline CA is operated using a laptop and USB-based HSM that are kept in a sealed bag in a safe at the RIPE NCC office. The offline CA key can only be used when three out of ten operator card holders are present and approve operation. Operator cards are kept by the card holders and are not stored at the RIPE NCC office.

5. 1. 2. Physical access

For the Offline CA, physical access is restricted to the RIPE NCC's IT staff and senior managers. The access system relies on personal smart cards. Access to areas is logged every moment of the day on our access system, this data is mirrored at the same moment to another server, located in another building. CCTV is in operation and recordings are kept for one week.

5.1.3. Only Telecity2 staff can open the suite for us and access is logged by the reception.5. 1. 3. Power and air conditioning

The

server rooms are located on the first floor of the building, which is above sea level. Power to the data centres comes from the public grid, supported by internal backup generator infrastructure. More information on the ISO standards applicable to Equinix AM3 and Equinix AM5 data centres Link: https://www.equinix.nl/data-centers/design/standards-compliance/ is available.

5.1.4. Water exposures

The server rooms located at Equinix AM3 and Equinix AM5 are both located on the first floor of their building or higher, which is above sea level.

5.1.5. Fire prevention and protection

The server room at Equinix AM3 has a two-stage fire detection system: Aspiration and VESDA, on a head-per-head basis. The server room at Equinix AM5 has VESDA and HI-FOG as water mist fire suppression and double knock fire activation.

5.1.6. Media storage

Whenever the Offline CA is operated, all data is backed up to a USB stick (and encrypted where needed).

For Nikhef, power consumption and air conditioning are monitored by the provider. Should power consumption exceed the maximum allowance, the RIPE NCC will receive an invoice, but power will not be cut. Nikhef has an uninterruptible power supply (UPS) to overcome immediate power failures, and a generator with enough fuel to cover for arrival of more fuel and/or fixing the power failure.

For Telecity2, power consumption and air conditioning are monitored by the provider. Should power consumption exceed the maximum allowance, the RIPE NCC will receive an invoice, but power will not be cut. Telecity2 has a UPS to overcome immediate power failures, and a generator with enough fuel to cover for arrival of more fuel and/or fixing the power failure.

5. 1. 4. Water exposures

The RIPE NCC server room used by the Offline CA is located on the second floor of the office building. This is above sea level.

The server room located at Nikhef is located on the first floor of their building. This is above sea level.

The server room located at Telecity2 is located on the first floor of their building.

5. 1. 5. Fire prevention and protection

a restore.

5.1.7. Waste disposal

5. 1. 6. Media storage

Whenever the Offline CA is operated, all data is backed up (encrypted where needed) to a network filesystem that is mirrored between the Nikhef and Telecity2 datacenters. In addition this data is backed up off-site nightly (see section 5. 1. 8).

For the Online CA and hosted member CAs all data is stored (encrypted where needed) on a network filesystem that is mirrored between the Nikhef and Telecity2 datacenters. In addition this data is backed-up off-site nightly (see section 5. 1. 8).

5. 1. 7. Waste disposal

When servers reach their end of life, the hard disks are physically destroyed by RIPE NCC staff.

Once the HSM is decommissioned, the private keys on the device will be wiped according to the process specified by the vendor. Broken modules for which this is not possible will be destroyed.

There is no other waste that may contain sensitive data.

5.1.8. 5. 1. 8. Off-site backup

The network filesystem, used to store the data from the CAs, is backed up every night to another fileserver. This second fileserver is also backed up every night to another backup

server.

5.2. Procedural Controls

Below are the procedural security controls used for certificate management.

5. 2. Procedural Controls

For the Offline CA:

For the Online