Guideline for New Certification Authorities

Abstract: This guideline is prepared for EUMED countries, large regions or international organizations for accreditation of their Certificate Authority. The definitions and information are gathered together from the documents of EUGRIDPMA and CAOPS WG.

1. General Definitions

EUGridPMA (http://www.eugridpma.org/)

The EUGridPMA is the international organisation to coordinate the trust fabric for e-Science grid authentication in Europe. It collaborates with the regional peers APGridPMA for the Asia-Pacific and The Americas Grid PMA in the International Grid Trust Federation. The charter document defines the group's objective, scope and operation. It is the basis for the guidelines documents on the accreditation procedures, the Authentication profile for X.509 secured “classic” certification authorities and other IGTF recognised Profiles.

EUGridPMA Charter (http://www.eugridpma.org/charter/)

The Charter defines the policies, practices, and bylaws of the European Policy Management Authority for Grid Authentication in e-Science. The Charter is owned and managed by the EUGridPMA .

Certification Authority(CA)

The entity or system that signs X.509 identity certificates.

Certificate Policy (CP)

A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements.

Certification Practice Statement (CPS)

A statement for the practices, that a certification authority applies in its operations.

Certificate Revocation List (CRL)

A time stamped list displaying revoked certificates that are signed by a CA and made freely available in a public repository.

PKI (Public Key Infrastructure)

IT infrastructure that enables users of a basically unsecured public network (such as the Internet) to securely and privately exchange data through the use of a public and a private cryptographic key pair that is obtained and shared through a trusted authority.

Private Key

In secure communication, an algorithm pattern used to encrypt message that only the corresponding public key can decrypt. The private key is also used to decrypt messages that were encrypted by the corresponding public key.

Public Key

The pattern used to confirm “signatures” on incoming messages or to encrypt a file or message so that the holder of the private key can decrypt the file or message.

Registration Authority (RA)

An entity that is responsible for identification and authentication of certificate subjects, but that does not sign or issue certificates.

Relying Party

A recipient who accepts a digital certificate and digital signature.

Subscriber

In the case of certificates issued to resources (such as web servers), the person responsible for the certificate for that resource. For certificates issued to individuals, same as certificate subject.

2. EUGridPMA CA Process (*)

2.1. Membership Request

Any community or organisation eligible for membership under the Charter of the EUGridPMA can apply for such membership by sending a request to the PMA Chair. Requests for membership may be submitted on paper or in electronic form, should contain enough information to verify eligibility of the prospective member.

The following information should be presented in the membership request:

• Name of the organisation applying for membership

• Contact information for the applying organisation, including both physical and electronic addresses

• Name and contact information of one primary and at least one alternate representative of the organisation

• Description of the constituency to be represented. For prospective Authority members, this information should include the geographical extent of the authority and the constituency served within that geographical extent, and the Authentication Profile(s) under which the authority aims to be accredited. For prospective Relying Party members, this information should include the constituency represented, as well as a rationale as to why this constituency is not already represented through the existing Authority members single or combined.

• Prospective Authority members should describe how their organisation has or will ensure appropriate and comprehensive coverage of the indicated geographical area and the target constituency therein.

By becoming member of the PMA, the organisation and its representatives understand and agree to participate in the activities of the PMA and contribute in-kind to its organisation and operations, and to the PMA processes that support the trust in the authentication infrastructure. This includes but is not limited to periodic face-to-face participation in its meetings at least annually, and meeting any on-going requirements expressed in the relevant Authentication Profiles, the PMA Charter and the IGTF Federation Document.

2.2. Accreditation Process

The PMA will accredit Authorities based on the positive outcome of an initial review with respect to all relevant guideline documents, and a successful registration process.

1. The applicant send a request for accreditation to the Chair. Once accepted by the chair in accordance with section 1 and subject to moderation, the application and acceptance and the accreditation process starts. This event is registered in the internal PMA repository and contact data posted there.

2. The Chair will ensure that the applicant representatives are subscribed to the relevant communications media, including the PMA discussion email list, so as to be able to participate in discussions regarding their application.

3. The Chair will announce the prospective member to the PMA discussion list, and provide the PMA with the organisational information, the names of the representatives, the description of the constituency, and the intended Authentication Profile.

4. The Chair will solicit at least two reviewers from amongst the current PMA membership, who will guide the review of policy and practices documents as well as operational issues.

1. • If the applicant already has an existing set of policies and practices, the reviewers may commence their review forthwith.

   • If the applicant has not yet completed a set of policies and practices, it is recommended that the applicant works with the assigned reviewers and other PMA members when drafting these documents.

Major versions of the documents sent to the reviewers will be made available to the Chair for posting on the internal review web site and scrutiny by all PMA members.

If specific practices of the CA are considered confidential by the applicant, the PMA by consensus may exceptionally agree to keep such information distribution limited to the assigned reviewers only. Such practices should then be described in separate documents.

5. The review process is iterative, and is expected to continue until consensus between the reviewers and applicant is reached. The Chair is kept informed of major changes and milestones in the review process, for recording on the internal web site. Reviews and the iterations are expected to occur at regular intervals, at least monthly.

In case of non-convergence, the Chair may appoint additional reviewers, and/or moderate the process. In all cases, the final decision rest with the PMA as a whole, according to the rules laid down in the Charter.

6. The applicant should make a face-to-face presentation discussing each authority at a plenary meeting of the PMA. This may happen at any time during the accreditation process, but the presentation should contain substantive information about the authority and should substantially present the final situation.

The presentation must discuss all important elements of the authority, including the authentication model, identity vetting model, and naming, as well as physical security measures, record keeping, and auditing.

The presentation and documentation should substantially match the results of the self-audit based on the guidelines for the specific Authentication Profile.

7. Once the presentation is held and both the reviewers and the Chair, or the PMA in session, deems that the presented policies, practices and their implementation meet the requirements, the Authority may be approved.

8. Approval of an Authority is based either on clear consensus or by voting.

• The PMA in session can decide to grant provisional approval in case only minor issues remain before the Authority can be fully approved. The intended consensus can then be reached after the definitive version of the documents is made available and known to the PMA and no objections have been raised on the email list in the following 10 working days.

After definitive approval and distribution of at least one issuing authority, the prospective Authority will become a member, gain all associated rights and duties, and will be included in the membership list.

2.3. Registration Process

Before an accredited authority can be included in the repositories of the PMA the relevant introduction ceremonies must be completed successfully.

The following information must be conveyed to the PMA Chair – by a trusted means if required due to the nature of the information. This includes all information described in the relevant guideline documents and Authentication Profile under which an authority is accredited, and must additionally include:

• Name of the organisation responsible for the accredited authority(ies)

• Contact information for the organisation, including both physical and electronic addresses

• Name and contact information of one primary and at least one alternate representative of the organisation

• An email address used for communicating concerns and requests to the Authority

• URLs where the policy and practices document(s) are made available to interested parties;

• URL to a web page containing general (subscriber-oriented) information of the authority

• URLs to all trust anchors and to relevant revocation information

• Fingerprint(s) of the trust anchors or root certificate(s);

The introduction process is not complete until all the information above has been conveyed to the PMA.

2.4. Distribution of Trust Anchors

Following approval and having completed the introduction ceremonies and the registration of trust anchors and meta-data successfully, the trust anchors pertaining to the Authority will be included in the Common Source repository of the International Grid Trust Federation (IGTF) and the PMA. These trust anchors and associated meta-data will be included in the relevant trust anchors distributions issued thereafter. Distribution of trust anchors will be in accordance with the Authentication Profile under which an issuing authority has been accredited.

Distribution of trust anchors may be postponed or suspended if inclusion in the distribution leads to operational problems in the authentication infrastructure. The PMA Chair and/or the Risk Assessment Team of the PMA and the IGTF will assess any operational issues related to the distribution of trust anchors. Trust anchors should comply with relevant standards.

The PMA and the IGTF periodically issue publicly a versioned distribution containing trust anchors and their associated meta-data. The frequency of publication is decided by the PMA and IGTF, having considered requirements on accuracy, timeliness, scalability and implementation of the trust anchors by relying parties, and having heard requests for publication by its membership.

The format of the distribution is decided by the PMA and the IGTF, having considered requests from its members and the general public, and bearing in mind the implementation of the authentication infrastructure and availability of resources within the PMA and IGTF.

The Chair is kept informed of major changes and milestones in the review process, for recording on the internal web site. In case of non-convergence, the Chair may appoint additional reviewers, and/or moderate the process. In all cases, the final decision rest with the PMA as a whole, according to the rules laid down in the Charter.

2.5. Modifications

Material changes in the policies, practices and issuing name space may void the accreditation unless approved beforehand by the PMA.

A planned change in policy, practices or namespace where the new policy is expected to qualify under the same Authentication Profile under which the issuing authority is currently accredited, must be submitted to the PMA for approval and such a request must contain at least the following information:

• Name of the Authority

• List of trust anchor(s) involved with the change

• A summary of relevant changes

• Other information to facilitate a comparison between the current and proposed policy by any qualified PMA member within a reasonable amount of time. Specifically, such other information may include a marked-up list of changes in the new document, detailing those elements that have changed since the previous version

• The date on which the new policy is proposed to go into effect

Any PMA member should be given the full opportunity to read and react to changes. To this effect, both the new document and the old document(s) must be made available to PMA members, and an announcement on where these document may retrieved must be circulated on the PMA member mailing list.

On request of the Authority or on its own initiative, the PMA Chair can facility the availability by making such document(s) available in the (internal) PMA repository.

Complaints should be raised within two work-weeks after announcing the changes. If any such complaints are raised, the proposed modification is held until the issues are satisfactorily resolved. Resolution may be by vote or by tacit consent as determined and announced by the Chair. If no objections are raised, the proposed changes are approved by tacit consent following a two work-week period, as determined and announced by the Chair.

Changes in policy that would result in the CA violating the Authentication Profile under which it is currently accredited cannot be approved. In such cases, a full accreditation based on the new Profile must ensue.

2.6. Self-Audit

Accredited Authorities must perform self-audits in accordance with the Profile under which they are accredited. These results should be presented to the PMA periodically, with an intended frequency of every two years, for peer review by the PMA.

The self-audit results presented should include all important elements of the authority, including the authentication model, identity vetting model, and naming, as well as physical security measures, record keeping, and auditing. In addition, the self-audit should be assessed based on the information and guidance laid down in GFD-I.169 and follow the structure proposed therein, in accordance with the Authentication Profile under which the Authority is accredited.

The Chair will solicit at least two members to peer-review the self-audit results presented, who will review the results and, if so required in order to meet the latest Authentication Profile requirements, monitor progress of the implementation of any changes needed.

2.6. Communications Channels

The PMA maintains the following communications channels pertaining to the accreditation and membership processes

• A public web site listing all current members and their contact addresses.

This shall be hosted at https://www.eugridpma.org/

• An internal web site listing current applicants, their accreditation process status, and relevant documents and reviews, and other confidential information.

This shall be hosted at http://www.eugridpma.org/review/

• A discussion mailing list to which all members and selected third parties are subscribed. This list is to be used for general discussions that have no immediate security implications and do not disclose vulnerabilities or would otherwise damage the trust infrastructure.

This shall be contact via dg-eur-ca@services.cnrs.fr

• A set of contact email addresses for the PMA in relation to accreditation, in particular

  • chair@eugridpma.org for contacting the current Chair

  • info@eugridpma.org for questions regarding the accreditation process

  • concerns@eugridpma.org for any concerns by third parties, including concerns regarding the accreditation process

In case of problems with the Internet domain name system or specific TLD operators, information will be posted on alternative domains, specifically www.eugridpma.info and www.gridpma.eu.

3. Technical Actions

You should take into considerations the following technical actions in your CA installation and certificate operations such as certificate request, certificate revocation list, and publications of certificates.

3.1. CA Installation

The following action will be take place in your CA installation:

• Assign a servers hardware for your CA software: This server will be dedicated machine for CA system, you should determine its hardware components according to software needs of the CA.

• Decide to manage on-line or off-line CA: The CA system must be completely off-line or use at least a FIPS 140-2 level 3 Hardware Security Module or equivalent to protect the private key of CA, you should decide to manage an off-line CA or an on-line CA which uses the defined protections for private key of CA. You can take more information from “Authentication Profile for Classic X.509 Public Key Certification Authorities with secured infrastructure” document.

• Decide to use CA manager software: There are many choices about CA manager software. You can research and decide to use one of the software. The known and free CA software are:

  • OpenCA: http://www.openca.org/

  • TinyCA: http://tinyca.sm-zone.net/

  • pyCA: http://www.pyca.de/

  • PHPki: http://sourceforge.net/projects/phpki/

• Define the role of RAs and if needed decide to use RA components: A CA must define the role of RA, and these RAs are responsible for the identity vetting of all end-entities (users, admins who is responsible from servers, admins who is responsible from services). If it is needed install and use RA components of CA software.

3.2. Issuing CA Certificate

• Decide properties of CA key: A CA key must have minimum length of 2048 bits and must be configured for long term use. If the private key of the CA is software-based, it must be protected with a pass phrase at least 15 elements.

• Decide to use certificate extensions: The CA and end-entity certificate extensions should be determined according to “Grid Certificate Profile” and “Authentication Profile for Classic X.509 Public Key Certification Authorities with secured infrastructure”

• Decide the CA certificate DN: The DN of the CA certificate should define the CA manager properties such as country, organisation, organisation unit and common name of the CA. Before creating the CA certificate, be sure of CA certificate DN.

3.3. CA/RA Operational Guidelines

After the installation of CA software, prepare an operational guideline for CA and RA technical operations for designated personnel of the CA and RA.

3.4. CA On-line Repositories

The followings must be published by each authority for their subscribers, relying parties and for benefit of distribution by the PMA and federation:

• The CA root certificate

• 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 address for inquiries and fault reporting

• A physical or postal contact address

• The repository must be run at least on a best-effort basis, with an intended continuous availability.

If you decide to take certificate request from the on-line repository, you should prepare an https URL for user, host and service certificate requests.

Also, on-line repository should be available for CRL downloads. Thus, your wide area network connection should be continuous since e very server, in a grid infrastructure, are always downloading CRL files in every hour.

4. Documentation

There should be a single CA organization per country, large region or international organization. The goal is to serve the largest possible community with a small number of stable CAs. To achieve this sustainability, it is expected that each CA will be operated as a long-term commitment by institutions or organizations rather than being a bound to specific projects.

The CA will handle the actual task of issuing the certificates and certificate revocations lists. The CA must prepare a CP/CPS and should document the each step of operations in detailed.

4.1. Preparing CP/CPS

Every CA should have a CP/CPS and these documents should be structured as defined in RFC 3647 (http://www.ietf.org/rfc/rfc3647.txt). Every CA organization must publish their CP/CPS documents in an on-line repository, you can search and find every accredited CA CP/CPSs on web pages and use them as an example is they are structured as defined in RFC 3647.

4.2. CP/CPS OID

Every CA must assign its CP/CPS an O.I.D. You can request an O.I.D. from IANA (http://www.iana.org/)

4.3. Self Audit Guidelines

You can check your technical actions and CP/CPS document with “Check Lists for new CA Organization” document in EUMEDGRID-Support project wiki page and “Guidelines for auditing Grid CAs Version 1.0” document in CAOPS WG (CA Operations Working Group) web page (https://forge.gridforum.org/sf/projects/caops-wg).

5. Current Situation

There are 5 countries in WP4 of EUMEDGrid-Support project that have their national Certification Authorities. You can follow the activities and CP/CPS documents of the related CAs in the following web addresses:

• CyGrid CA , Cyprus: http://cygrid.org.cy/certification.php

• GRID-FR CA, France: http://igc.services.cnrs.fr/GRID-FR/?lang=en&cmd=Info

• INFN CA, Italy: http://security.fi.infn.it/CA/en

• MaGrid CA, Morocco: http://www.magrid.ma/ca/

• TRGrid CA, Turkey: http://www.grid.org.tr/eng/servisler/sertifika

Catch-all MED Countries CA (INFN CA), for the infrastructure to run in a secure fashion, will continue to operate providing certificates for countries without a CA. In parallel, the experienced countries, which have been officially accredited by the EUGRIDPMA, will support for national CA deployment and accreditation in continuity with the process started in EUMEDGRID project.

6. References

1. Authentication Profile for Classic X.509 Public Key Certification Authorities with secured infrastructure, Version 4.3 http://www.eugridpma.org/guidelines/classic

2. Guidelines for auditing Grid CAs, Version 1.0 https://forge.gridforum.org/sf/projects/caops-wg

3. Grid Certificate Profile https://forge.gridforum.org/sf/projects/caops-wg, http://www.ogf.org/documents/GFD.125.pdf

4. Policy on entities that are natural persons http://www.eugridpma.org/guidelines/1scp/

5. Policy on vetting identity by a face to face meeting http://www.eugridpma.org/guidelines/1scp/

6. Policy on vetting identity by a Trusted Third Party http://www.eugridpma.org/guidelines/1scp/

7. Policy on holding non-exportable private keys protected on a secure hardware token http://www.eugridpma.org/guidelines/1scp/

8. Policy on holding private keys protected on a secure hardware token http://www.eugridpma.org/guidelines/1scp/

9. Policy on holding private keys protected in files http://www.eugridpma.org/guidelines/1scp/

10. Accreditation Procedures http://www.eugridpma.org/guidelines/

11. Protection of private key data for end-users in local and remote systems http://www.eugridpma.org/guidelines/

(* ) EUGridPMA document "Accreditation Procedures" is being updated by EUGridPMA members in April 2010. The Draft version of the new guideline is present in EUGridPMA web page. This wiki page had been updated according to the new Accreditation and Membership Process Guideline