Certification Practice Statement (CPS)

The APNIC “Certification Practice Statement” (CPS) is published as a PDF document, bound into every RPKI Certificate

View The Certification Practice Statement in PDF format

The PDF above is the canonical text of our operating terms and conditions, but we also provide the text of the CPS below if you wish to read it in the web

APNIC Certification Practice Statement
for the Resource PKI

Table of Contents

1. Introduction 9

1.1. Overview 9

1.2. Document name and identification 10

1.3. PKI participants 10

1.3.1. Certification authorities 11

1.3.2. Registration authorities 11

1.3.3. Subscribers 11

1.3.4. Relying parties 11

1.3.5. Other participants 12

1.4. Certificate usage 12

1.4.1. Appropriate certificate uses 12

1.4.2. Prohibited certificate uses 12

1.5. Policy administration 12

1.5.1. Organization administering the document 12

1.5.2. Contact person 12

1.5.3. Person determining CPS suitability for the policy 12

1.5.4. CPS approval procedures 13

1.6. Definitions and acronyms 13

2. Publication And Repository Responsibilities 14

2.1. Repositories 14

2.2. Publication of certification information 14

2.3. Time or Frequency of Publication 14

2.4. Access controls on repositories 14

3. Identification And Authentication 15

3.1. Naming 15

3.1.1. Types of names 15

3.1.2. Need for names to be meaningful 15

3.1.3. Anonymity or pseudonymity of subscribers 15

3.1.4. Rules for interpreting various name forms 15

3.1.5. Uniqueness of names 15

3.1.6. Recognition, authentication, and role of trademarks 15

3.2. Initial identity validation 16

3.2.1. Method to prove possession of private key 16

3.2.2. Authentication of organization identity 16

3.2.3. Authentication of individual identity 16

3.2.4. Non-verified subscriber information 16

3.2.5. Validation of authority 16

3.2.6. Criteria for interoperation 16

3.3. Identification and authentication for re-key requests 17

3.3.1. Identification and authentication for routine re-key17

3.3.2. Identification and authentication for re-key after revocation 17

3.4. Identification and authentication for revocation request 17

4. Certificate Life-Cycle Operational Requirements 18

4.1. Certificate Application 18

4.1.1. Who can submit a certificate application 18

4.1.2. Enrollment process and responsibilities 18

4.2. Certificate application processing 18

4.2.1. Performing identification and authentication functions

4.2.2. Approval or rejection of certificate applications 18

4.2.3. Time to process certificate applications 18

4.3. Certificate issuance 19

4.3.1. CA actions during certificate issuance 19

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

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

4.4. Certificate acceptance 19

4.4.1. Conduct constituting certificate acceptance 19

4.4.2. Publication of the certificate by the CA 19

4.5. Key pair and certificate usage 19

4.5.1. Subscriber private key and certificate usage 19

4.5.2. Relying party public key and certificate usage 20

4.6. Certificate renewal 20

4.6.1. Circumstance for certificate renewal 20

4.6.2. Who may request renewal 20

4.6.3. Processing certificate renewal requests 20

4.6.4. Notification of new certificate issuance to subscriber

4.6.5. Conduct constituting acceptance of a renewal certificate 21

4.6.6. Publication of the renewal certificate by the CA 21

4.6.7. Notification of certificate issuance by the CA to other entities [OMITTED] 21

4.7. Certificate re-key 21

4.7.1. Circumstance for certificate re-key 21

4.7.2. Who may request certification of a new public key 21

4.7.3. Processing certificate re-keying requests 22

4.7.4. Notification of new certificate issuance to subscriber 22

4.7.5. Conduct constituting acceptance of a re-keyed certificate 22

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

4.7.7. Notification of certificate issuance by the CA to other entities [OMITTED] 22

4.8. Certificate modification 22

4.8.1. Circumstance for certificate modification 22

4.8.2. Who may request certificate modification 23

4.8.3. Processing certificate modification requests 23

4.8.4. Notification of modified certificate issuance to subscriber 23

4.8.5. Conduct constituting acceptance of modified certificate 23

4.8.6. Publication of the modified certificate by the CA 23

4.8.7. Notification of certificate issuance by the CA to other entities [OMITTED] 23

4.9. Certificate revocation and suspension 23

4.9.1. Circumstances for revocation 23

4.9.2. Who can request revocation 24

4.9.3. Procedure for revocation request 24

4.9.4. Revocation request grace period 24

4.9.5. Time within which CA must process the revocation request 24

4.9.6. Revocation checking requirement for relying parties 24

4.9.7. CRL issuance frequency 24

4.9.8. Maximum latency for CRLs 24

4.9.9. On-line revocation/status checking availability [OMITTED] 25

4.9.10. On-line revocation checking requirements [OMITTED] 25

4.9.11. Other forms of revocation advertisements available [OMITTED] 25

4.9.12. Special requirements re key compromise [OMITTED] 25

4.9.13. Circumstances for suspension [OMITTED] 25

4.9.14. Who can request suspension [OMITTED] 25

4.9.15. Procedure for suspension request [OMITTED] 25

4.9.16. Limits on suspension period [OMITTED] 25

4.10. Certificate status services 25

4.10.1. Operational characteristics [OMITTED] 25

4.10.2. Service availability [OMITTED] 25

4.10.3. Optional features [OMITTED] 25

4.11. End of subscription [OMITTED] 25

4.12. Key escrow and recovery [OMITTED] 25

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

4.12.2. Session key encapsulation and recovery policy and

5. Facility, Management, And Operational Controls 26

5.1. Physical controls 26

5.1.1. Site location and construction 26

5.1.2. Physical access 26

5.1.3. Power and air conditioning 26

5.1.4. Water exposures 26

5.1.5. Fire prevention and protection 26

5.1.6. Media storage 26

5.1.7. Waste disposal 27

5.1.8. Off-site backup 27

5.2. Procedural controls 27

5.2.1. Trusted roles 27

5.2.2. Number of persons required per task 27

5.2.3. Identification and authentication for each role 27

5.2.4. Roles requiring separation of duties 28

5.3. Personnel controls 28

5.3.1. Qualifications, experience, and clearance requirements 28

5.3.2. Background check procedures 28

5.3.3. Training requirements 28

5.3.4. Retraining frequency and requirements 28

5.3.5. Job rotation frequency and sequence 28

5.3.6. Sanctions for unauthorized actions 28

5.3.7. Independent contractor requirements 29

5.3.8. Documentation supplied to personnel 29

5.4. Audit logging procedures 29

5.4.1. Types of events recorded 29

5.4.2. Frequency of processing log 29

5.4.3. Retention period for audit log 29

5.4.4. Protection of audit log 29

5.4.5. Audit log backup procedures 30

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

5.4.7. Notification to event-causing subject [OMITTED] 30

5.4.8. Vulnerability assessments 30

5.5. Records archival [OMITTED] 30

5.5.1. Types of records archived [OMITTED] 30

5.5.2. Retention period for archive [OMITTED] 30

5.5.3. Protection of archive [OMITTED] 30

5.5.4. Archive backup procedures [OMITTED] 30

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

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

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

5.6. Key changeover 30

5.7. Compromise and disaster recovery [OMITTED] 30

5.7.1. Incident and compromise handling procedures [OMITTED]30

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

5.7.3. Entity private key compromise procedures [OMITTED] . 31

5.7.4. Business continuity capabilities after a disaster [OMITTED] 31

5.8. CA or RA termination 31

6. Technical Security Controls 32

6.1. Key pair generation and installation 32

6.1.1. Key pair generation 32

6.1.2. Private key delivery to subscriber 32

6.1.3. Public key delivery to certificate issuer 32

6.1.4. CA public key delivery to relying parties 32

6.1.5. Key sizes 32

6.1.6. Public key parameters generation and quality checking32

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

6.2. Private Key Protection and Cryptographic Module Engineering Controls 33

6.2.1. Cryptographic module standards and controls 33

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

6.2.3. Private key escrow 33

6.2.4. Private key backup 33

6.2.5. Private key archival 33

6.2.6. Private key transfer into or from a cryptographic module 34

6.2.7. Private key storage on cryptographic module 34

6.2.8. Method of activating private key 34

6.2.9. Method of deactivating private key 34

6.2.10. Method of destroying private key 34

6.2.11. Cryptographic Module Rating 34

6.3. Other aspects of key pair management 35

6.3.1. Public key archival 35

6.3.2. Certificate operational periods and key pair usage periods 35

6.4. Activation data 35

6.4.1. Activation data generation and installation 35

6.4.2. Activation data protection 35

6.4.3. Other aspects of activation data 35

6.5. Computer security controls 35

6.5.1. Specific computer security technical requirement 35

6.5.2. Computer security rating [OMITTED] 35

6.6. Life cycle technical controls 36

6.6.1. System development controls 36

6.6.2. Security management controls 36

6.6.3. Life cycle security controls 36

6.7. Network security controls 37

6.8. Time-stamping 37

7. Certificate and CRL Profiles 38

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

7.1. Certificate profile [OMITTED] 38

7.1.1. Version number(s) [OMITTED] 38

7.1.2. Certificate extensions [OMITTED] 38

7.1.3. Algorithm object identifiers [OMITTED] 38

7.1.4. Name forms [OMITTED] 38

7.1.5. Name constraints [OMITTED] 38

7.1.6. Certificate policy object identifier [OMITTED] 38

7.1.7. Usage of Policy Constraints extension [OMITTED] 38

7.1.8. Policy qualifiers syntax and semantics [OMITTED] 38

7.1.9. Processing semantics for the critical Certificate Policies extension [OMITTED] 38

7.2. CRL profile [OMITTED] 38

7.2.1. Version number(s) [OMITTED] 38

7.2.2. CRL and CRL entry extensions [OMITTED] 38

7.3. OCSP profile [OMITTED] 38

7.3.1. Version number(s) [OMITTED] 38

7.3.2. OCSP extensions [OMITTED] 38

8. Compliance Audit and Other Assessments 39

8.1. Frequency or circumstances of assessment 39

8.2. Identity/qualifications of assessor 39

8.3. Assessor’s relationship to assessed entity 39

8.4. Topics covered by assessment 39

8.5. Actions taken as a result of deficiency 39

8.6. Communication of results 39

9. Other Business And Legal Matters 40

9.1. Fees 40

9.1.1. Certificate issuance or renewal fees 40

9.1.2. Fees for other services (if applicable) 40

9.1.3. Refund policy 40

9.2. Financial responsibility 40

9.2.1. Insurance coverage 40

9.2.2. Other assets 40

9.2.3. Insurance or warranty coverage for end-entities 40

9.3. Confidentiality of business information 40

9.3.1. Scope of confidential information 40

9.3.2. Information not within the scope of confidential information 40

9.3.3. Responsibility to protect confidential information . 40

9.4. Privacy of personal information 40

9.4.1. Privacy plan 40

9.4.2. Information treated as private 40

9.4.3. Information not deemed private 40

9.4.4. Responsibility to protect private information 40

9.4.5. Notice and consent to use private information 40

9.4.6. Disclosure pursuant to judicial or administrative process 40

9.4.7. Other information disclosure circumstances 41

9.5. Intellectual property rights (if applicable) 41

9.6. Representations and warranties 41

9.6.1. CA representations and warranties 41

9.6.2. Subscriber representations and warranties 41

9.6.3. Relying party representations and warranties 41

9.6.4. Representations and warranties of other participants [OMITTED] 41

9.7. Disclaimers of warranties 41

9.8. Limitations of liability 41

9.9. Indemnities 42

9.10. Term and termination 42

9.10.1. Term 42

9.10.2. Termination 42

9.10.3. Effect of termination and survival 42

9.11. Individual notices and communications with participants 42

9.12. Amendments 42

9.12.1. Procedure for amendment 42

9.12.2. Notification mechanism and period 42

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

9.13. Dispute resolution provisions 42

9.14. Governing law 42

9.15. Compliance with applicable law 42

9.16. Miscellaneous provisions 42

9.16.1. Entire agreement 43

9.16.2. Assignment 43

9.16.3. Severability 43

9.16.4. Enforcement (attorneys’ fees and waiver of rights) 43

9.16.5. Force Majeure 43

9.17. Other provisions [OMITTED] 43

10. References 44

10.1. Normative References ……. Error! Bookmark not defined.43

10.2. Informative References ….. Error! Bookmark not defined.43

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 [cp-
business-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 CO₂
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
140-2, at level 3 [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, application-
specific 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 24 hours. The Repository will be available for download on a
best 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]

10. References

[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
2007.

[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.