1 Introduction

The Asia Pacific Grid Policy Management Authority (hereafter called APGrid PMA) provides the minimum requirements for traditional online PKI CAs. The PMA specifies two levels of the minimum requirements, one is for experimental CAs and the other is for production CAs. An experimental CA is considered as an alternative of the Globus CA and it will be accepted within Asia for experimental use. For production runs and international collaboration, any CA must satisfy the minimum requirements for production CAs.

In this document, the key words "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may", and "optional" are to be interpreted as described in RFC 2119.

The minimum requirements for Production CA are based on "Profile for Traditional X.509 Public Key Certification Authorities with secured infrastructure Version 4.0" which is an Authentication Profile of the International Grid Trust Federation describing the minimum requirements on traditional X.509 PKI CAs. The Authentication Profile is managed by the European Grid Policy Management Authority and available from the EUGrid PMA web site at: http://www.eugridpma.org/.

2 Minimum CA Requirements for Production CA

2.1 Certification Authority

1. CP/CPS

• Every CA must have a CP/CPS
• Every CA must assign its CP/CPS an O.I.D.
• Whenever there is a change in the CP/CPS the O.I.D. of the document must change and the major changes must be announced to the APGrid PMA and approved before signing any certificates under the new CP/CPS.
• The CP/CPS must be available online such as web.

2. CA System

• The CA system must be a dedicated machine.
• The CA system must be located in a secure environment where access is controlled.
• The CA system must be professionally managed.
• The CA system must be off line or use at least a FIPS 140-2 level 3 Hardware Security Module or equivalent to protect the private key of CA.
• The secure environment must be documented that are available to the PMA.

3. CA Key

• The CA key must have a minimum length of 2048 bits
• The private key of every CA must be protected with a pass phrase of at least 15 elements.
• The pass phrase must be known by specific personnel of the CA.
• Copies of the encrypted private key must be kept on offline mediums in secure places where access is controlled.

4. CA Certificate

• Lifetime of the CA certificate must be no longer than 20 years.
• Lifetime of the CA certificate must be no less than two times of the maximum life time of an end entity certificate.
• The CA certificate must have the extensions keyUsage and basicConstraints marked as critical.
• Value of x509 Basic Constraints must be CA:TRUE
• Value of x509 Key Usage must include at least
• keyCertSign, cRLSign

5. CA Namespace

• Each CA must only assign a namespace that does not clash with any other CA.

6. Certificate Revocation

• Certificate revocation can be requested by users, the registration authorities, and the CA.
• The revocation request must be sent via a secure method such as signed email.
• End entity must request revocation of its certificate if
• he lost or compromised the private key.
• the data in the certificate are no longer valid.
• Revocation requests must be properly authenticated.

7. Certificate Revocation List (CRL)

• Every CA must generate CRLs.
• The CRL lifetime must be no more than 30 days.
• Every CA must issue a new CRL at least 7 days before expiration.
• Every CA must issue a new CRL immediately after a revocation.
• The signed CRL must be published in a repository at least accessible via a Web.
• The repository must be run at least on a best-effort basis, with an intended availability of 24x7.
• The CRLs must be compliant with RFC3280, and can be either version 1 or version 2.
• The message digests of the certificates and CRLs must be generated by a trustworthy mechanism, like SHA1 (in particular, MD5 must not be used).

8. End Entity Certificates and keys

• The user key and the host key must have a minimum length of 1024 bits.
• Lifetime of the user certificate and the host certificate must be no longer than 13 months.
• Any user certificates must not be shared.
• Each host certificate must be linked to a single network entity.
• Every user must generate his private key and must keep this private and secure.
• Every CA should make a reasonable effort to make sure that end-entities realize the importance of properly protecting their private data. It's upon the user to protect user's private key with a pass phrase at least 12 characters long. It's also upon the user to protect host's and service's private keys by secure method if they are not protected by a pass phrase.
• The end-entity certificates must be in X.509v3 format and compliant with RFC3280 unless explicitly stated otherwise. In the certificate extensions:
• a Policy Identifier must be included and must contain an OID and an OID only
• CRLDistributionPoints must be included and contain at least one http URL
• keyUsage must be included and marked as critical
• basicConstraints should be included, and when included it must be set to 'CA: false' and marked as critical
• if an OCSP responder, operated as a production service by the issuing CA, is available, AuthorityInfoAccess must be included and contain at least one URI
• for certificates bound to network entities, a FQDN shall be included as a dnsName in the SubjectAlternativeName
• If a commonName component is used as part of the subject DN, it should contain an appropriate presentation of the actual name of the end-entity.

9. Records Archival

• Every CA must record and archive all requests for certificates, along with all the issued certificates, all the request for revocation, all the issued CRLs and the login/logout/reboot of the issuing machine.
• These records must be available to external auditors in the course of their work as auditor.
• These records must be kept at least three years.

10. Audits

• Each CA must accept being audited by other accredited CAs to verify its compliance with the rules and procedures specified in its CP/CPS document.
• Every CA must perform operational audits of the CA/RA staff at least once per year.

11. Publication and Repository responsibilities

• Each authority must publish for their subscribers, relying parties and for the benefit of distribution by the PMA and the federation
• a CA root certificate or set of CA root certificates up to a self-signed root;
• a http or https URL of the PEM-formatted CA certificate;
• a http URL of the PEM or DER formatted CRL;
• a http or https URL of the web page of the CA for general information;
• the CP and/or CPS documents;
• an official contact email address for inquiries and fault reporting
• a physical of postal contact address
• The originating authority must grant to the PMA and the Federation ? by virtue of its accreditation ? the right of unlimited re-distribution of this information.

12. Privacy and confidentiality

• Accredited CAs must define a privacy and data release policy compliant with the relevant national legislation. The CA is responsible for recording, at the time of validation, sufficient information regarding the subscribers to identify the subscriber. The CA is not required to release such information unless provided by a valid legal request according to national laws applicable to that CA.

13. Compromise and disaster recovery

• The CA must have an adequate compromise and disaster recovery procedure, and we willing to discuss this procedure in the PMA. The procedure need not be disclosed in the policy and practice statements.

2.2 Registration Authority

1. Entity Identification

• In order for an RA to validate the identity of a person, the subject must contact the RA personally and present photo-id and/or valid official documents showing that the subject is an acceptable end entity as defined in the CP/CPS document of the CA.
• In case of host or service certificate requests, the CSR must be delivered to the RA by the person in charge of the specific entities using a secure method.

2. Name Uniqueness

• The subject name listed in a certificate must be unambiguous and unique for all certificates issued to the same entity by the CA.

3. RA to CA communications

• The RA must communicate with the CA with secure methods that are clearly defined in the CP/CPS. (e.g. signed emails, voice conversations with a known person, or some other acceptable method)

4. Records and Archival

• The RA must record and archive all requests and confirmations.

3 Minimum CA Requirements for Experimental CA

3.1 Certification Authority

1. CA System

• The CA system must be a dedicated machine.
• The CA system must be located in a secure environment where access is controlled.
• The CA system must be professionally managed.

2. CA Key

• The CA key must have a minimum length of 1024 bits
• The pass phrase must be known by specific personnel of the CA.

3. CA Certificate

• Lifetime of the CA certificates must be no longer than 5 years.

4. CA Namespace

• Each CA must only assign a namespace that does not clash with any other CA.

5. Certificate Revocation

• Certificate revocation can be requested by users or the registration authorities.
• End entity must request revocation of its certificate if
• he lost or compromised the private key.
• he left organization

6. Certificate Revocation List (CRL)

• Every CA must generate CRLs.
• The CRL lifetime must be no more than 90 days.
• Every CA must issue a new CRL immediately after a revocation.
• The CRLs must be published in a repository at least accessible via a Web.
• The repository must be run at least on a best-effort basis, with an intended availability of 24x7.

7. End Entity Certificates and keys

• The user key and the host key must have a minimum length of 1024 bits.
• Lifetime of the user certificate and the host certificate must be no longer than 1 year.
• Each host certificate must be linked to a single network entity.
• Every user must generate his private key and must keep this private and secure.

3.2 Registration Authority

1. Entity Identification

• The RA can validate the identity by any method which is described in CP/CPS.

2. Name Uniqueness

• The subject name listed in a certificate must be unambiguous and unique for all certificates issued to the same entity by the CA.