Historical CPS

1. Introduction

This document is the Certification Practice Statement (CPS) of APNIC. It describes the practices employed by the APNIC Certification Authority (CA) in the Internet IP Address and Autonomous System (AS) Number PKI. These practices are defined in accordance with the requirements of the Certificate Policy (CP, [RFC6484]) of this PKI.

The Internet IP Address and AS Number PKI is aimed at supporting verifiable attestations about resource controls, e.g., for improved routing security. The goal is that each entity that allocates IP addresses or AS numbers to an entity will, in parallel, issue a certificate reflecting this allocation. These certificates will enable verification that the holder of the associated private key has been allocated the resources indicated in the certificate, and is the current, unique holder of these resources. The certificates and CRLs, in conjunction with ancillary digitally signed data structures, will provide critical inputs for routing security mechanisms, e.g., generation of route filters by ISPs.

The most important and distinguishing aspect of the PKI for which this CPS was created is that it does not purport to identify an address space holder or AS number 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 address block or an AS number, 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 producing a signature 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 address space and AS number holdings, with emphasis on support of routing security mechanisms. Use of the certificates and CRLs managed under this PKI for any other purpose is a violation of this PKI’s CP, and relying parties should reject such uses.

Note: This CPS is based on the template specified in RFC 3647. A number of sections contained in the template were omitted from this CPS because they did not apply to this PKI. However, we have retained section heading “place holders” for these omitted sections, in order to facilitate comparison with the section numbering scheme employed in that RFC, i.e., the relevant section headings are included and marked [OMITTED]. In the Table of Contents the relevant sections are also marked [OMITTED].

1.1. Overview

This CPS describes:

• Participants
• Distribution of the certificates and CRLs
• How certificates are issued, managed, and revoked
• Facility management (physical security, personnel, audit, etc.)
• Key management
• Audit procedures
• Business and legal issues

The PKI encompasses several types of certificates:

• CA certificates for each organization allocating address blocks and/or AS numbers, and for each address space (AS number) holder
• End entity (EE) certificates for organizations to use in verifying signatures of Route Origination Authorizations (ROAs) and other (non-certificate/CRL) signed objects
• In the future, the PKI also may include end entity certificates in support of access control for the repository system

1.2. Document name and identification

The name of this document is “APNIC Certification Practice Statement for the Resource PKI”.

1.3. PKI participants

Note: 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 LIR/ISP. Thus, in this PKI, the term “subscriber” can refer both to LIRs/ISPs, which can be subscribers of RIRs, NIRs, and other LIRs, and also to organizations that are not ISPs, but which are subscribers of ISPs in the networking sense of the term. Also note that, for brevity, this document always refers to subscribers as organizations, even though some subscribers are individuals. When necessary, the phrase “network subscriber” is used to refer to an organization that receives network services from an LIR/ISP.

1.3.1. Certification authorities

APNIC operates two CAs for the RPKI: one is designated “offline” and the other is designated “production.” The offline CA is the top level CA for the APNIC portion of the RPKI. It provides a secure revocation and recovery capability in case the production CA is compromised or become unavailable Thus this CA issues certificates only to instances of the production CA and the CRLs it issues are used to revoke only a certificate issued to that CA. The production CA is used to issue RPKI certificates to APNIC members, to which address space or AS numbers have been allocated. In the future, the production CA also may issue other types of end entity (EE) certificates, e.g., EE certificates to operations personnel in support of repository maintenance.

1.3.2. Registration authorities

There is no registration authority (RA) for either the offline or the production CA operating under this CPS. The former needs no RA capability because it issues certificates only to the production CA. The production CA relies upon certificates issued by the APNIC Business PKI (BPKI) (see Section 3.2.6) to identify individuals authorized to requests certificates under the RPKI. APNIC already establishes a business relationship with each subscriber (APNIC member) and assumes responsibility for allocating and tracking the current allocation of address space and AS numbers. Since APNIC operates the BPKI CA, there is no distinct RA for the RPKI.

1.3.3. Subscribers

Two types of organizations receive allocations of IP addresses and AS numbers from this CA and thus are subscribers in the PKI sense: network subscribers and Internet Service Providers (ISPs). Additionally, this CA issues certificates to National Internet Registries (NIRs) who, in turn, issue certificates to network subscribers or LIRs/ISPs.

1.3.4. Relying parties

Entities that need to validate claims of address space and/or AS number current holdings are relying parties. Thus, for example, entities that make use of address and AS number allocation certificates in support of improved routing security are relying parties. Registries are relying parties because they transfer resources between one another and thus will need to verify (cross) certificates issued in conjunction with such transfers. This includes LIRs/ISPs, multi-homed organizations exchanging BGP [BGP4] traffic with LIRs/ISPs, and subscribers who have received an allocation of address space from one ISP or from a registry, but want to authorize an (or another) LIR/ISP to originate routes to this space.

To the extent that repositories make use of certificates for access control – checking for authorization to upload certificate, CRL, and ROA update packages – they too act as relying parties.

1.3.5. Other participants

APNIC operates a repository that holds certificates, CRLs, and other RPKI signed objects, e.g., ROAs.

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 address space and/or AS numbers, e.g., for routing security. With regard to routing security, an initial goal of this PKI is to 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 authorized 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.

Some of the certificates that may be issued under this hierarchy could be used to support operation of this infrastructure, e.g., access control for the repository system. Such uses also are permitted under this policy.

1.4.2. Prohibited certificate uses

Any uses other than those described in Section 1.4.1 are prohibited.

1.5. Policy administration

1.5.1. Organization administering the document

This CPS is administered by APNIC.

1.5.2. Contact person

The RPKI CPS point of contact is the Security Officer for APNIC. He may be reached at 33 Park Road, Brisbane, AU, 4064.

1.5.3. Person determining CPS suitability for the policy

Not applicable. Each organization issuing a certificate in this PKI is attesting to the allocation of resources (IP addresses, AS numbers) to the holder of the private key corresponding to the public key in the certificate. The issuing organizations are the same organizations as the ones that perform the allocation hence they are authoritative with respect to the accuracy of this binding.

1.5.4. CPS approval procedures

Not applicable. Each organization issuing a certificate in this PKI is attesting to the allocation of resources (IP addresses, AS numbers) to the holder of the private key corresponding to the public key in the certificate. The issuing organizations are the same organizations as the ones that perform the allocation hence they are authoritative with respect to the accuracy of this binding.

1.6. Definitions and acronyms

BPKI – Business PKI: A BPKI is used by an RIR to identify members to whom RPKI certificates can be issued.

CP – Certificate Policy. A CP is a named set of rules that indicates the applicability of a certificate to a particular community and/or class of applications with common security requirements.

CPS – Certification Practice Statement. A CPS is a document that specifies the practices that a Certification Authority employs in issuing certificates.

ISP – Internet Service Provider. An ISP is an organization managing and selling Internet services to other organizations.

LIR – Local Internet Registry. This is an organization, typically a network service provider, that sub-allocates the assignment of IP addresses for a portion of the area covered by a Regional (or National) Registry.

NIR – National Internet Registry. An NIR is an organization that manages the assignment of IP address and AS numbers for a portion of the geopolitical area covered by a Regional Registry. These form an optional second tier in the tree scheme used to manage IP address and AS number allocation.

RIR – Regional Internet Registry. An RIR is an organization that manages the assignment of IP address and AS numbers for a specified geopolitical area. At present, there are five RIRs: ARIN (North America), RIPE NCC (Europe), APNIC (Asia – Pacific), LACNIC (Latin America and Caribbean), and AfriNIC (Africa).

ROA – Route Origination Authorization. This is a digitally signed object that identifies a network operator, identified by an AS, that is authorized to originate routes to a specified set of address blocks.

2. Publication And Repository Responsibilities

2.1. Repositories

As per the CP, certificates and CRLs, are made available for downloading by all network operators, to enable them to validate this data for use in support of routing security. The APNIC RPKI CA publishes certificates, CRLs, and other signed objects accessible via RSYNC at rpki.apnic.net.

2.2. Publication of certification information

APNIC uploads certificates and CRLs issued by it to a local repository system that operates as part of a world-wide distributed system of repositories.

2.3. Time or Frequency of Publication

As per the CP, the following standards exist for publication times and frequency:

A certificate will be published within 24 hours after issuance.

The APNIC CA will publish its CRL prior to the nextScheduledUpdate value in the scheduled CRL previously issued by the CA. Within 24 hours of effecting revocation, the CA will publish a CRL with an entry for the revoked certificate.

2.4. Access controls on repositories

Access to the repository system, for modification of entries, must be controlled to prevent denial of service attacks. All data (certificates, CRLs and ROAs) uploaded to a repository are digitally signed. Updates to the repository system must be validated to ensure that the data being added or replaced is authorized. This document does not define the means by which updates are verified, but use of the PKI itself to validate updates is anticipated.

3. Identification And Authentication

3.1. Naming

3.1.1. Types of names

The Subject of each certificate issued by this Registry is identified by an X.500 Distinguished Name (DN). For certificates issued to NIRs/LIRs/ISPs and subscribers, the Subject will consist of a single CN attribute with a value generated by the issuer.

3.1.2. Need for names to be meaningful

The Subject name in each subscriber certificate will be unique relative to all certificates issued by APNIC RPKI CA. However, there is no guarantee that the subject name will be globally unique in this PKI.

Note: The name of the holder of an address block or AS number need not to be “meaningful” in the conventional, human-readable sense, since certificates issued under this PKI are used for authorization in support of routing security, not for identification

3.1.3. Anonymity or pseudonymity of subscribers

Although Subject names in certificates issued by this registry need not be meaningful, and may appear “random,” anonymity is not a function of this PKI, and 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

APNIC certifies Subject names that are unique among the certificates that it issues. Although it is desirable that these Subject names be unique throughout the PKI, to facilitate certificate path discovery, such uniqueness is neither mandated nor enforced through technical means.

3.1.6. Recognition, authentication, and role of trademarks

Because the Subject names are not intended to be meaningful, there is no provision to recognize nor authenticate trademarks, service marks, etc.

3.2. Initial identity validation

3.2.1. Method to prove possession of private key

APNIC accepts certificate requests via the protocol described in [RFC6492]. This protocol makes use of the PKCS #10 format, as profiled in [RFC6487]. This request format requires that the PKCS #10 request be signed using the (RSA) private key corresponding to the public key in the certificate request. This mechanism provides proof of possession by the requester.

3.2.2. Authentication of organization identity

Certificates issued under this PKI do not attest to the organizational identity of resource holders, with the exception of registries. However, certificates are issued to resource holders in a fashion that preserves the accuracy of allocations as represented in APNIC records. Specifically, a BPKI certificate used to authenticate a certificate request serves as a link to the APNIC member database that maintains the resource allocation records. The certificate request is matched against the database record for the member in question, and an RPKI certificate is issued only if the resources requested are a subset of those held by the member.

3.2.3. Authentication of individual identity

Certificates issued under this PKI do not attest to the individual identity of a resource holder. However, APNIC maintains contact information for each resource holder in support of certificate renewal, re-key, or revocation, via the BPKI.

The APNIC BPKI (see Section 3.2.6) issues certificates that are used to identify individuals who represent APNIC members that are address space (or AS number) holders.

3.2.4. Non-verified subscriber information

No non-verified subscriber data is included in certificates issued under this certificate policy.

3.2.5. Validation of authority

Only an individual to whom a BPKI certificate (see Section 3.2.6) has been issued may request issuance of an RPKI certificate. Each certificate issuance request is verified using the BPKI.

3.2.6. Criteria for interoperation

The RPKI is neither intended nor designed to interoperate with any other PKI. However, APNIC operates a BPKI [cps-business-pki] that is used to authenticate members and to enable them to manage their resource allocations. The Resource PKI relies on this BPKI to authenticate Subscribers who make certificate requests, revocation requests, etc.

3.3. Identification and authentication for re-key requests

3.3.1. Identification and authentication for routine re-key

Routine re-key is effected via a Certificate Issuance Request message as described in [RFC6492]. This digitally signed CMS message is authenticated using a BPKI certificate associated with the requester.

3.3.2. Identification and authentication for re-key after revocation

Re-key after revocation is effected via a Certificate Issuance Request message as described in [RFC6492]. This digitally signed CMS message is authenticated using a BPKI certificate associated with the requester.

3.4. Identification and authentication for revocation request

An RPKI Subscriber makes an explicit revocation request using the protocol defined in [RFC6492]. Revocation requests in this protocol are digitally signed CMS messages, and are verified using a public key bound to an authorized representative via the APNIC BPKI.

When a Subscriber requests an new resource allocation, an existing resource certificate issued to the subscriber is NOT revoked, so long as the set of resources allocated to the Subscriber did not “shrink,” i.e., the new resources are a superset of the old resource set. However, if a new resource allocation results in “shrinkage” of the set of resources allocated to a Subscriber, this triggers an implicit revocation of the old resource certificate(s) associated with that Subscriber.

4. Certificate Life-Cycle Operational Requirements

4.1. Certificate Application

4.1.1. Who can submit a certificate application

Any entity enrolled under the APNIC BPKI may request a certificate under the RPKI.

4.1.2. Enrollment process and responsibilities

APNIC members who are resource holders are enrolled in the APNIC BPKI via the process described in [www.apnic.net/ca/index.html]. Only a member who holds a certificate issued under the BPKI is eligible to make an RPKI certificate request.

4.2. Certificate application processing

An APNIC resource holder requests a certificate via a Certificate Issuance Request message [RFC6492], which is authenticated via the digital signature on the CMS envelope. The certificate used to authenticate the message is issued under the APNIC BPKI. APNIC processes the resource request as described in [RFC6492]. The Certificate Issuance Response message [RFC6492] either provides the certificate to the Subscriber, or provides a response indicating why the request was not fulfilled.

4.2.1. Performing identification and authentication functions

The APNIC BPKI is used to identify an APNIC member representative applying for a certificate via a certificate issuance request in the RFC6492 protocol. See the APNIC BPKI CPS for additional details [cpbusiness-pki]

4.2.2. Approval or rejection of certificate applications

The Certificate Issuance Response message [RFC6492] either provides the certificate to the Subscriber, or provides a response indicating why the request was not fulfilled. Certificate approval/rejection, for a syntactically valid request, is based on the APNIC resource allocation policy described at [www.apnic.net/services/guide/eligibility.html].

4.2.3. Time to process certificate applications

APNIC expects to issue a certificate attesting to a resource allocation within 1 business day after approval of the allocation.

4.3. Certificate issuance

4.3.1. CA actions during certificate issuance

A Subscriber generates a draft certificate using the PKCS #10 format, as profiled in [RFC6487]. This draft certificate is encapsulated in a CMS message, signed by the requester, and submitted as a Certificate Issuance Request as described in [RFC6492]. The CA verifies the request message as described in [RFC6492] and generates a Certificate Issuance Response message. That message either contains the requested certificate, or provides a response indicating why the request was not fulfilled.

4.3.2. Notification to subscriber by the CA of issuance of certificate

A Subscriber is notified of the issuance of a new certificate by the Certificate Issuance Response message.

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

[OMITTED]

4.4. Certificate acceptance

4.4.1. Conduct constituting certificate acceptance

A subject is deemed to have accepted a certificate issued by this CA unless the subject explicitly requests revocation of the certificate using the procedures described in Section 4.9.3.

4.4.2. Publication of the certificate by the CA

Certificates will be published in the Repository system within 1 business day of being issued by this CA.

4.5. Key pair and certificate usage

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

4.5.1. Subscriber private key and certificate usage

The certificates issued by this registry to resource holders are CA certificates. The private key associated with each of these certificates is used to sign subordinate (CA or EE) certificates and CRLs. A subscriber will issue certificates to any organizations to which it allocates resources and one or more EE certificates for use in verifying signatures on ROAs signed by the subscriber. Subscribers that are NIRs issue certificates to organizations to which they have allocated address space or AS numbers. Subscribers that are LIRs issue certificates to organizations to which they have allocated address space. Subscribers also will issue certificates to operators in support of repository access control.

4.5.2. Relying party public key and certificate usage

The primary relying parties in this PKI are LIRs/ISPs, who will use RPKI EE certificates to verify ROAs and other signed objects, e.g., in support of generating route filters.

4.6. Certificate renewal

4.6.1. Circumstance for certificate renewal

As per the CP, a certificate will be processed for renewal based on its expiration date or a renewal request from the certificate Subject. The request may be implicit, a side effect of renewing its resource holding agreement, or may be explicit. If APNIC initiates the renewal process based on the certificate expiration date, then APNIC will notify the resource holder 6 months prior to the expiration date. The validity interval of the new (renewed) certificate will overlap that of the previous certificate by 6 months, to ensure uninterrupted coverage.

Certificate renewal will incorporate the same public key as the previous certificate, unless the private key has been reported as compromised. If a new key pair is being used, the stipulations of Section 4.7 will apply.

4.6.2. Who may request renewal

The certificate holder or APNIC may initiate the renewal process. For the case of the certificate holder, only an individual to whom a BPKI certificate (see Section 3.2.6) has been issued may request renewal of an RPKI certificate. Each certificate issuance request is verified using the BPKI.

4.6.3. Processing certificate renewal requests

A Subscriber requests certificate renewal by sending a Certificate Issuance Request message [RFC6492].

4.6.4. Notification of new certificate issuance to subscriber

A Subscriber is notified of the issuance of a new certificate via the Certificate Issuance Response message, if the Subscriber initiated the renewal. If APNIC initiated the renewal process, the Subscriber is notified by the posting of the renewed certificate in the repository. A Subscriber can discover a certificate renewed by APNIC through use of the List message [RFC6492].

4.6.5. Conduct constituting acceptance of a renewal certificate

A Subscriber is deemed to have accepted a certificate unless the subscriber explicitly requests revocation of the certificate after publication in the APNIC RPKI repository system, as described in Section 4.9.3.

4.6.6. Publication of the renewal certificate by the CA

APNIC will publish a renewal certificate in the APNIC RPKI repository within 1 business day after issuance of the renewed certificate.

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

[OMITTED]

4.7. Certificate re-key

4.7.1. Circumstance for certificate re-key

As per the CP, re-key of a certificate will be performed only when requested, based on:

1. knowledge or suspicion of compromise or loss of the associated private key, or
2. the expiration of the cryptographic lifetime of the associated key pair

If a certificate is revoked to replace the RFC 3779 extensions, the replacement certificate will incorporate the same public key, not a new key, 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 the Certificate Policy notes that when a CA signs a certificate, the signing key should have a validity period that exceeds the validity period of the certificate. This places additional constraints on when a CA should request a re-key.

4.7.2. Who may request certification of a new public key

The holder of the certificate may request a re-key. In addition, APNIC may initiate a re-key based on a verified compromise report. If the Subscriber (certificate Subject) requests the rekey, authentication is effected using the APNIC BPKI.

4.7.3. Processing certificate re-keying requests

A Subscriber requests a re-key of a certificate by issuing a Certificate Issuance Request message in which the resources are ones that the Subscriber already holds, but a new public key is provided in the PKCS #10 portion of the request.

4.7.4. Notification of new certificate issuance to subscriber

A Subscriber is notified of the issuance of a re-keyed certificate via the Certificate Issuance Response message.

4.7.5. Conduct constituting acceptance of a re-keyed certificate

A subject is deemed to have accepted a certificate issued by this CA unless the subject explicitly requests revocation of the certificate using the procedures described in Section 4.9.3.

4.7.6. Publication of the re-keyed certificate by the CA

A re-keyed certificate will be published in the Repository system within 1 business day of being issued by this CA.

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

[OMITTED]

4.8. Certificate modification

4.8.1. Circumstance for certificate modification

As per the CP, modification of a certificate occurs to implement changes to the RFC 3779 extension values in a certificate. A subscriber can request a certificate modification when this information in a currently valid certificate has changed, as a result of changes in the resource holdings of the subscriber. The request may be implicit, a side effect of the allocation of additional resources, or may be explicit. A subscriber also may request that its existing set of resources be redistributed among multiple certificates. This example of certificate modification is effected through issuance of new certificates, and revocation of the previous certificates.

If a subscriber is to be allocated address space or AS numbers in addition to a current allocation, and if the subscriber does not request that a new certificate be issued containing only these resources, then this is accomplished through a certificate modification. When a certificate modification is approved, a new certificate is issued. The new certificate will contain the same public key and the same expiration date as the original certificate, but with the incidental information corrected and/or the address space and AS allocations expanded. When previously allocated address space or AS numbers are to be removed from a certificate, then the old certificate MUST be revoked and a new certificate (reflecting the new allocation) issued.

4.8.2. Who may request certificate modification

The certificate holder or APNIC may initiate the certificate modification process. If a certificate holder requests the modification, the request is authenticated using the APNIC BPKI, as described in [RFC6492]. APNIC will modify a certificate, and revoke the old certificate, if, for example, a Subscriber fails to renew membership in a timely fashion.

4.8.3. Processing certificate modification requests

A certificate can be modified (other than for re-key) only by the addition or removal or resources. A Subscriber requests certificate modification by submitting a Certificate Issuance Request. If the request contains values for AS and/or (IPv4 or IPv6) address resource sets that the Subscriber already holds, but which are different from those in the currently issued certificates, the request is interpreted as a request for certificate modification.

4.8.4. Notification of modified certificate issuance to subscriber

A Subscriber is notified of the issuance of a modified certificate by the publication of the certificate in the APNIC RPKI repository system.

4.8.5. Conduct constituting acceptance of modified certificate

A subject is deemed to have accepted a certificate issued by this CA unless the subject explicitly requests revocation of the certificate using the procedures described in Section 4.9.3.

4.8.6. Publication of the modified certificate by the CA

A re-keyed certificate will be published in the APNIC RPKI Repository system within 1 business day of being issued by this CA.

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

[OMITTED]

4.9. Certificate revocation and suspension

4.9.1. Circumstances for revocation

As per the CP, certificates can be revoked for several reasons. Either APNIC or the subject may choose to end the relationship expressed in the certificate, thus creating cause to revoke the certificate. If one or more of the resources bound to the public key in the certificate are no longer associated with the subject, that too constitutes a basis for revocation. A certificate also may be revoked due to loss or compromise of the private key corresponding to the public key in the certificate. Finally, a certificate may be revoked in order to invalidate data signed by that certificate.

4.9.2. Who can request revocation

The certificate holder or APNIC may request a revocation. A Subscriber requests certificate revocation using the Certificate Revocation Request message described in [RFC6492].

4.9.3. Procedure for revocation request

A Subscriber requests certificate revocation using the Certificate Revocation Request message described in [RFC6492]. The Certificate Revocation Response messages confirms receipt of the revocation request by APNIC, and indicates that APNIC will include the revoked certificate in a CRL.

4.9.4. Revocation request grace period

A Subscriber should request revocation as soon as possible after the need for revocation has been identified.

4.9.5. Time within which CA must process the revocation request

APNIC will process a revocation request within 1 business day of receipt and validation of the request.

4.9.6. Revocation checking requirement for relying parties

As per the CP, a relying party is responsible for acquiring and checking the most recent, scheduled CRL from the issuer of the certificate, whenever the relying party validates a certificate.

4.9.7. CRL issuance frequency

The APNIC RPKI CA production will publish a new CRL every 24 hours. The APNIC RPKI offline CA will publish a new CRL on a monthly basis. Each CRL will carry a nextScheduledUpdate value and a new CRL will be published at or before that time. APNIC will set the nextScheduledUpdate value when it issues a CRL, to signal when the next scheduled CRL will be issued.

4.9.8. Maximum latency for CRLs

A CRL will be posted to the repository system with minimal delay after generation.

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]

4.10. Certificate status services

APNIC does not support OCSP. APNIC issues CRLs.

4.10.1. Operational characteristics [OMITTED]

4.10.2. Service availability [OMITTED]

4.10.3. Optional features [OMITTED]

4.11. End of subscription [OMITTED]

4.12. Key escrow and recovery [OMITTED]

4.12.1. Key escrow and recovery policy and practices [OMITTED]

4.12.2. Session key encapsulation and recovery policy and practices

[OMITTED]

5. Facility, Management, And Operational Controls

5.1. Physical controls

5.1.1. Site location and construction

Operations for the APNIC RPKI CA and RA are conducted within a physically protected area of an office building in which APNIC is a tenant. This building is located at 33 Park Road, Brisbane. APNIC space within this facility includes offices and meeting spaces and two machine rooms. The APNIC CA system (including CA and RA computers and cryptographic modules) is in machine room 1.

5.1.2. Physical access

The APNIC CA systems are protected by two levels of physical security. Only APNIC staff have access to APNIC space within the building and only APNIC system administrators have access to the machine room where the CA systems reside. A receptionist is on duty at the main entrance during normal business hours (9 AM to 5:30 PM, M-F, except Australian holidays). APNIC staff are issued key cards that grant access to the APNIC space at any time. APNIC staff authorized for CA roles as noted in 5.2.1 are granted separate access to the space that houses the CA systems.

5.1.3. Power and air conditioning

The APNIC CA computers and cryptographic module are powered by a UPS (uninterruptible power supply) system. This system is capable of providing brief support for the CA system and the cryptographic module in the event of loss of municipal power. APNIC The room containing this equipment makes use of HVAC (heating/ventilation/air conditioning) systems to control temperature and relative humidity.

5.1.4. Water exposures

Machine room 1 is located in the first level (one level above the ground floor) of the building noted in 5.1.1. There is no history of flooding in this area of Brisbane that has reached the elevation of the this level of the building.

5.1.5. Fire prevention and protection

Fire suppression for machine room-1 is provided by portable CO2 extinguishers.

5.1.6. Media storage

All media containing production software and data for the CA and RA functions, plus audit logs, are stored within APNIC facilities. Data software on disk is backed up to a separate disk drives daily. Incremental backup to tape is also performed daily. Access to the backup disks (and tapes) is restricted to staff who have been granted access to the machine rooms. Logical access control to the disk backup is effected via user accounts restricted to staff members responsible for computer system operation.

5.1.7. Waste disposal

Sensitive documents and materials associated with operation of this CA are shredded before disposal. Data on the unusable computers is erased using a software package that overwrites the disk. Cryptographic devices are physically destroyed or zeroized in accordance the manufacturer’s guidance prior to disposal.

5.1.8. Off-site backup

APNIC performs continuous, offsite backups of critical system data, audit log data, and other information via network-accessible storage. Within 24 hours, all critical data will be sent to the online, offsite backup facility. Offsite backup media (tape) are held by a company specializing in secure offsite media storage.

5.2. Procedural controls

5.2.1. Trusted roles

Two trusted roles are defined for managing the APNIC RPKI CAs:

• CA administrator: has full access to the CA server and the associated cryptographic module.
• CA supervisor: has a limited access to the CA server to produce various reports.

5.2.2. Number of persons required per task

APNIC assigns two individuals to each role, a primary and a backup. There is no overlap among the individuals assigned to these roles, i.e., there are four distinct individuals staffing the two roles cited in 5.2.1. The staff fulfilling these roles may be shared across the two CAs (offline and production), but no single individual will fulfill the same role for both CAs.

5.2.3. Identification and authentication for each role

For the production CA, access is controlled via password-protected login over a SSH-protected connection via the APNIC back-office LAN.

The offline CA server is a laptop computer stored with the offline CA cryptographic module in a secure container. Only individuals filling the CA supervisor role have physical access to the server and cryptographic module for this CA. Only individuals filling the CA administrator role have logical access (password-protected login) to the CA server and cryptographic module.

5.2.4. Roles requiring separation of duties

The CA administrator and CA supervisor roles require separation of duties.

5.3. Personnel controls

5.3.1. Qualifications, experience, and clearance requirements

Only full-time APNIC staff may fulfill the trusted roles described in #### 5.2.1. Staff members are assigned to the roles only if supervisory personnel deem them to be sufficiently trustworthy and only after they have undergone in-house training for the role.

5.3.2. Background check procedures

All APNIC staff undergo normal employment reference checks.

5.3.3. Training requirements

APNIC provides its CA staff with training upon assignment to a CA role as well as on-the-job training as needed to perform job responsibilities competently. APNIC maintains records of such training and periodically reviews and enhances its training programs as necessary.

5.3.4. Retraining frequency and requirements

APNIC provides refresher training and updates for CA personnel to the extent and frequency required to ensure that such personnel maintain the required level of proficiency to perform their job responsibilities competently.

5.3.5. Job rotation frequency and sequence

There are no requirements for enforced job rotation among staff fulfilling trusted CA roles.

5.3.6. Sanctions for unauthorized actions

If APNIC RPKI CA staff are determined to have performed activities inconsistent with APNIC RPKI policies and procedures, appropriate disciplinary actions will be taken.

5.3.7. Independent contractor requirements

No independent contractor or consultant is used to perform APNIC RPKI CA roles. Contractors who are needed to perform any maintenance functions on CA severs or cryptographic modules must be escorted and directly supervised by APNIC staff at all times when in sensitive areas, e.g., machine room 1.

5.3.8. Documentation supplied to personnel

Training for staff assigned to a trusted CA role is primarily via mentoring. An internal Twiki is maintained by APNIC staff as a further training aid.

5.4. Audit logging procedures

5.4.1. Types of events recorded

Audit records are generated for the basic operations of the CA servers. Audit records include the date, time, responsible user, and summary content data relating to the event. Messages requesting CA actions, i.e., certificate requests and certificate revocation requests, are logged. The cryptographic modules maintain internal logs of operations they perform, although these records do not maintain user ID info.

The physical access control system separately maintains logs for access to the areas housing sensitive CA equipment, i.e., machine room ## 1.

5.4.2. Frequency of processing log

Audit logs are examined on at least a weekly basis for significant security and operational events. In addition, APNIC reviews its audit logs for suspicious or unusual activity in response to alerts generated based on irregularities and incidents within APNIC CA and RA systems

5.4.3. Retention period for audit log

Audit logs are retained onsite for at least 6 months after processing.

5.4.4. Protection of audit log

No special, additional protection is afforded audit logs relative to other, sensitive CA data.

5.4.5. Audit log backup procedures

The offsite backup capabilities described in 5.1.8 apply to audit logs and extend the retention to 2 years.

5.4.6. Audit collection system (internal vs. external) [OMITTED]

5.4.7. Notification to event-causing subject [OMITTED]

5.4.8. Vulnerability assessments

APNIC employs an outside firm to perform periodic vulnerability assessments for computer and network systems. These reports are provided to the APNIC security manager and to the APNIC Director General.

5.5. Records archival [OMITTED]

5.5.1. Types of records archived [OMITTED]

5.5.2. Retention period for archive [OMITTED]

5.5.3. Protection of archive [OMITTED]

5.5.4. Archive backup procedures [OMITTED]

5.5.5. Requirements for time-stamping of records [OMITTED]

5.5.6. Archive collection system (internal or external) [OMITTED]

5.5.7. Procedures to obtain and verify archive information [OMITTED]

5.6. Key changeover

The APNIC production CA key pair changes on a scheduled basis. In anticipation of this rekey activity, APNIC reissues all of the certificates issued under the old key prior to expiration of the old certificate. APNIC then creates a new key pair, and acquires and publishes a new certificate containing the new public key, a minimum of 1 week in advance of the scheduled rekey. Once the new CA certificate has been published, no more certificates are issued under the old CA key. The CA continues to issue CRLs under the old key until the old certificate expires.

5.7. Compromise and disaster recovery [OMITTED]

5.7.1. Incident and compromise handling procedures [OMITTED]

5.7.2. Computing resources, software, and/or data are corrupted [OMITTED]

5.7.3. Entity private key compromise procedures [OMITTED]

5.7.4. Business continuity capabilities after a disaster [OMITTED]

5.8. CA or RA termination

APNIC has been granted sole authority by IANA to manage allocation of IP address space and AS number resources in the Asia-Pacific region. APNIC has established the RPKI for its region consistent with this authority. There are no provisions for termination and transition of the CA function to another entity.

6. Technical Security Controls

This section describes the security controls used by APNIC.

6.1. Key pair generation and installation

6.1.1. Key pair generation

For the production and CAs operated by APNIC, key pairs are generated using a hardware cryptographic module. The module used for this purpose is certified as complying with FIPS 140-2 level 3. The hardware cryptographic module employed for this process is the SafeNet Luna SA (PIN Entry Device Authentication).

APNIC takes no responsibility for (and imposes no requirements upon) key pair generation performed by members who submit public keys for certificate issuance under the RPKI.

6.1.2. Private key delivery to subscriber

APNIC does not generate key pairs for subscribers and thus makes no provisions for delivery of private keys.

6.1.3. Public key delivery to certificate issuer

Subscribers deliver public keys to the APNIC RPKI CA by use of the RFC6492 protocol as described in [RFC6492].

6.1.4. CA public key delivery to relying parties

CA public keys for all entities other than RIRs are contained in certificates issued by other CAs. These certificates plus certificates used to represent inter-RIR transfers of address space or AS numbers are published via a repository system. Relying parties may download these certificates from this system. Public key values and associated data for the trust anchors (RIRs) are distributed out of band, e.g., embedded in path validation software that will be made available to the Internet community.

6.1.5. Key sizes

APNIC CAs use an RSA key of 2048 bits. For NIR certificates signed by APNIC, the RSA keys will be 2048 bits. For subscriber and LIR/ISP certificates, the RSA keys will be between 1024 an 2048 bits.

6.1.6. Public key parameters generation and quality checking

The RSA algorithm [RSA] is used in this PKI with the public exponent (e) F4 (65,537).

Subscribers are responsible for key pair generation, and are responsible for performing checks on the quality of their key pairs. APNIC is not responsible for performing such checks for subscribers.

6.1.7. Key usage purposes (as per X.509 v3 key usage field)

The Key usage extension bit values is consistent with RFC 3280. For APNIC’s CA certificates, the keyCertSign and cRLSign bits are set TRUE. All other bits (including digitalSignature) are set FALSE, and the extension is marked critical.

6.2. Private Key Protection and Cryptographic Module Engineering

Controls

6.2.1. Cryptographic module standards and controls

The APNIC CA employs a cryptographic module evaluated under FIPS

6.2.2. Private key (n out of m) multi-person control

Activation of the private key for offline CA requires two-party control. The cryptographic modules for the offline CA is stored in a secure container. The CA supervisor has the combination (or key) to the container, while the CA administrator has the password to activate the cryptographic module. Access to the private key for this CA, for key recovery purposes also required two-party control, as described in #### 6.2.4 below.

Activation of the private key for the production CA also requires two-party control, which is effected through use of the SafeNet Luna PED.

6.2.3. Private key escrow

No private key escrow procedures are required for this PKI.

6.2.4. Private key backup

APNIC creates backup copies of CA private keys for both routine and disaster recovery purposes. Such keys are stored within two password-protected Luna SA Backup tokens. One token is stored onsite in a security container, and the other is stored offsite. Two party control for access to backed-up private keys is effected using the same procedure described in 6.2.2. A password (separate from the cryptographic module administrator password) is used to enable encryption of the backup copy of the private key. This password is held by the CA Administrator.

6.2.5. Private key archival

There will be no archive of private keys by this CA.

6.2.6. Private key transfer into or from a cryptographic module

The private keys for APNIC’s CA are generated by the cryptographic module specified in 6.2.1. The private keys will never leave the module except in encrypted form for backup and/or transfer to a new module.

6.2.7. Private key storage on cryptographic module

The private keys for APNIC’s CA are stored in the cryptographic module and will be protected from unauthorized use in accordance with the FIPS 140-2 requirements applicable to the module. (See [FIPS])

6.2.8. Method of activating private key

Activation of either the production or offline CA private key requires use of the CA administrator password, as well as password used to initiate a secure connection to the cryptographic module.

6.2.9. Method of deactivating private key

The production CA cryptographic module normally will operate in an unattended mode, on a 24/7 basis, after activation.

The offline CA cryptographic module, when activated, will not be left unattended. When not in use, the module will be deactivated and stored securely, as described in 5.1. Deactivation requires use of the CA administrator password.

6.2.10. Method of destroying private key

When either the offline or production CA keys are superceded, or upon cessation of operations, APNIC will destroy the old CA private keys. Destruction is effected using the zeroization function of the hardware cryptographic modules to ensure that there are no residual remains of the key that could lead to the reconstruction of the key.

6.2.11. Cryptographic Module Rating

The cryptographic module(s) used by APNIC for the offline and production RPKI CAs are certified under FIPS 140-2, at level 3 [FIPS].

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 APNIC CA’s key pair has a validity interval of 10 years.

6.4. Activation data

6.4.1. Activation data generation and installation

Passwords are used to activate the cryptographic modules for both the production and offline CAs. They are generated and installed in the same fashion. Each password is generated by the trusted individual serving in the role. Each password is entered by the individual directly into the cryptographic module, via a serial interface to the module, upon module initialization.

6.4.2. Activation data protection

An APNIC staff member filling a trusted role for a CA memorizes the cryptographic module password he/she uses to perform the operations associated with the role. The staff member also memorizes the password used to activate the key used to secure communication between the CA server and the cryptographic module.

6.4.3. Other aspects of activation data

None

6.5. Computer security controls

6.5.1. Specific computer security technical requirement

APNIC ensures that the systems maintaining CA software and data files are trustworthy. This is achieved by the use of operating systems controls on access to systems as a whole, applicationspecific controls, regular periodic maintenance, and application of advised bug fixes and patches. CA systems are connected to internal networks protected via firewalls, or operated as offline systems where applicable.

These systems are secured from unauthorized access and are logically separated from other computers used for other APNIC operations. Access authorization is local to the CA machines and does not depend on any network-based, third-party agents. User authentication is based on use of tightly managed passwords (with mandated character set diversity and 6-month change cycles) or challenge-response tokens. Logical separation of the CA systems from other APNIC systems is achieved through use of network protocol filtering, ACLs, and switch configuration.

6.5.2. Computer security rating [OMITTED]

6.6. Life cycle technical controls

6.6.1. System development controls

CA system software that was not acquired externally, was developed by APNIC staff (not by contractors).

APNIC software development follows an ‘agile’ methodology which includes test driven development. All software is developed and maintained under a revision control system and releases are tagged. Code is subject a code review during development. APNIC software development uses bug and issue tracking software for all software development. Prior to release, code is packaged and deployed to a standalone platform for integration tests. Deployment to the production systems is from the same packages used for integration tests. Code deployment is scheduled during known maintenance windows, with post-deployment (live) testing and back-out planning and is performed by APNIC operations staff. Externally visible issues in deployed systems are tracked using a ticketing system in the operations and software contexts.

6.6.2. Security management controls

Cryptographic module and associated host access control is isolated from the general APNIC LDAP access control framework. The RPKI engine is in the general APNIC LDAP access control but has a specific group limiting access, and network login is disabled.

RPKI front end is in the general APNIC LDAP access control but has a specific group limiting access. The cryptographic module and associated host have specific ACLs limiting network access to the RPKI host on the web service port. Outbound ACLs are limited to the security audit, backup, and systems management and maintenance tasks.

Access to the RPKI systems is audited, and logged. These logs are exported to a separate system maintained by the APNIC security officer, for later processing and review.

6.6.3. Life cycle security controls

Software and hardware used for the RPKI was acquired through normal APNIC commercial purchasing procedures. The cryptographic module hardware is acquired on an as-needed basis from suppliers who specialize in FIPS compliant systems. Support contracts are maintained with suppliers to facilitate software maintenance.

Host operating systems are maintained to current patch levels and CERT and other security advisories are tracked for relevant vulnerabilities.

Hosts and network infrastructure are physically maintained and replaced in duty cycle averaging 3 years. Onsite maintenance contracts cover normal business hours support for this hardware.

Software release to deployed services is scheduled, with planned back-out, and post-deployment testing of service. Computers supporting the CA functions are attached physical, and logical networks after consideration of security risks. ACLs are used to limit inter-network segment traffic as needed.

6.7. Network security controls

APNIC performs all its CA and RA operations using a secured network to prevent unauthorized access and other malicious activity. APNIC protects communications of sensitive information through the use of encryption and digital signatures. Communications are protected by at least one of TLS/SSL with client and server certificates, and with SSH version 2 with 1024-bit keys, or better. Offline communications are secured through use of signed objects on physical media.

6.8. Time-stamping

The RPKI operated by APNIC does not make use of time stamping.

7. Certificate and CRL Profiles

Please refer to the Certificate and CRL Profile [RFC6487].

7.1. Certificate profile [OMITTED]

7.1.1. Version number(s) [OMITTED]

7.1.2. Certificate extensions [OMITTED]

7.1.2.1. Required certificate extensions [OMITTED]

7.1.2.2. Deprecated certificate extensions [OMITTED]

7.1.2.3. Optional certificate extensions [OMITTED]

7.1.3. Algorithm object identifiers [OMITTED]

7.1.4. Name forms [OMITTED]

7.1.5. Name constraints [OMITTED]

7.1.6. Certificate policy object identifier [OMITTED]

7.1.7. Usage of Policy Constraints extension [OMITTED]

7.1.8. Policy qualifiers syntax and semantics [OMITTED]

7.1.9. Processing semantics for the critical Certificate Policies

extension [OMITTED] ### 7.2. CRL profile [OMITTED] #### 7.2.1. Version number(s) [OMITTED] #### 7.2.2. CRL and CRL entry extensions [OMITTED] ##### 7.2.2.1. Required CRL extensions [OMITTED] ##### 7.2.2.2. Deprecated CRL extensions [OMITTED] ##### 7.2.2.3. Optional CRL extensions [OMITTED] ### 7.3. OCSP profile [OMITTED] #### 7.3.1. Version number(s) [OMITTED] #### 7.3.2. OCSP extensions [OMITTED]

8. Compliance Audit and Other Assessments

APNIC employs an outside firm to perform periodic vulnerability assessments for computer and network systems, including those that are part of the RPKI CA.

APNIC will not engage an entity to perform a CA compliance audit.

8.1. Frequency or circumstances of assessment

Assessments are initiated at the behest of the Security Officer.

8.2. Identity/qualifications of assessor

The outside firm engaged to perform the assessment is a commercial entity specializing in IT security assessment.

8.3. Assessor’s relationship to assessed entity

The outside firm engaged to perform the assessment is a paid contractor with no other relationships to APNIC.

8.4. Topics covered by assessment

The external vulnerability assessment perform on APNIC IT systems cover a variety of topics including (but not limited to) network port scanning, testing of web application interfaces, review of user authentication and authorization mechanisms, logging and auditing, network security, and configuration management.

8.5. Actions taken as a result of deficiency

The APNIC Security Officer reviews all recommendations made by the external assessor and takes remedial actions as appropriate.

8.6. Communication of results

The external vulnerability assessment reports are provided to the APNIC Security Officer and to the APNIC Director General.

9. Other Business And Legal Matters

9.1. Fees

9.1.1. Certificate issuance or renewal fees

Certificate issuance and renewal fees may be charged by APNIC. Fees are set from time to time by the Executive Council of APNIC. The current schedule of fees are published on the APNIC web site.

9.1.2. Fees for other services (if applicable)

APNIC charges fees for other services related to the allocation and administration of IP address and Autonomous System number resources. Fees are set from time to time by the Executive Council of APNIC. The current schedule of fees are published on the APNIC web site.

9.1.3. Refund policy [OMITTED]

9.2. Financial responsibility [OMITTED]

9.2.1. Insurance coverage [OMITTED]

9.2.2. Other assets [OMITTED]

9.2.3. Insurance or warranty coverage for end-entities [OMITTED]

9.3. Confidentiality of business information [OMITTED]

9.3.1. Scope of confidential information [OMITTED]

9.3.2. Information not within the scope of confidential information

[OMITTED] #### 9.3.3. Responsibility to protect confidential information [OMITTED] ### 9.4. Privacy of personal information [OMITTED] #### 9.4.1. Privacy plan [OMITTED] #### 9.4.2. Information treated as private [OMITTED] #### 9.4.3. Information not deemed private [OMITTED] #### 9.4.4. Responsibility to protect private information [OMITTED] #### 9.4.5. Notice and consent to use private information [OMITTED] #### 9.4.6. Disclosure pursuant to judicial or administrative process [OMITTED] #### 9.4.7. Other information disclosure circumstances [OMITTED]

9.5. Intellectual property rights (if applicable)

APNIC’s intellectual property (agreements, documents, software, databases, website, etc.) may only be used, reproduced and made available to third parties upon prior written authorisation from APNIC.

9.6. Representations and warranties [OMITTED]

9.6.1. CA representations and warranties [OMITTED]

9.6.2. Subscriber representations and warranties [OMITTED]

9.6.3. Relying party representations and warranties [OMITTED]

9.6.4. Representations and warranties of other participants [OMITTED]

9.7. Disclaimers of warranties [OMITTED]

9.8. Limitations of liability

Download of the Repository, access and use of the data contained therein, and use of the service is at the User’s own risk entirely.

The Certificate holder is liable for all aspects of the use of the Certificate and the creation of RPKI signed objects.

APNIC is not liable for any direct or indirect damages, including but not limited to, damages to the User’s business, loss of profit, damages to third parties, personal injury or damages to property, except in cases involving willful misconduct on the part of APNIC.

Users are responsible for making decisions based on the latest version of the Repository. APNIC is not liable for any decisions made based on an outdated version of the Repository.

Without reducing the effect of the previous paragraphs:

APNIC is not liable for non-performance or damages due to force majeure (including but not limited to industrial action, strikes, occupations and sit-ins, blockades, embargoes, governmental measures, denial of service attacks, war, revolutions or comparable situations, power failures, defects in electronic lines of communication, fire, explosions, damage caused by water, floods and earthquakes).

APNIC is not liable in the case that local legislation prohibits the use of any technical aspects of the Repository, service or the data contained therein.

Any right on the part of the User towards APNIC in connection with the download of the Repository, the service and the access and use of the data contained therein shall finally and unconditionally lapse one year from the date on which the User became aware of (or could in all fairness have been aware of) the existence of such rights and entitlements. This one-year term can only be barred or interrupted by actual legal action instituted by the User against APNIC.

9.9. Indemnities [OMITTED]

9.10. Term and termination [OMITTED]

9.10.1. Term [OMITTED]

9.10.2. Termination [OMITTED]

9.10.3. Effect of termination and survival [OMITTED]

9.11. Individual notices and communications with participants [OMITTED]

9.12. Amendments [OMITTED]

9.12.1. Procedure for amendment [OMITTED]

9.12.2. Notification mechanism and period [OMITTED]

9.12.3. Circumstances under which OID must be changed [OMITTED]

9.13. Dispute resolution provisions [OMITTED]

9.14. Governing law

These Terms and Conditions shall be exclusively governed by the laws of Queensland, Australia. The competent court in Queensland, Australia has exclusive jurisdiction with regard to disputes arising from these Terms and Conditions.

9.15. Compliance with applicable law

If any provision contained in the Terms and Conditions is held to be invalid by a court of law, this shall not in any way affect the validity of the remaining provisions.

9.16. Miscellaneous provisions

Anyone is able to download, access or use the Repository and the data contained therein, to the extent permitted by these Terms and Conditions and provided these Terms and Conditions are followed. By downloading the Repository and accessing and using the data contained therein, the User agrees to be bound by these Terms and Conditions.

Users are permitted to download the Repository and to access the service and use the data contained therein, in order to validate Certificates, CRLs and RPKI-signed objects.

Download of the Repository, access to or use of the service and data contained therein for any other purpose, including but not limited to identification purposes, advertising, direct marketing, marketing research or similar purposes, is not permitted.

The use of the Certificate does not support claims of alleged “ownership” of Internet number resources. Internet number resources registered by APNIC are subject to and exclusively governed by the policies adopted by the APNIC community.

Users should always check revocation information when using a Certificate or RPKI-signed object and should always ensure that they are using the latest version of the Repository, which is updated every effort basis and APNIC may suspend its operation or liability to the User for technical, legal, anti-abuse or any other reasons within the scope of managing the operations of the Repository.

9.16.1. Entire agreement [OMITTED]

9.16.2. Assignment [OMITTED]

9.16.3. Severability [OMITTED]

9.16.4. Enforcement (attorneys’ fees and waiver of rights) [OMITTED]

9.16.5. Force Majeure

9.17. Other provisions [OMITTED]

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC3280] Housley, R., Polk, W. Ford, W., Solo, D., “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, BCP 14, RFC 2119, March 1997.

[RFC6484] Seo, K., Watro, R., Kong, D., and Kent, S. , “Certificate Policy for the Internet IP Address and AS Number PKI”, work in progress, July 2007.

[RFC6487] Huston, G., Loomans, R., Michaelson, G., “A Profile for X.509 PKIX Resource Certificates”, work in progress, June

[RFC6487] Huston, G., Loomans, R., Michaelson, G., “A Profile for X.509 PKIX Resource Certificates”.

[RFC6492] G. Houston, R. Loomans, B. Ellacott, R. Austien, “A Protocol for Provisioning Resource Certificates,”

[BGP4] Y. Rekhter, T. Li (editors), A Border Gateway Protocol 4 (BGP-4). IETF RFC4271, March 1995.

[FIPS] Federal Information Processing Standards Publication 140-2 (FIPS PUB 140-2), “Security Requirements for Cryptographic Modules”, Information Technology Laboratory, National Institute of Standards and Technology, May 25, 2001.

[RSA] Rivest, R., Shamir, A., and Adelman, L. M. 1978. A method for obtaining digital signatures and public-key cryptosystems. Commun. ACM 21, 2 (Feb.), 120-126.