Certification Practice Statement
This document is based on the structure suggested by the RFC 2527.
The terms used in this document are explained in the Glossary.
This document describes the set of rules and procedures followed by Grid Canada Certificate Authority (GC CA), the top level CA for all purposes of Grid Canada (http://www.gridcanada.ca/).
GC CA Certificate Policy and Certification Practice Statement
February 18, 2004
GC CA provides PKI services for the Canadian research community that are involved in Grid activities.
GC CA does not issue certificates to subordinate Certificate Authorities.
GC CA manages the functions of its Registration Authority. Additional RA’s may be created as required. See the GC CA site for a current list (http://www.gridcanada.ca/ca/ra.html).
The GC CA issues certificates for people, hosts, and host applications involved in the activities listed in section 1.3.
Person certificates can be used to authenticate a person to research sites that have agreed to accept certificates from the GC CA, and may require the signing of Globus proxy certificates [PROXY]. While person certificates can be used for other purposes such as email signing, these are not supported.
Service certificates can be used to identify a named service on a specific host and for encryption of communication (SSL/TLS).
The ownership of a GC certificate does not imply automatic access to any kind of computing resources.
The GC CA is managed by the Grid Canada Security Group.
The contact persons for questions related to this document or the GC CA in general is:
Darcy Quesnel Ratilal Haria
Phone: +1 613 996-2144 Phone: +1 613 990 4433
Email : email@example.com Email : firstname.lastname@example.org
1200 Montreal Road, M-50
Canada K1A 0R6
Fax: +1 613 952 7151
Email : email@example.com
Web : http://www.gridcanada.ca/ca/
The GC CA will:
· Accept certification requests from entitled entities;
· Notify the RA of certification request and accept authentication results from the RA;
· Issue certificates based on the requests from authenticated entities;
· Notify the subscriber of the issuing of the certificate;
· Publish the issued certificates (optionally, respective of privacy and other issues);
· Accept revocation requests according to the procedures outlined in this document;
· Authenticate entities requesting the revocation of a certificate, possibly by delegating this task to a GC RA;
· Issue a Certificate Revocation List (CRL);
· Publish the CRL issued; and
· Keep audit logs of the certificate issuance process.
A GC RA will:
· Accept authentication requests from the GC CA;
· Authenticate entity making the certification request according to procedures outlined in this document;
· Notify the GC CA when authentication is completed for a certification or revocation request;
· Accept revocation requests according to the procedures outlined in this document;
· Notify the GC CA of all revocation requests; and
· Will not approve a certificate with a lifetime greater than 12 months.
· Read and adhere to the procedures published in this document;
· Generate a key pair using a trustworthy method;
· Take reasonable precautions to prevent any loss, disclosure or unauthorized use of the private key associated with the certificate, including:
o For Person Certificates:
§ Selecting a pass phrase of a minimum recommended 15 characters;
§ Protecting the pass phrase from others;
§ Always using the pass phrase to encrypt the stored private key; and
§ Never sharing the private key with other users;
o For Service Certificates:
§ Storing them encrypted whenever possible; and
§ They may be kept unencrypted on the host that they represent;
· Provide correct personal information and optionally authorize the publication of the certificate;
· Notify the GC CA immediately in case of private key loss or compromise; and
· Use the certificates for the permitted uses only.
Relying parties must:
· Read the procedures published in this document;
· Use the certificates for the permitted uses only; and
· Do not assume any authorization attributes based solely on an entity's possession GC CA certificate.
Relying parties may:
· Verify that the certificate is not on the CRL before validating a certificate.
GC CA will provide access to GC CA information, as outlined in section 2.6.1, on its web site, http://www.gridcanada.ca/ca/.
The GC CA and its agents issue person certificates according to the practices described in this document to validate identity. No liability, implicit or explicit, is accepted.
GC CA and its agents make no guarantee about the security or suitability of a service that is identified by a GC certificate. The certification service is run with a reasonable level of security, but it is provided on a best-effort basis. It does not warrant its procedures and it will take no responsibility for problems arising from its operation, or for the use made of the certificates it provides.
GC CA denies any financial or any other kind of responsibility for damages or impairments resulting from its operation.
GC CA assumes no financial responsibility with respect to use or management of any issued certificate.
This document must be treated according to Canadian laws. Legal disputes arising from the operation of the GC CA will be treated according to Canadian laws.
Interpretation of this CP and CPS is according to Canadian laws.
No fees are charged.
GC CA will operate a secure online repository that contains:
· The GC CA’s certificate;
· Certificates issued by the GC CA (optionally, respective of privacy and other issues);
· A Certificate Revocation List;
· A copy of this policy; and
· Other information deemed relevant to the GC CA.
· Certificates will be published to the GC CA repository as soon after being issued (optionally, respective of privacy and other issues);
· CRLs will be published soon after a revocation is issued or refreshed once every month, 7 days before the month-long validity of the CRL expires;
· All GC CA documents will be published to the project website as they are updated; and
· Changes to this CP and CPS will be published as soon as they are approved and previous versions will remain available on-line.
The online repository is available on a substantially 24/7 basis, subject to reasonable scheduled maintenance.
GC CA does not impose any access control on its policy, its signing certificate and issued certificates, and its CRLs.
In the future, GC CA may impose access controls on issued certificates, their status information and CRLs at its discretion, subject to agreement between the CA, relying parties, and subscribers.
The repository of certificates and CRLs are available at http://www.gridcanada.ca/ca/.
No external audit will be required, only self-assessment by the GC CA that its operation is according to this Policy.
GC CA collects subscribers’ full names and email addresses. Some of this information is used to construct unique, meaningful subject names in the issued certificates.
Information included in issued certificates and CRLs is generally not considered confidential. The GC CA does not collect any other kind of confidential information.
The GC CA does not have access to or generate the private keys of a digital signature key pair, such as those used in GC identity certificates. These key pairs are generated and managed by the client and are the sole responsibility of the subscriber.
Parts of this document are inspired by [INFN], [CERN], [DOE], [FZKGRID], [GRIDEIRE], [CNRS], and [RFC2527].
The subject name is an X.500 name type, a Distinguished Name. It has one of the following forms:
Must include the full name of the subject;
Must include the fully qualified domain name of the host, and optionally the named service.
The Subject Name in a certificate must have a reasonable association with the authenticated name of the subscriber.
See sections 3.1.1 and 3.1.2.
The X.500 Distinguished Name (DN) must be unique for each subject name certified by the
GC CA. The Common Name (CN) component of the DN will include the full name of the subscriber as described in 3.1.1.
For hosts and services the CN should contain the fully qualified domain name (FQDN) of the host.
The CN may contain an arbitrary alphanumeric qualifier that distinguishes it from certificates from the same subscriber.
Certificates must apply to unique individuals or resources. Users may not share certificates.
The GC CA verifies the identity of organizations by checking:
· That the organization is known to be part of a grid computing project or related experiments; and
· That the organization is operating in Canada, by checking contact information.
The Grid Canada RA verifies the identity of a person by checking:
· A certificate request (or renewal or revocation) must be sent to firstname.lastname@example.org with an email subject containing “Certificate Request” (or “Certificate Renewal” or “Certificate Revocation”) and originate from a valid email address from a known organization as specified in section 3.1.8; and
· A request will be accepted if the person is known to those listed in section 1.4; or
· A request is verified by an RA closely associated with the person’s organization; or
· A copy of an organization’s identity card for the requestor, manually-signed by a well-known contact person of that organization, is sent to those listed in section 1.4 along with contact information for confirmation.
Rekey (or renewal) before expiration can be accomplished by sending a rekey request based on a new public key. The GC CA will send renewal reminders at least a month before expiration.
Rekey after expiration follows the same authentication procedure as a new certificate.
Rekey after revocation follows the same authentication procedure as a new certificate.
Certificate revocation requests must be sent by email to email@example.com. The GC CA checks the identity of the revoker as per 3.1.9.
The minimum key length for all certificates is 1024 bits. The maximum validity period is one year. Each applicant must generate its own key pair using either Globus grid-cert-request or OpenSSL or similar software.
Certificate requests in PEM format are sent by email, as outlined in section 3.1.9.
GC CA issues the certificate if, and only if, the authentication of the subject is successful according to section 3.1.9. The applicant will be notified about the issuance of the certificate by email or will be informed about the reason why the certificate could not be issued.
A certificate will be revoked when the information it contains is suspected to be incorrect or compromised. This includes situations where:
· The subscriber’s private key is lost or suspected to be compromised;
· The information in the subscriber’s certificate is suspected to be inaccurate;
· The subject has failed to comply with the rules in this policy;
· The system to which the certificate has been issued has been retired;
· The subscriber no longer needs the certificate to access a relying parties’ resources; and
· The subscriber violated his/her obligations.
A certificate revocation can be requested by the holder of the certificate to be revoked or by any other entity presenting proof of knowledge of a circumstance of revocation.
A certificate revocation can be requested as outlined in section 3.1.9.
There is no revocation grace period.
CRLs are issued after every certificate revocation or every month, 7 days before the month-long validity of the CRL has expired.
A relying party may verify a certificate against the most recent CRL issued, in order to validate the use of the certificate.
OCSP is not implemented.
Security auditing of the GC CA is not supported.
The following events are recorded and archived:
· Certificate requests;
· Issued certificates;
· Issued CRLs; and
· All email correspondence with the GC CA.
The minimum retention period is three years.
Records are backed up on removable media, which are stored in a room with restricted access.
See section 4.6.3.
See section 4.6.3.
The CA’s private signing key is changed periodically. To avoid interruption of validity of all subordinate keys the new CA key should be generated one year before the old one becomes invalid. From that point on new certificates are signed by the new CA key.
The new CA public key is posted online at http://www.gridcanada.ca/ca/.
If the CA’s private key is compromised - or suspected to be compromised - the CA will:
· Inform subscribers and other relying parties;
· Terminate the issuance and distribution of certificates and CRLs;
· Generate a new CA certificate (with a new key pair) and make it immediately available in the public repository at http://www.gridcanada.ca/ca/; and
· All subjects will have to recertify following the procedures in section 3.1.
Before the GC CA terminates its services, it will:
· Inform subscribers and subordinate RAs;
· Make widely available information of its termination; and
· Stop issuing certificates and CRLs.
The GC CA operates in a controlled environment, where access is restricted to authorized people.
The GC CA is located at the National Research Council of Canada (NRC) on the Montreal Road Campus (Ottawa, Ontario, Canada) at the Institute for Information Technology (Building M-50).
Physical access to the hardware is restricted to authorized personnel. All removable media is stored in secured area.
The building has an air conditioning system and the CA machines are connected to a UPS system.
The hardware is in a zone not subject to floods.
The building has a fire alarm system.
Backups are stored on removable storage media.
Access to servers and applications is limited to the GC CA Security Group who are staff or guest workers of NRC.
Key pairs for the GC CA are generated by the GC CA Security Group on a dedicated machine, not connected to any kind of network. The underlying software package used is OpenSSL.
Each end entity must generate its own key pair. The GC CA does not generate end entity private keys.
The GC CA never has access to the end entity private key.
End entities’ public keys must be delivered to the GC CA as per section 3.1.
The CA certificate is available from its public repository at http://www.gridcanada.ca/ca/.
Keys of length less then 1024 bits will not be signed.
Key generation is performed by software (for example, OpenSSL).
GC certificates may be used only for authentication and signing proxy certificates
[PROXY]. It is understood that they could be used in other capacities, but the GC
CA does not recommend or warrant any other use of the certificates it signs.
The GC CA root private key will only be used to sign CRLs and end entity certificates.
The GC CA root private key is kept encrypted in multiple locations.
The current GC CA root certificate has a validity of five years, expires in 2007-04-10, and has a key length of 2048.
GC CA root private key is protected by a passphrase.
GC CA servers include the following:
· Operating systems are maintained at a high level of security by applying all recommended and applicable security patches;
· Monitoring is done to detect unauthorized software changes; and
· Services are reduced to a minimum.
See section 6.5.1.
Basic Constraints (CRITICAL)
Not a CA.
Key Usage (CRITICAL)
Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
Subject Key Identifier
Authority Key Identifier
Subject Alternative Name
Subject’s email address
Issuer Alternative Name
C=CA, O=Grid, CN=Grid Canada CA
C=CA, O=Grid, OU=domainName, CN=fullPersonName[, Email=emailAddress]
C=CA, O=Grid, [OU=domainName,] CN=host/fullyQualifiedDomainName
C=CA, O=Grid, [OU=domainName,] CN=serviceName/fullyQualifiedDomainName
See section 1.2.
Users may not be warned in advance of changes to GC CA’s policy and CPS. Relevant changes will be made as widely available as possible.
The policy is available at http://www.gridcanada.ca/ca/.
The GC CA Security Group is responsible for the CP and CPS. All changes must be approved by the Security Group.
Data values, other than keys, that are required to operate cryptographic modules and that need to be protected (e.g., a PIN, a passphrase, or a manually-held key share).
Certification Authority (CA)
The entity / system that issues X.509 identity certificates (places a subject name and public key in a document and then digitally signs that document using the private key of the CA).
Certificates – or Public Key Certificates
A data structure containing the public key of an end entity and some other information, which is digitally signed with the private key of the CA that issued it
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. For example, a particular certificate policy might indicate applicability of a type of certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range.
Certification Practice Statement (CPS)
A statement of the practices, which a certification authority employs in issuing certificates.
Certificate Revocation Lists (CRL)
A CRL is a time stamped list identifying revoked certificates that is signed by a CA and made freely available in a public repository.
A certificate subject that does not sign certificates (i.e., person, host, and service certificates).
A certificate for server certification and encryption of communications (SSL/TSL). It will represent a single machine.
Public Key Infrastructure (PKI)
A term generally used to describe the laws, policies, standards, and software that regulate or manipulate certificates and public and private keys. All of this implies a set of standards for applications that use encryption.
A certificate used for authentication to establish a Grid Person Identity. It will represent an individual person.
Policy Management Authority (PMA)
For the GC CA this is a committee composed of the GC CA Security Group.
The policy-dependent information that accompanies a certificate policy identifier in an X.509 certificate.
In a PKI, a cryptographic key created and kept private by a subscriber. It may be used to make digital signatures which may be verified by the corresponding public key; to decrypt the message encrypted by the corresponding public key; or, with other information, to compute a piece of common shared secret information.
In a PKI, a cryptographic key created and made public by a subscriber. It may be used to encrypt information that may be decrypted by the corresponding private key; or to verify the digital signature made by the corresponding private key.
Registration Authority (RA)
An entity that is responsible for identification and authentication of certificate subjects, but that does not sign or issue certificates (i.e., an RA is delegated certain tasks on behalf of a CA).
A recipient of a certificate who acts in reliance on that certificate and/or digital signatures verified using that certificate.
A certificate for a particular service running on a host. It will represent a single service on a single host.
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.
Virtual Organization (VO)
An organization that has been created to represent a particular research or development effort independent of the physical sites at which the scientist or engineers work.
CERN CA Certificate Policy and Certification Practice Statement, Version 0.1. August 2001.
Certificate Policy and Certification Practice Statement CNRS/CNRS-Projets/Datagrid-fr, Version 0.3. August 2002.
DOE Science Grid PKI Certificate Policy and Certification Practice Statement, Version 2.1. August 2002.
FZK-Grid-CA Certificate Policy and Certification Practice Statement, Version 0.2. June 2002.
Grid-Ireland Certification Authority Certificate Policy and Certification Practice Statement, Version 0.3. October 2001.
INFN CA Certificate Policy and Certification Practice Statement, Version 1.0. December 2001.
S. Tuecke, et al., Internet X.509 Public Key Infrastructure Proxy Certificate Profile, Internet Draft. 2001.
S. Chokani and W. Ford, Internet X.509 Infrastructure Certificate Policy and Certification Practices Framework, RFC 2527. March 1999.