Minimum CA Requirements

Here we discuss the minimum requirements for traditional online PKI CAs. These have evolved over a period of three years in an iterative discursive fashion largely as a result of the numerous difficulties that arise when interoperating between different linguistic, administrative, networking and security domains as occur over national boundaries. In this section, the key words `must', `must not', `required', `shall', `shall not', `should', `should not', `recommended', `may', and `optional' in this document are to be interpreted as described in RFC 2119.

1          PKI Structure

Due to certain idiosyncrasies of the Grid middleware, the PKI structure within each country should should not follow the conventional hierarchical model, where there is a chain of CAs. The model followed simulates the hierarchical model , but there should by having be one a single Certification Authority (CA) per country or , large region (5-20M people) or international organization. and aA wide network of Registration Authorities (RA) for each CA is preferred. The RAs will handle the tasks of validating the identity of the end entities and authenticating their requests, which will then be forwarded at to the national/regional CA. The CA will handle the actual tasks of issuing CRLs, signing Certificates/CRLS and revoking Certificates when necessary.

2          Certification Authority

2.1        Computer Security Controls

The CA computer, where the signing of the certificates will take place, needs to be a dedicated machine, running no other services than those needed for the CA operations. The CA computer must be located in a secure environment where access is controlled, limited to specific trained personnel and must be kept disconnected from any kind of networks at all times. In case the CA computer is equipped with at least a FIPS 140-1 level 3 Hardware Security Module or equivalent , to protect the CAs private key, the CA computer can be connected to a highly protected/monitored network, possibly accessible from the Internet. The secure environment must be documented that are available to the PMA.

2.2        CA Namespace

Each CA must sign only a well defined namespace that does not clash with any other CA.

2.3        Policy Document & Identification

Every CA must have a Certification Policy and Certificate Practice Statement (CP/CPS Document) and assign it 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 euGridPMA for and approvedal before signing any certs under the new CP/CPs. All the CP/CPS under which valid certs are issued MUST be available on the web.

2.4        CA Key

The CA Key must have a minimum length of 2048 bits and for CAs that issue end-entity certificates the a lifetime must be no longer of 5 years and no less than two times of the maximum life time of an end entity certificate.

The private key of the CA must be protected with a pass phrase of at least 15 elements which is known only by specific personnel of the Certification Authority. Copies of the encrypted private key must be kept on offline mediums in secure places where access is controlled.

The pass phrase of the encrypted private must be kept also on an offline medium, separated from the encrypted keys and guarded in a safe place where only the autorized personnel of the Certification Authority have access.

2.5        CA Certificate

The CA certificate must have the extensions keyUsage and basicConstraints marked as critical.

2.6        CRLs

The maximum CRL lifetime must be at most 30 days and the CA must issue a new CRL at least 7 days before expiration and immediatelly after a revocation. The CRLS must be published in a repository at least accessible via the World Wide Web, as soon as issued.

2.7        Records Archival

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

2.8        Key changeover

The CA's private signing key must be changed periodically; from that time on only the new key will be used for certificate signing purposes. The overlap of the old and new key must be at least the longest time an end-entity cert can be valid.The period of changing the CAs private key must not be longer than the CA Key lifetime minus the maximum life time of an end entity certificate. The older , but still valid certificate, must be available to verify old signatures and the secret key to sign CRLs until all the certificates signed using the associated private key have also expired.

2.9        Repository

The repository must be run at least on a best-effort basis, with an intended availability of 24x7.

2.10   Compliance Audits

Each CA must accept being audited by other trusted accredited CAs to verify its compliance with the rules and procedures specified in its CP/CPS document.

2.11   Operational Audits

The CA must perform operational audits of the CA/RA staff at least once per year.

3          Registration Authority

3.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 be delivered to the RA by the person in charge of the specific entities using a secure method.

3.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.3        Records and Archival

The RAs must record and archive all requests and confirmations.

3.4        RA Obligations

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, SSL protected private web pages that are bi-directionally authenticated)

4          End Entity Certificates

The EE keys must be at least 1024 bits long and must not be generated by the CA or the RA. The EE certificates must have a maximum lifetime of 1 year and must not be shared among end entities. The EE certificate must contain information to identify which CP/CPS was used to issue the certificate (e.g. OID or by date). The extensions basicConstraints and keyUsage must be marked as critical and the basicConstraints must be set to CA: False.

The CA should make a reasonable effort to make sure that end-entities realize the importance of properly protecting their private data. Its upon the user to protect his private key with a pass phrase at least 12 characters long.