Digital Signature Certificate Policy

Version 1.3b
December 2002

Table of Contents

1. Introduction

Top of page

2. General Provisions

2.1 Obligations

2.1.1 CA obligations

2.1.1.1 Notification of certificate issuance and revocation
2.1.1.2 Accuracy of representations
2.1.1.3 Time between certificate request and issuance
2.1.1.4 Certificate revocation and renewal
2.1.1.5 Protection of private keys
2.1.1.6 Restrictions on issuing CA's private key use

2.1.2 LRA obligations/duties

2.1.2.1 Notification of certificate issuance and revocation
2.1.2.2 Accuracy of representations
2.1.2.3 Protection of LRA private keys
2.1.2.4 Restrictions on LRA private key use

2.1.3 Subscriber obligations

2.1.3.1 Representations
2.1.3.2 Protection of subscriber private key and key token
2.1.3.3 Restrictions on End-Entity private key use
2.1.3.4 Notification upon private key compromise

2.1.4 Relying party obligations

2.1.4.1 Use of certificates for appropriate purpose
2.1.4.2 Verification responsibility
2.1.4.3 Revocation check responsibility

2.1.5 Repository obligations

Top of page

2.2 Liability

2.2.1 Requirements
2.2.2 Disclaimers of warranties and obligations
2.2.3 Limitations of liability
2.2.4 Other terms and conditions

2.3 Financial responsibility
2.4 Interpretation and Enforcement

2.4.1 Governing law
2.4.2 Severability, survival, merger, notice
2.4.3 Dispute resolution procedures

2.5 Fees
2.6 Publication and repository
2.7 Compliance inspection

2.7.1 Frequency of compliance inspection
2.7.2 Identity/qualifications of CA inspector
2.7.3 Inspector's relationship to audited CA
2.7.4 Topics covered by inspection
2.7.5 Actions taken as a result of inspection
2.7.6 Communication of results

2.8 Confidentiality of information
2.9 Intellectual property rights

3. Identification and Authentication

3.1 Initial Registration

3.1.1 Types of names
3.1.2 Need for names to be meaningful
3.1.3 Rules for interpreting various name forms
3.1.4 Uniqueness of names
3.1.5 Name claim dispute resolution procedure
3.1.6 Recognition, authentication and roles of trademarks
3.1.7 Method to prove possession of private key
3.1.8 Authentication of organisation identity
3.1.9 Authentication of individual identity
3.1.10 Authentication of devices or applications

Top of page

3.2 Authentication for routine re-key
3.3 Authentication for re-key after revocation
3.4 Authentication of revocation request

4. Operational Requirements

4.1 Application for a certificate

4.1.1 Application for a cross-certificate

4.2 Certificate issuance
4.3 Certificate acceptance
4.4 Certificate Suspension and Revocation

4.4.1 Circumstances for revocation
4.4.2 Who can request revocation
4.4.3 Procedure for revocation request
4.4.4 Revocation request grace period
4.4.5 Circumstances for Certificate Suspension (Deactivating Subscribers)
4.4.6 Who Can Request Suspension (Deactivation)
4.4.7 Procedure for Suspension (Deactivation) Request
4.4.8 Limits on Suspension (Deactivation) Period
4.4.9 CRL issuance frequency
4.4.10 CRL checking requirements
4.4.11 On-line revocation/status checking availability
4.4.12 On-line revocation checking requirements
4.4.13 Other forms of revocation advertisements available
4.4.14 Checking requirements for other forms of revocation advertisements
4.4.15 Special requirements re: Key compromise

Top of page

4.5 System Security Audit Procedures

4.5.1 Types of event recorded
4.5.2 Frequency of audit log processing
4.5.3 Retention period of audit log
4.5.4 Protection of audit log
4.5.5 Audit log back-up procedures
4.5.6 Audit collection system
4.5.7 Notification to event causing subject
4.5.8 Vulnerability assessments

4.6 Records archival
4.7 Key changeover
4.8 Compromise and Disaster Recovery

4.8.1 Computing resources, software, and/or data are corrupted
4.8.2 Entity public certificate is revoked

4.8.2.1 Entity public certificate is downgraded

4.8.3 Entity key is compromised
4.8.4 4.8.4 Secure facility after a natural or other type of disaster

4.9 CA termination

5. Physical, Procedural and Personnel Security

5.1 Physical Controls

5.1.1 Site location, construction and physical access
5.1.2 Site location, construction and physical access
5.1.3 Power and air conditioning
5.1.4 Water exposure
5.1.5 Fire prevention and protection
5.1.6 Media storage
5.1.7 Waste disposal
5.1.8 Off-site back-up

Top of page

5.2 Procedural Controls

5.2.1 Trusted Roles

5.2.1.1 CA trusted roles
5.2.1.2 LRA trusted roles

5.2.2 Number of persons required per task
5.2.3 Identification and authentication for each role

5.3 Personnel security controls

5.3.1 Background, qualifications, experience and clearance requirements
5.3.2 Background check procedures
5.3.3 Training requirements
5.3.4 Retraining frequency and requirements
5.3.5 Job rotation
5.3.6 Sanctions for unauthorised actions
5.3.7 Contracting personnel
5.3.8 Documentation supplied to personnel

6. Technical Security Controls

6.1 Key Pair Generation and Installation

6.1.1 Key pair generation
6.1.2 Private key delivery to entity
6.1.3 Public key delivery to certificate issuer
6.1.4 CA public key delivery to users
6.1.5 Asymmetric key sizes
6.1.6 Public key parameters generation
6.1.7 Parameter quality checking
6.1.8 Hardware/software key generation
6.1.9 Key usage purposes (as per X.509v3 field)

6.2 Private key protection

6.2.1 Standards for crypto-module
6.2.2 Private key multi-person control
6.2.3 Private key escrow
6.2.4 Private key back-up
6.2.5 Private key archival
6.2.6 Private key entry into cryptographic module
6.2.7 Method of activating private key
6.2.8 Method of deactivating private key
6.2.9 Method of destroying private key

Top of page

6.3 Other Aspects of Key Pair Management

6.3.1 Public key archival
6.3.2 Usage periods for the public and private keys

6.4 Activation Data

6.4.1 Activation data generation and installation
6.4.2 Activation data protection
6.4.3 Other aspects of activation data

6.5 Computer Security Controls

6.5.1 Specific computer security technical requirements
6.5.2 Computer security rating

6.6 Life Cycle Technical Controls

6.6.1 System development controls
6.6.2 Security management controls

6.7 Network Security Controls
6.8 Cryptographic module engineering controls

7. Certificate and CRL Profiles

7.1 Certificate profile

7.1.1 Version number
7.1.2 Certificate extensions
7.1.3 Algorithm object IDs, CRL distribution points for different assurance levels
7.1.4 Name forms
7.1.5 Name constraints
7.1.6 Certificate policy object identifier
7.1.7 Usage of policy constraints extension
7.1.8 Policy qualifiers syntax and semantics
7.1.9 Processing semantics for the critical certificate policy extension

Top of page

7.2 CRL Profile

7.2.1 Version number
7.2.2 CRL and CRL entry extensions

8. Specification Administration

1. Introduction

1.1 Overview

The Certificate Policy defined in this document is intended for use by the Canada Customs and Revenue Agency (CCRA). Users of this document are to consult the issuing Certification Authority to obtain further details of the implementation of this Certificate Policy.

The PKISignCertPcy policy is for the management and use of certificates containing public keys used for verification, authentication, integrity and key agreement mechanisms. For instance, the certificates issued under this policy could be used to verify the identity of electronic mail correspondents or for access to computer systems, to verify the identity of citizens or other legal entities, or to protect the integrity of software and documents.

The term "assurance" is not intended to convey any representation or warranty as to 100% availability of CA services offered under the CCRA PKI. Such availability may be affected by system maintenance, system repair or factors outside the control of the CA.

Issuance of a public key certificate under this policy does not imply that the Subscriber has any authority to conduct business transactions on behalf of the Canada Customs and Revenue Agency operating the CA.

The CA will be governed by the laws of Canada and applicable provincial laws concerning the enforceability, construction, interpretation and validity of this Certificate Policy.

The Canada Customs and Revenue Agency reserves the right not to enter into a cross certification agreement with an external Certification Authority.

Top of page

1.1.1 Policy overview

The Policy Object Identifier Designation for this Policy is extSignMedium 2 16 124 101 1 272 3 1 1 1 2.

This policy has been designed to be used in certain situations and identifies specific roles and responsibilities for the CA which issues certificates and for Local Registration Authorities who must perform tasks that may be assigned to them by the CA. Subscribers and Relying Parties also have specific obligations which are outlined in this policy.

The CA may issue cross-certificates at this level of assurance.

The CA must ensure that it associates itself with and uses one Certificate and one Certificate Revocation List (CRL) repository for this type of certificate. Certificates must be made available to Subscribers.

The use of medium assurance level confidentiality keys is appropriate for the confidentiality of designated information that, if compromised, could cause serious injury outside the national interest.

The Crown, in right of Canada, and CCRA disclaim all liability for any use of this type of certificate other than uses permitted by the CA. The Crown, in right of Canada, and CCRA limit their liability for permitted uses to $50,000 per instance of use.

Any disputes concerning key or certificate management under this policy are to be resolved by the Parties concerned using the dispute settlement mechanism contained herein.

Certificates may be issued under this policy following authentication of a Subscriber's identity. Identification will be in the manner set out in this policy.

The CA will revoke certificates in the circumstances enumerated in this policy.

The CA is required to maintain records or information logs in the manner described in this policy.

The CA should ensure that critical CA functions are performed by at least two individuals.

Digital signature keys must not be backed-up or otherwise stored. Keys may have a validity period as indicated in this policy. Confidentiality keys issued by the CA will be backed-up to protect against data loss or data corruption.

No personal information collected by the CA may be disclosed without the Subscriber's consent unless required by law.

CA activities are subject to inspection.

Top of page

1.1.2 General definitions

Top of page

1.1.3 Government security policy definitions

Top of page

1.1.4 Acronyms

Top of page

1.2 Identification alphanumeric OID

The name of this Certificate Policy is: CCRA External Medium Assurance Digital Signature CP - PC ADRC externe pour Signature Numériques d'assurance de niveau moyen.

The object identifier (OID) for this Certificate Policy is: 2 16 124 101 1 272 3 1 1 1 2

1.3 Community and applicability

This Certificate Policy has been designed to satisfy general public key certificate requirements of the CCRA.

1.3.1 Certification Authorities (CAs)

The CA operating under this policy is responsible for the creation and signing of:

• certificates binding Subscribers, PKI personnel and (where permitted) other CAs with their signature verification keys;
• promulgating certificate status through CRLs; and
• ensuring adherence to this Certificate Policy.

While the CCRA may use a contractor to provide CA services, it must remain responsible and accountable for the operation of its CA.

CCRA CA will cross-certify through the CCF. A cross-certification must be in accordance with the Certificate Policy and any additional requirements determined by the CCRA and GoC PMAs. All cross-certification between CCRA PKI CAs and non-CCRA CAs will be done through the CCF pursuant to instructions from the GoC PMA. Any agreements made with other CAs must be documented and applicable disclaimers made available to Subscribers.

Notwithstanding the above, the CA may issue cross-certificates to other CAs where expressly authorised by the GoC PMA.

1.3.2 Local registration authorities (LRAs)

An LRA operating under this Certificate Policy is responsible for all duties assigned to them by the CA.

An LRA may perform duties on behalf of more than one CA, providing that in doing so they satisfy all the requirements of this CP.

1.3.3 Repositories

The CA must ensure that there is at least one certificate and CRL repository associated with it. This repository should be in the form of one or more directories that comply with the GoC X.500 standards profile.

A repository may or may not be under the control of the CA. Where a repository is not under the control of the CA, the CA must ensure that the terms and conditions of its association include, but are not limited to, the subjects of availability, access control, integrity of data, directory replication and directory chaining.

Top of page

1.3.4 Subscribers

Individuals or organisations may be Subscribers. Subscribers may be issued certificates for assignment to devices, groups, organisational roles or applications provided that responsibility and accountability is attributable to an individual or an organisation.

CCRA PKI certificates will only be issued after a request or an authorisation for issuance from one or more Sponsors. They may be issued to individuals, organisations or others with whom the Sponsor has a relationship.

Eligibility for a certificate is at the sole discretion of the CA.

The CA may administer any number of Subscribers.

1.3.5 Relying parties

A Relying Party may be either a Subscriber of the CCRA PKI or a Subscriber of a PKI which has signed a cross-certification agreement with the CCRA PKI.

1.3.6 Policy applicability

This policy is suitable for the integrity and authentication of business or other transactions that if falsified could cause either significant financial or other loss, or require legal action for correction.

1.3.6.1 Approved and prohibited applications

The CA must certify which CCRA applications are intended to be used with the PKI system. These applications must, as a minimum, meet the following requirements:

• correctly establish, transfer and use the public and private keys;
• are capable of performing the appropriate certificate validity and verification checking; and
• report appropriate information and warnings to the Subscriber.

1.4 Contact details

This Certificate Policy is administered by:

Top of page

The contact person is:

2. General Provisions

2.1 Obligations

2.1.1 CA obligations

The CA will operate in accordance with its CPS, this CP, and the laws of Canada when issuing and managing the keys provided to LRAs and Subscribers under this CP. The CA will ensure that all LRAs operating on its behalf comply with the relevant provisions of this CP concerning the operation of LRAs. The CA will take all reasonable measures to ensure that Subscribers and Relying Parties are aware of their rights and obligations with respect to the operation and management of any keys, certificates or End-Entity hardware and software used in connection with the PKI.

The CA must provide notice of limitations of liability. Such notice must, at a minimum, be provided within the certificate either through a private certificate extension or the use of the userNotice field within the certificate as defined by PKIX. Because of space limitations within a certificate, such notice must be limited to the following language: "Limited Liability. See CP-Responsabilité limitée. Voir PC."

• The OID for ccraCertUserNotice is 2 16 124 101 1 272 3 0 0

The CA must:

• issue a CPS;
• have in place mechanisms and procedures to ensure that its LRAs and Subscribers are aware of, and agree to abide with, the stipulations in this policy that apply to them;
• ensure that any CA with whom it directly cross-certifies complies with all CPs that are mutually recognised; and
• through compliance inspection, verify to cross-certifying CAs that it complies with this CP.

CA personnel associated with PKI roles must be individually accountable for actions they perform. "Individually accountable" means that there must be evidence that attributes an action to the person performing the action.

2.1.1.1 Notification of certificate issuance and revocation

The Issuing CA must make CRLs available to a Subscriber or Relying Party in accordance with section 4.4. The Issuing CA must notify a Subscriber when a certificate bearing the Subscriber's DN is issued or revoked.

2.1.1.2 Accuracy of representations

When the Issuing CA publishes a certificate it certifies that it has issued a certificate to a Subscriber and that the information stated in the certificate was verified in accordance with this CP. Publication of the certificate in a repository, to which the subscriber has access, constitutes notice of such verification.

The CA will provide to each Subscriber notice of the Subscriber's rights and obligations under this Certificate Policy. Such notice may be in the form of an agreement. Such notice will include a description of the allowed uses of certificates issued under this CP; the Subscriber's obligations concerning key protection; and procedures for communication between the Subscriber and the CA or LRA, including communication of changes in service delivery or changes to this policy. Subscribers should also be notified as to procedures for dealing with suspected key compromise, certificate or key renewal, service cancellation, and dispute resolution.

The CA will ensure that any notice of the Subscriber's rights and obligations under this Certificate Policy includes a description of a Relying Party's obligations with respect to use, verification and validation of certificates.

2.1.1.3 Time between certificate request and issuance

There is no stipulation for the period between the receipt of an application for a Certificate and the generation of the Entity's key material.

The CA must ensure that the Entity's key material will be forwarded to the Entity within 24 hours of generation.

The CA must ensure that the period which the Entity has to complete its initialisation process is no longer than seven working days from the date of the generation of the entity's key material by the CA.

2.1.1.4 Certificate revocation and renewal

The Issuing CA must ensure that any procedures for the expiration, revocation and renewal of a certificate will conform to the relevant provisions of this CP and will be expressly stated in the Subscriber Agreement and any other applicable document outlining the terms and conditions of the certificate use. The CA must ensure that the key changeover procedures are in accordance with section 4.7. The Issuing CA will also ensure that notice of revocation of a certificate will be posted to the CRL within the time limits stated in sections 4.4.4 and 4.4.9. The address of the CRL must be defined in the certificate.

2.1.1.5 Protection of private keys

All Entities must ensure that their private keys and activation data are protected in accordance with sections 5 and 6.

Top of page

2.1.1.6 Restrictions on issuing CA's private key use

The CA must ensure that its certificate signing private key is used only to sign certificates and CRLs.

The CA must ensure that private keys issued to its personnel to access and operate CA applications are used only for such purposes. If required, its personnel would be issued sets of Subscriber keys and certificates to be used for purposes other than CA use.

2.1.2 LRA obligations/duties

The CA must ensure that all its LRAs comply with all the relevant provisions of this CP and the CA's CPS.

The CA is responsible through its LRA personnel to inform Subscribers of all relevant information pertaining to the rights and obligations of the CA, LRA and Subscriber contained in this CP, the Subscriber agreement, if applicable, and any other relevant document outlining the terms and conditions of use.

Records of all actions carried out in performance of LRA duties must identify the individual who performed the particular duty.

LRA Administrators must be individually accountable for actions performed on behalf of the CA. Individually accountable means that there must be evidence that attributes an action to the person performing the action.

2.1.2.1 Notification of certificate issuance and revocation

There is no requirement for an LRA to notify a Relying Party of the issuance or revocation of a certificate.

2.1.2.2 Accuracy of representations

When an LRA submits Subscriber information to the CA, they must certify to the CA that they have authenticated the identity of that Subscriber in accordance with sections 3 and 4.

2.1.2.3 Protection of LRA private keys

Each person performing LRA duties on-line through a remote administration application with the CA must ensure that his or her private keys are protected in accordance with sections 5 and 6.

2.1.2.4 Restrictions on LRA private key use

Private keys used by an LRA administrator to access and operate LRA Applications on-line with the CA must not be used for any other purpose.

2.1.3 Subscriber obligations

The Issuing CA must ensure that a Subscriber enters into an agreement or abides by an Acceptable Use Statement which outlines the terms and conditions of use, including permitted applications and purposes.

2.1.3.1 Representations

Any information required to be submitted to the CA or LRA in connection with a certificate must be complete and accurate.

2.1.3.2 Protection of subscriber private key and key token

Subscribers are required to protect their private keys and key tokens (if applicable) in accordance with section 6, and to take all reasonable measures to prevent their loss, disclosure, modification, or unauthorised use.

2.1.3.3 Restrictions on End-Entity private key use

The Subscriber will use the keys and certificates only for the purposes identified in this CP.

Top of page

2.1.3.4 Notification upon private key compromise

Where a Subscriber suspects private key compromise, they must immediately notify the Issuing CA in a manner specified by that CA.

Where any other entity suspects private key compromise, they should immediately notify the Issuing CA.

2.1.4 Relying party obligations

The rights and obligations of a Relying Party who is a member of the CCRA PKI are covered in this policy. The rights and obligations of a Relying Party belonging to another PKI must be addressed in the cross-certification agreement between the two PKIs.

2.1.4.1 Use of certificates for appropriate purpose

Prior to using a Subscriber's certificate, a Relying Party must ensure that it is appropriate for the intended use.

2.1.4.2 Verification responsibility

A Relying Party must use certificates only in accordance with the certification path validation procedure specified in X.509 and PKIX protocols.

2.1.4.3 Revocation check responsibility

Prior to using a certificate, a Relying Party must check the status of the certificate against the appropriate and current CRL in accordance with the requirements stated in section 4.4.10. As part of this verification process the digital signature of the CRL must also be validated.

2.1.5 Repository obligations

The repository should be available for a high proportion of every 24-hour period. Certificates and CRLs must be available to Relying Parties in accordance with the requirements of section 4.4.9.

2.2 Liability

2.2.1 Requirements

The Issuing CA will ensure that its certification and repository services, issuance and revocation of certificates, and issuance of CRLs are in accordance with this CP. It will also take reasonable efforts to ensure that all LRAs and Subscribers will follow the requirements of this policy when dealing with any certificates containing this policy's OID or the associated keys.

CAs and LRAs will ensure that their authentication and validation procedures are implemented as set forth in section 3.

Top of page

2.2.2 Disclaimers of warranties and obligations

The Crown, in right of Canada, and CCRA assume no liability whatsoever in relation to the use of CCRA PKI certificates or associated public/private key pairs for any use other than in accordance with this CP and any other agreements, and Subscribers will indemnify them and save them harmless from any such liability.

The Crown, in right of Canada, and CCRA, their employees, servants or agents makes no representations, warranties or conditions, express or implied other than as expressly stated in this CP or in any other document.

No joint venture, partnership, trust, agency or fiduciary relationship is established or deemed to be established between the Crown and its citizens, trading partners or others using the CCRA PKI.

2.2.3 Limitations of liability

The Crown, in right of Canada and CCRA, disclaim any liability of any kind whatsoever for any award, damages or other claim or obligation of any kind arising from tort, contract or any other reason with respect to any service associated with the issuance, use of, or reliance upon, a CCRA PKI external medium level assurance certificate or its associated public/private key pair, in excess of $50,000 per instance of use by a Subscriber or Relying Party.

2.2.4 Other terms and conditions

The disclaimers and limitations of liability in sections 2.2.2 and 2.2.3 are subject to any signed contract or cross-certification agreement that may be entered into by the Crown and/or CCRA that provides otherwise. Any such disclaimers or limitations of liability must be consistent with this Certificate Policy.

Top of page

2.3 Financial responsibility

The CA will not contract for the provision of its CA services.

2.4 Interpretation and Enforcement

2.4.1 Governing law

The CA must ensure that any agreements will be governed by the laws of Canada and applicable provincial law concerning the enforceability, construction, interpretation and validity of this Certificate Policy. This agreement shall be governed by and construed in accordance with the laws of Canada and applicable provincial laws, exclusive of their conflict-of-laws principles.

2.4.2 Severability, survival, merger, notice

The CA must ensure that any agreements will contain appropriate provisions governing severability, survival, merger or notice.

2.4.3 Dispute resolution procedures

Any dispute related to key and certificate management between the CCRA and an organisation or individual outside of the CCRA should be resolved using an appropriate dispute settlement mechanism. A dispute should be resolved by negotiation if possible. A dispute not settled by negotiation should be resolved using an independent mediator acceptable to the parties to the dispute. A dispute not settled by mediation should be resolved through arbitration in accordance with the Commercial Arbitration Act.

A dispute related to key and certificate management between GoC departments should be resolved by negotiation if possible. A dispute not settled by negotiation should be resolved by the GoC PMA or, where appropriate, through a mediator or arbitrator(s) appointed by the GoC PMA.

The CA must ensure that any agreement it enters into provides appropriate dispute resolution procedures.

2.5 Fees

The charging of fees is subject to appropriate legislative authority and policy. Notice of any fee charged to a Subscriber or Relying Party must be brought to the attention of that Entity.

2.6 Publication and repository

The issuing CA must:

• include within any certificate or subscriber agreement it issues the URL of a web site maintained by, or on behalf of, the CA;
• ensure the publication of its CP, digitally signed by an authorised representative of the CA, on a web site maintained by, or on behalf, of the CA, the location of which must be indicated in compliance with section 8;
• ensure, directly or through agreement with a repository, that operating system and repository access controls will be configured so that only authorised CA personnel can write or modify the online version of the CP; and
• provide a full text version of the CPS when necessary for the purposes of any audit, inspection, accreditation or cross-certification.

Access controls may be instituted at the discretion of the CA with respect to certificates or on-line certificate status (if the latter is provided as a service by the CA). Certificates must be published promptly upon issuance. The CA must ensure, directly or with agreement with a repository, unrestricted access to CRLs. CRL publication must be in accordance with section 4.

2.7 Compliance inspection

A compliance inspection determines whether the CA's performance meets the standards established in its CPS and satisfies the requirements of the CPs it supports.

2.7.1 Frequency of compliance inspection

The CA issuing certificates pursuant to this CP must establish to the satisfaction of any CA with whom it cross certifies that it fully complies via compliance inspection with the requirements of this policy:

• prior to initial cross-certification with a GoC PKI CA; and
• as a minimum every twelve months thereafter.

Top of page

One of every five inspections must be done by an agency external to the CCRA. The CCRA and GoC PMAs, at their discretion, may request CCRA's commissioner to have a compliance inspection by an agency external to the agency at any time.

The CA must certify annually to the CCRA PMA that they have at all times during the period in question complied with the requirements of this policy. The CA must also provide to the CCRA PMA reasons for which the CA has not complied with its CP and state any periods of non-compliance.

2.7.2 Identity/qualifications of CA inspector

Any person or entity, external to the GoC, seeking to perform a compliance inspection must possess significant experience with PKI and cryptographic technologies as well as the operation of relevant PKI software.

2.7.3 Inspector's relationship to audited CA

Where an inspector is within the GoC, the inspector must be independent of the CA.

Where an inspector is external to the GoC, the inspector must be independent of the CA and must comply with the provisions of the Conflict of Interest and Post-Employment Code for Public Office Holders or the Conflict of Interest and Post-Employment Code for the Public Service. No person may be appointed an inspector to perform an inspection who is, whose partner is, or a member of whose firm is:

No member of the House of Commons or the Senate shall be admitted to share any part of a contract between the inspector and the Government of Canada, nor any resulting benefit.

2.7.4 Topics covered by inspection

The compliance inspection must follow the inspection guidelines instituted by the CCRA PMA. This will include whether:

• a CPS outlines, in sufficient detail, the technical, procedural and personnel policies and practices of the CA which meet the requirements of all the certificate policies supported by the CA;
• the CA implements and complies with those technical, procedural and personnel practices and policies; and
• an LRA, if used, implements and complies those technical, procedural and personnel practices and policies set out by the CA.

2.7.5 Actions taken as a result of inspection

The inspection results must be submitted to the CCRA PMA. If irregularities are found, the CA must submit a report to the CCRA and GoC PMAs as to any action the CA will take in response to the inspection report. Where the CA fails to take appropriate action in response to the inspection report, the CCRA PMA may:

• indicate the irregularities, but allow the CA to continue operations until the next programmed inspection; or
• allow the CA to continue operations for a maximum of thirty days pending correction of any problems prior to revocation; or
• downgrade the assurance level of any cross-certificates; or
• revoke the CA's certificate.

Where the CCRA PMA fails to take any action, the GoC PMA may:

• downgrade the assurance level of the cross-certificate with the CCF; or
• revoke the CA's cross certificate with the CCF.

Any decision regarding which of these actions to take will be based on the severity of the irregularities.

Top of page

2.7.6 Communication of results

CAs cross-certified with the CCF must provide the GoC PMA with a copy of the results of the compliance inspection. These results will not be made public unless required by law. The method and detail of notification of inspection results to CAs cross-certified with the CA must be defined within the cross-certification agreement between the two parties.

2.8 Confidentiality of information

Certificates and CRLs, and personal or corporate information appearing on them and in public directories, are not considered sensitive, (sensitive in accordance with the Government Security Policy). All other personal or corporate information held by the CA or an LRA (e.g., registration and revocation information, logged events, correspondence between the Subscriber and the CA or LRA, etc.) is considered sensitive and must not be disclosed without the prior consent of the Subscriber, unless required by law.

The Digital Signature private key of each Subscriber is to be held only by the Subscriber and must be kept confidential by them. Any disclosure by the Subscriber is at the Subscriber's own risk.

Inspection information is to be considered sensitive and must not be disclosed to anyone for any purpose other than inspection purposes or where required by law.

Information pertaining to the CA's management of a Subscriber's Digital Signature certificate may only be disclosed to the Subscriber, the Sponsor or where required by law.

Any requests for the disclosure of information must be signed and delivered to the CA.

Any disclosure of information is subject to the requirements of the Privacy Act, the Access to Information Act, other relevant legislation and any applicable Government of Canada policy.

2.9 Intellectual property rights

No stipulation

3. Identification and Authentication

3.1 Initial Registration

3.1.1 Types of names

Each Entity must have a clearly distinguishable and unique X.501 Distinguished Name (DN) in the certificate subject name field and in accordance with PKIX Part 1. Each Entity may use an alternative name via the SubjectAlternateName field, which must also be in accordance with PKIX Part 1. The DN must be in the form of a X.501printableString and must not be blank.

3.1.2 Need for names to be meaningful

The contents of each certificate Subject and Issuer name fields must have an association with the authenticated name of the Entity. In the case of individuals the Relative Distinguished Name (RDN) should be a combination of first name, surname, and optionally initials. This RDN may also include an organisational position or role. In the case of other entities the RDN will reflect the authenticated legal name of the Entity.

Where a certificate refers to a role or position, the certificate must also contain the identity of the person who holds that role or position.

A certificate issued for a device or application must include within the DN the name of the person or organisation responsible for that device or application.

3.1.3 Rules for interpreting various name forms

No stipulation

3.1.4 Uniqueness of names

Distinguished names must be unique for all End-Entities of a CA. For each End-Entity additional numbers or letters may be appended to the commonName to ensure the RDN's uniqueness. The Unique Identifiers capability to differentiate Subscribers with identical names will not be supported.

Top of page

3.1.5 Name claim dispute resolution procedure

The CA reserves the right to make all decisions regarding Entity names in all assigned certificates. A party requesting a certificate must demonstrate its right to use a particular name.

Where there is a dispute about a name in a repository not under its control, the CA must ensure that there is a name claim dispute resolution procedure in its agreement with that repository.

3.1.6 Recognition, authentication and roles of trademarks

The use of trademarks will be reserved to registered trademark holders.

3.1.7 Method to prove possession of private key

Prior to the issuance of a verification certificate, the Issuing CA and End-Entity will confirm their respective identities through the use of a shared secret.

The key transfer protocol described in PKIX Certificate Management Protocol is suitable for this requirement.

3.1.8 Authentication of organisation identity

These certificates are not intended for use by organisations. Where the technology does not permit the independent generation of Digital Signature and Confidentiality key pairs, the Digital Signature key pair shall not be used.

3.1.9 Authentication of individual identity

An application for an individual to be a Subscriber may be made by the individual or by another person or organisation authorised to act on behalf of the prospective Subscriber.

Identification and authentication of the individual must be through one of the following means:

• the CA or LRA will compare the identity of the individual with two pieces of identification (notarised copies or originals). At least one of these must be government identification containing a photograph; or
• if the agency has previously established the identity of an individual using a process that satisfies the CA, and there have been no changes in the information presented, then the CA or LRA and the individual may utilise this privately shared information.

The CA or LRA must keep a record of the type and details of identification used.

3.1.10 Authentication of devices or applications

An application for a device or application to be an End-Entity may be made by an individual or organisation to which the device's or application's signature is attributable for the purposes of accountability and responsibility.

Identification and authentication of the applicant must follow sections 3.1.8 or 3.1.9 as if that individual or organisation was applying for the certificate on their own behalf.

The CA or LRA must also verify the identity of the individual or organisation making the application and their authority to receive the keys for that device or application.

The CA or LRA must keep a record of the type and details of identification used.

3.2 Authentication for routine re-key

A request for re-key may only be made by the Entity in whose name the keys have been issued. All requests for re-key must be authenticated by the CA, and the subsequent response must be authenticated by the Entity. This may be done by an on-line method in accordance with PKIX Part 3 - Certificate Management Protocol. An Entity requesting re-key may authenticate the request for re-key using its valid Digital Signature key pair. Where one of the keys has expired the request for re-key must be authenticated in the same manner as the initial registration.

Top of page

3.3 Authentication for re-key after revocation

Where the information contained in a certificate has changed or there is a known or suspected compromise of the private key, the CA must authenticate a re-key in the same manner as for initial registration. Any change in the information contained in a certificate must be verified by the CA or the LRA authorised to act on behalf of that CA before that certificate is issued.

3.4 Authentication of revocation request

The CA, or an LRA acting on its behalf, must authenticate a request for revocation of a certificate. The CA must establish and make publicly available the process by which it addresses such requests and the means by which it will establish the validity of the request.

Requests for revocation of certificates must be logged.

4. Operational Requirements

4.1 Application for a certificate

The CA must ensure that all procedures and requirements with respect to an application for a certificate are set out in the CPS or a publicly available document. Bulk applications on behalf of End-Entities are permitted to be made only by persons authorised to make such applications.

The CA must ensure that each application be accompanied by:

• proof of the End-Entity's identity;
• proof of authorisation for any requested certificate attributes;
• an agreement signed by the End-Entity, of the applicable terms and conditions governing use of the certificate;
• a public verification key generated by the End-Entity.

An application for a certificate does not oblige the CA to issue a certificate.

4.1.1 Application for a cross-certificate

The CCF or the CA will identify all procedures and requirements with respect to an application for a cross-certificate in its cross-certification procedures.

A CA requesting cross-certification through the CCF or the CA must ensure that each application be accompanied by:

• its Certificate Policy;
• a compliance inspection report validating the assurance level stated in the CP;
• the public verification key generated by the CA.

An application for a cross-certificate does not oblige the CCF or the CA to issue a cross-certificate.

4.2 Certificate issuance

The issuance and publication of a certificate by the CA indicates a complete and final approval of the certificate application by the CA.

4.3 Certificate acceptance

The CA must ensure that an Entity acknowledges acceptance of a certificate. For a device or application this acknowledgement may be done by the individual or organisation responsible for the device or application.

Top of page

4.4 Certificate Suspension and Revocation

4.4.1 Circumstances for revocation

A certificate must be revoked:

• when any of the information in the certificate changes;
• upon suspected or known compromise of the private key;
• upon suspected or known compromise of the media holding the private key.

The CA in its discretion may revoke a certificate when an Entity fails to comply with obligations set out in this CP, the CPS, any agreement or any applicable law.

Where the CA is cross-certified with the CCF, the CCF must revoke a cross-certificate:

• when any of the information in the certificate changes;
• upon suspected or known compromise of the private key;
• upon suspected or known compromise of the media holding the private key.

The GoC or CCRA PMA, in its discretion, may revoke a cross-certificate when a CA fails to comply with obligations set out in this CP, its related CPS, any agreement or any applicable law.

4.4.2 Who can request revocation

The revocation of a certificate may only be requested by:

• the Subscriber in whose name the certificate was issued;
• the individual or organisation which made the application for the certificate on behalf of a device or application;
• the Sponsor;
• personnel of the Issuing CA;
• personnel of an LRA associated with the Issuing CA.

The revocation of a cross-certificate may only be requested by:

• the CA on whose behalf the cross-certificate was issued;
• the personnel operating the CCF;
• the GoC or CCRA PMA.

4.4.3 Procedure for revocation request

The CA must ensure that all procedures and requirements with respect to the revocation of a certificate are set out in the CPS or otherwise made publicly available. An authenticated revocation request, and any resulting actions taken by the CA, must be recorded and retained. In the case where a certificate is revoked, full justification for the revocation must also be documented.

Where an Entity certificate is revoked, the revocation will be published in the appropriate CRL. Where a cross-certificate is revoked the revocation will be published in the ARL of the Issuing CA.

Top of page

4.4.4 Revocation request grace period

Any action taken as a result of a request for the revocation of a certificate must be initiated immediately if the request is received during local business hours of the CA or within twelve (12) hours of receipt.

4.4.5 Circumstances for Certificate Suspension (Deactivating Subscribers)

The CCRA CA may suspend (deactivate) subscribers who leave for an extended period of time, for example, on maternity leave. The CCRA CA may also suspend subscribers' certificates while revocation requests are being verified.

4.4.6 Who Can Request Suspension (Deactivation)

Suspensions (deactivations) may be requested by:

• Subscribers.
• Individual who made the application for the certificate on behalf of a device or application.
• Sponsors.
• LRA officers, on behalf of a sponsor or subscriber.
• CCRA CA personnel.

4.4.7 Procedure for Suspension (Deactivation) Request

When the request comes from a subscriber or a sponsor, they must submit it to an LRA officer via a digitally signed e-mail message. The LRA officer will forward the request to the CCRA CA in a similar fashion. When the request comes from an LRA officer, they must submit it directly to the CCRA CA via a digitally signed e-mail message.

The procedure for processing revocation requests is as follows:

• The request is submitted to the CCRA CA as described above.
• The signature on the request is verified.
• If justified, the subscriber's certificates are suspended (deactivated) and their LRA officer is notified.
• The LRA officer notifies the subscribers when their certificates have been suspended (deactivated).
• Certificates are suspended (deactivated) upon receipt of the request by the CCRA CA without notification.

Subscribers must present themselves in person to an LRA officer to request re-activation of their suspended (deactivated) certificates.

4.4.8 Limits on Suspension (Deactivation) Period

No limitations apply. Certificates will expire as defined in section 6.3.2.

4.4.9 CRL issuance frequency

The CA must ensure that it issues an up to date CRL at least every twelve hours. The CA must also ensure that its CRL issuance is synchronised with any directory synchronisation to ensure the accessibility of the most recent CRL to Relying Parties. When a certificate is revoked due to key compromise the updated CRL must be issued immediately.

4.4.10 CRL checking requirements

A Relying Party must check the status of all certificates in the certificate validation chain against the current CRLs and ARLs prior to their use. A Relying Party must also verify the authenticity and integrity of CRLs and ARLs.

Top of page

4.4.11 On-line revocation/status checking availability

The CCRA PKI does not currently support online revocation/status checking availability.

4.4.12 On-line revocation checking requirements

Not applicable.

4.4.13 Other forms of revocation advertisements available

Not applicable.

4.4.14 Checking requirements for other forms of revocation advertisements

Not applicable.

4.4.15 Special requirements re: Key compromise

In the event of the compromise, or suspected compromise, of the CA signing key, the CA must immediately notify all CAs to whom it has issued cross-certificates and the CCRA and GoC PMAs.

In the event of the compromise, or suspected compromise, of any other Entity's signing key, an Entity must notify the Issuing CA immediately.

The CA must ensure that its CPS or a publicly available document and appropriate agreements contain provisions outlining the means it will use to provide notice of compromise or suspected compromise.

4.5 System Security Audit Procedures

4.5.1 Types of event recorded

The CA should record in audit log files all events relating to the security of the CA system. These include such events as:

• system start-up and shutdown;
• CA application start-up and shutdown;
• attempts to create, remove, set passwords or change the system privileges of the PKI Master Officer, PKI Officer, or PKI Administrator;
• changes to CA details and/or keys;
• changes to certificate creation policies e.g., validity period;
• login and logoff attempts;
• unauthorised attempts at network access to the CA system;
• unauthorised attempts to access system files;
• generation of own and subordinate Entity keys;
• creation and revocation of certificates;
• attempts to initialise, remove, enable, and disable Subscribers, and update and recover their keys;
• failed read-and-write operations on the certificate and CRL directory.

All logs, whether electronic or manual, should contain the date and time of the event, and the identity of the entity which caused the event.

Top of page

The CA should also collect and consolidate, either electronically or manually, security information not CA-system generated such as:

• physical access logs;
• system configuration changes and maintenance;
• personnel changes;
• discrepancy and compromise reports;
• records of the destruction of media containing key material, activation data, or personal Subscriber information.

The CA must ensure that the CPS indicates what information is logged.

To facilitate decision-making, all agreements and correspondence relating to CA services should be collected and consolidated, either electronically or manually, in a single location.

4.5.2 Frequency of audit log processing

The CA must ensure that its audit logs are reviewed by CA personnel at least once every week and all significant events are explained in an audit log summary. Such reviews involve verifying that the log has not been tampered with, and then briefly inspecting all log entries, with a more thorough investigation of any alerts or irregularities in the logs. Supporting manual and electronic logs from the CA and LRA should be compared where any action is deemed suspicious.

Actions taken following these reviews must be documented.

4.5.3 Retention period of audit log

The CA must retain its audit logs onsite for at least two months and subsequently retain them in the manner described in section 4.6.

4.5.4 Protection of audit log

The electronic audit log system must include mechanisms to protect the log files from unauthorised viewing, modification, and deletion.

Manual audit information must be protected from unauthorised viewing, modification and destruction.

4.5.5 Audit log back-up procedures

Audit logs and audit summaries must be backed up or copied if in manual form.

4.5.6 Audit collection system

The CA must identify its audit collection systems in the CPS.

4.5.7 Notification to event causing subject

Where an event is logged by the audit collection system no notice need be given to the individual, organisation, device or application which caused the event.

4.5.8 Vulnerability assessments

Events in the audit process are logged, in part, to monitor system vulnerabilities. The CA must ensure that a vulnerability assessment is performed, reviewed and revised following an examination of these monitored events.

Top of page

4.6 Records archival

Digital Signature certificates, Confidentiality private keys stored by the CA, and ARLs and CRLs generated by the CA, must be retained for at least one year after the expiration of the key material. This requirement does not include the back-up of private signature keys.

Audit information as detailed in section 4.5, Subscriber agreements and any identification and authentication information should be retained for at least six years.

Confidentiality private keys that are backed up by the CA are to be protected at a level of physical and cryptographic protection equal to or exceeding that in place at the CA site.

A second copy of all material retained or backed up must be stored in a location other than the CA site and must be protected either by physical security alone, or a combination of physical and cryptographic protection. Any such secondary site must provide adequate protection from environmental threats such as temperature, humidity and magnetism.

The CA should verify the integrity of the back-ups once every six months.

Material stored off-site must be periodically verified for data integrity.

In addition to the foregoing, information retained or backed up by the CA may be subject to the National Archives Act.

4.7 Key changeover

A Subscriber may only apply to renew his or her key pair within three months prior to the expiration of one of the keys, provided the previous certificate has not been revoked. A subscriber, the CA, or the LRA may initiate this key changeover process. Automated key changeover is permitted. The CA must ensure that the details of this process are indicated in its CPS.

Subscribers without valid keys must be re-authenticated by the CA or LRA in the same manner as the initial registration.

Where a Subscriber's certificate has been revoked as a result of non-compliance, the CA must verify that any reasons for non-compliance have been addressed to its satisfaction prior to certificate re-issuance.

Keys may not be renewed using an expired Digital Signature key.

4.8 Compromise and Disaster Recovery

4.8.1 Computing resources, software, and/or data are corrupted

The CA must establish business continuity procedures that outline the steps to be taken in the event of the corruption or loss of computing resources, software and/or data. Where a repository is not under the control of the CA, the CA must ensure any agreement with the repository provides that business continuity procedures be established and documented by the repository.

4.8.2 Entity public certificate is revoked

In the event of the need for revocation of the CA's Digital Signature certificate, the CA must immediately notify:

• the CCRA and GoC PMAs;
• all CAs to whom it has issued cross-certificates;
• all of its LRAs;
• all Subscribers;
• all individuals or organisations who are responsible for a certificate used by a device or application.

The CA must also:

• publish the certificate serial number on an appropriate CRL;
• revoke all cross-certificates signed with the revoked Digital Signature certificate.

Top of page

After addressing the factors that led to revocation, the CA may:

• generate a new CA signing key pair;
• re-issue certificates to all Entities and ensure all CRLs and ARLs are signed using the new key.

In the event of the need for revocation of any other Entity's Digital Signature certificate see section 4.4.

4.8.2.1 Entity public certificate is downgraded

In the event of the need for the downgrade of a CA's Digital Signature certificate, the CA must immediately notify:

• the GoC and CCRA PMAs;
• all CAs to whom it has issued cross-certificates;
• all of its LRAs;
• all Subscribers;
• all individuals or organisations who are responsible for a certificate used by a device or application.

Prior to re-establishing cross-certification the CA must also:

• request revocation of cross-certificates issued to the CA;
• revoke all certificates signed with the higher assurance key;
• provide appropriate notice (see section 4.8.2);
• generate a new CA signing key pair;
• re-issue certificates to all Entities and ensure all CRLs and ARLs are signed using the new key.

In the event of the need for downgrade of any other Entity's Digital Signature certificate the CA or LRA must notify the subscriber in a manner set out in its CPS and the subscriber agreement.

4.8.3 Entity key is compromised

In the event of the compromise of the CA's Digital Signature key, prior to re-certification within the CCRA and GoC PKI, the CA must:

• request revocation of cross-certificates issued to the CA;
• revoke all certificates issued using that key;
• provide appropriate notice (see section 4.8.2).

After addressing the factors that led to key compromise, the CA may:

• generate a new CA signing key pair;
• re-issue certificates to all Entities and ensure all CRLs and ARLs are signed using the new key.

In the event of the compromise, or suspected compromise, of any other Entity's Digital Signature key, the Entity must notify the Issuing CA immediately.

The CA must ensure that its CPS and appropriate agreements contain provisions outlining the means it will use to provide notice of compromise or suspected compromise.

Top of page

4.8.4 Secure facility after a natural or other type of disaster

The CA must establish a disaster recovery plan outlining the steps to be taken to re-establish a secure facility in the event of a natural or other type of disaster. Where a repository is not under the control of the CA, the CA must ensure that any agreement with the repository provides that a disaster recovery plan be established and documented by the repository.

4.9 CA termination

In the event that the CA ceases operation, it must notify its Subscribers immediately upon the termination of operations and arrange for the continued retention of the CA's keys and information. It must also notify all CA's with whom it is cross-certified.

In the event of a change in management of the CA's operations, the CA must notify all Entities for which it has issued certificates and CA's with whom it has cross-certified.

In the event of a transfer of the CA's operations to another CA operating at a lower level of assurance the certificates issued by the CA whose operations are being transferred must be revoked through a CRL signed by that CA prior to the transfer.

The CA archives should be retained in the manner and for the time indicated in section 4.6.

5. Physical, Procedural and Personnel Security

5.1 Physical Controls

5.1.1 Site location, construction and physical access for the CA

The CA site must:

• satisfy at least the requirements for a Security Zone;
• be manually or electronically monitored for unauthorised intrusion at all times;
• ensure unescorted access to the CA server is limited to those personnel identified on an access list;
• ensure personnel not on the access list are properly escorted and supervised;
• ensure a site access log is maintained and inspected periodically; and
• ensure all removable media and paper containing sensitive plain text information are stored in containers either listed in, or of equivalent strength to those listed in, the Security Equipment Guide.

5.1.2 Site location, construction and physical access for LRA and Subscribers

All LRA sites must be located in areas that satisfy the controls required for a Reception Zone.

If an LRA workstation is used for on-line Entity management with the CA, the workstation must be located in either:

• an Operations Zone; or
• a Reception Zone while attended with all media security protected when unattended.

The CA will ensure the operation of the LRA site provides appropriate security protection of the cryptographic module, all system software and the LRA Administrator's private key. The CA must conduct a threat and risk assessment. For example, the cryptographic module and the LRA Administrator's private key could be stored in a secure container or safe.

Where a PIN or password is recorded, it must be stored in a security container accessible only to authorised personnel.

Top of page

Subscribers must not leave their workstations unattended when the cryptography is in an unlocked state (i.e., when the PIN or password has been entered). A workstation that contains private keys on a hard drive must be physically secured or protected with an appropriate access control product.

5.1.3 Power and air conditioning

The CA must ensure that the power and air conditioning facilities are sufficient to support the operation of the CA system.

5.1.4 Water exposure

The CA must ensure that the CA system is protected from water exposure.

5.1.5 Fire prevention and protection

The CA must ensure that the CA system is protected with a fire suppression system.

5.1.6 Media storage

The CA must ensure that storage media used by the CA system is protected from environmental threats such as temperature, humidity and magnetism.

5.1.7 Waste disposal

All media used for the storage of information such as keys, activation data or CA files is to be sanitised or destroyed before being released for disposal.

5.1.8 Off-site back-up

The CA must ensure that facilities used for off-site back-up, if any, have the same level of security as the primary CA site.

5.2 Procedural Controls

5.2.1 Trusted Roles

5.2.1.1 CA trusted roles

The CA must ensure a separation of duties for critical CA functions to prevent one person from maliciously using the CA system without detection. Each user's system access is to be limited to those actions for which they are required to perform in fulfilling their responsibilities.

The CA should provide for a minimum of three distinct PKI personnel roles, distinguishing between day-to-day operation of the CA system, the management and audit of those operations and the management of substantial changes to requirements on the system including its policies, procedures or personnel. The division of responsibilities between the three roles should be as follows:

• PKI Master User
  • configuration and maintenance of the CA system hardware and software;
  • commencement and cessation of CA services.
  
  
  
• PKI Officer
  • management of PKI Operators and other PKI Officers;
  • configuring CA security policies;
  • verification of audit logs;
  • verification of CP and CPS compliance.
  
  
  
• PKI Administrator
  • management of the Subscriber initialisation process;
  • creation, renewal or revocation of certificates;
  • distribution of tokens (where applicable).

An alternative division of responsibilities is permitted so long as it provides the same degree of resistance to insider attack.

Only those personnel responsible for the duties outlined for PKI Master User and System Administrator should have access to the software that controls the CA operation.

Top of page

5.2.1.2 LRA trusted roles

The CA must ensure that LRA personnel understand their responsibility for the identification and authentication of prospective Subscribers and perform the following functions:

• acceptance of subscription, certificate change, certificate revocation and key recovery requests;
• verification of an applicant's identity and authorisations;
• transmission of applicant information to the CA;
• provision of authorisation codes for on-line key exchange and certificate creation.

The CA may permit all duties for LRA functions to be performed by one individual.

5.2.2 Number of persons required per task

The CA must ensure that no single individual may gain access to Subscriber private keys stored by the CA. At a minimum two individuals, preferably using a split-knowledge technique, such as twin passwords, must perform any key recovery operation.

Multi-user control is also required for CA key generation as outlined in section 6.2.2.

All other duties associated with CA roles may be performed by an individual operating alone. The CA must ensure that any verification process it employs provides for oversight of all activities performed by privileged CA role holders.

5.2.3 Identification and authentication for each role

All CA personnel must have their identity and authorisation verified before they are:

• included in the access list for the CA site;
• included in the access list for physical access to the CA system;
• given a certificate for the performance of their CA role;
• given an account on the PKI system.

Each of these certificates and accounts (with the exception of CA signing certificates) must:

• be directly attributable to an individual;
• not be shared;
• be restricted to actions authorised for that role through the use of CA software, operating system and procedural controls.

CA operations must be secured, using mechanisms such as token-based strong authentication and encryption, when accessed across a shared network.

Top of page

5.3 Personnel security controls

The CA must ensure that all personnel performing duties with respect to the operation of the CA or LRA must:

• be appointed in writing;
• be bound by contract or statute to the terms and conditions of the position they are to fill;
• have received comprehensive training with respect to the duties they are to perform;
• be bound by statute or contract not to disclose sensitive CA security-relevant information or Subscriber information; and
• not be assigned duties that may cause a conflict of interest with their CA or LRA duties.

5.3.1 Background, qualifications, experience and clearance requirements

The CA must ensure that all personnel performing duties with respect to the operation of the CA must hold a Level II Security Clearance. The CA must ensure that all personnel who operate an LRA workstation for the purpose of on-line Entity management with the CA must hold an ERC (Enhanced Reliability Check) as per the CCRA security policy.

5.3.2 Background check procedures

All background checks must be performed in accordance with the Government Security Policy.

5.3.3 Training requirements

The CA must ensure that all personnel performing duties with respect to the operation of the CA or LRA must receive comprehensive training in:

• the CA/LRA security principles and mechanisms;
• all PKI software versions in use on the CA system;
• all PKI duties they are expected to perform; and
• disaster recovery and business continuity procedures.

5.3.4 Retraining frequency and requirements

The requirements of 5.3.3 must be kept current to accommodate changes in the CA system. Refresher training must be conducted as required, and the CA must review these requirements at least once a year.

5.3.5 Job rotation

No stipulation.

5.3.6 Sanctions for unauthorised actions

In the event of actual or suspected unauthorised action by a person performing duties with respect to the operation of the CA or LRA, the CA will take action immediately which may suspend his or her access to the CA system.

5.3.7 Contracting personnel

CA must ensure that contractor access to the CA site is in accordance with section 5.1.1.

Top of page

5.3.8 Documentation supplied to personnel

The CA must make available to its CA and LRA personnel the certificate policies it supports, its CPS, and any specific statutes, policies or contracts relevant to their position.

6. Technical Security Controls

6.1 Key Pair Generation and Installation

6.1.1 Key pair generation

Each prospective certificate holder must generate its own Digital signature key pair using a CCRA PMA-approved algorithm.

6.1.2 Private key delivery to entity

Not applicable

6.1.3 Public key delivery to certificate issuer

The public verification key must be delivered to the CA via an on-line transaction in accordance with the PKIX-3 Certificate Management Protocol, or via an equally secure manner approved by the CCRA PMA.

6.1.4 CA public key delivery to users

The CA public verification key must be delivered to the prospective certificate holder in an on-line transaction in accordance with PKIX-3 Certificate Management Protocol, or via an equally secure manner approved by the CCRA PMA.

6.1.5 Asymmetric key sizes

The CA must ensure that the key pairs for all PKI entities must be either 1024 bit RSA or DSA or 2048 bit RSA.

6.1.6 Public key parameters generation

A CA that utilises the DSA must generate parameters in accordance with FIPS 186.

6.1.7 Parameter quality checking

Not applicable.

6.1.8 Hardware/software key generation

CA Digital signature key pairs must be generated in a hardware cryptographic module. Key pairs for all other Entities may be generated in a software or hardware cryptographic module.

6.1.9 Key usage purposes (as per X.509v3 field)

Keys may be used for authentication, non-repudiation and data integrity. They may also be used for session key establishment. CA signing keys are the only keys permitted to be used for signing certificates and CRLs.

The certificate KeyUsage field must be used in accordance with PKIX-1 Certificate and CRL Profile. One of the following KeyUsage values must be present in all certificates:

• Digital Signature, or
• Non-Repudiation.

Top of page

One of the following additional values must be present in CA certificate-signing certificates:

• Key Cert Sign, or
• CRL Sign.

6.2 Private key protection

The certificate holder must protect their private keys from disclosure.

The private keys of Entities must be protected from unauthorised use by a combination of cryptographic and physical access control mechanisms. The level of protection must be adequate to deter a motivated attacker with substantial resources. If a reusable password scheme is used, the mechanism should include a facility to temporarily lock the account after a predetermined number of login attempts.

6.2.1 Standards for crypto-module

Refer to section 6.8 of this policy.

6.2.2 Private key multi-person control

There must be multiple person control for CA key generation operations. Two staff, performing duties associated with the roles of PKI Master User or PKI Officer positions, must participate or be present.

There must be multiple person control for private key recovery. Two staff, performing duties associated with the roles of PKI Master User, PKI Officer or PKI Administrator, must participate or be present.

6.2.3 Private key escrow

Digital Signature private keys must not be escrowed.

6.2.4 Private key back-up

An Entity may optionally back-up its own Digital Signature private key. If so, the keys must be copied and stored in encrypted form and protected at a level no lower than stipulated for the primary version of the key.

6.2.5 Private key archival

Refer to section 4.6.

6.2.6 Private key entry into cryptographic module

Not applicable.

6.2.7 Method of activating private key

The Entity must be authenticated to the cryptographic module before the activation of the private key. This authentication may be in the form of a password. When deactivated, private keys must be kept in encrypted form only.

6.2.8 Method of deactivating private key

When keys are deactivated they must be cleared from memory before the memory is de-allocated. Any disk space where keys were stored must be over-written before the space is released to the operating system. The cryptographic module must automatically deactivate the private key after a pre-set period of inactivity.

Top of page

6.2.9 Method of destroying private key

Upon termination of use of a private key, all copies of the private key in computer memory and shared disk space must be securely destroyed by over-writing. The method of over-writing must be approved by the CCRA PMA. Private key destruction procedures must be described in the CPS or other publicly available document.

6.3 Other Aspects of Key Pair Management

6.3.1 Public key archival

The issuing CA must retain all verification public keys.

6.3.2 Usage periods for the public and private keys

1024 bit keys must have validity periods of no more than two years.

2048 bit keys must have validity periods of no more than twenty years.

Suggested validity period (1024):

• CA public verification key and certificate - two years;
• CA private signing key - one year;
• End-Entity public verification key and certificate -one year;
• End-Entity private signing key six months.

Suggested validity period (2048):

• CA public verification key and certificate - twenty years;
• CA private signing key - eight years;
• End-Entity public verification key and certificate twelve years;
• End-Entity private signing key -two years.

Use of particular key lengths should be determined in accordance with CCRA threat-risk assessments.

6.4 Activation Data

6.4.1 Activation data generation and installation

Any activation data must be unique and unpredictable. The activation data, in conjunction with any other access control, must have an appropriate level of strength for the keys or data to be protected. Where passwords are used, an Entity must have the capability to change its password at any time.

6.4.2 Activation data protection

Data used for Entity initialisation must be protected from unauthorised use by a combination of cryptographic and physical access control mechanisms.

6.4.3 Other aspects of activation data

No stipulation.

Top of page

6.5 Computer Security Controls

6.5.1 Specific computer security technical requirements

CA servers must include the following functionality:

• access control to CA services and PKI roles;
• enforced separation of duties for PKI roles;
• identification and authentication of PKI roles and associated identities;
• object re-use or separation for CA random access memory;
• use of cryptography for session communication and database security;
• archival of CA and End-Entity history and audit data;
• audit of security related events;
• self-test of security related CA services;
• trusted path for identification of PKI roles and associated identities;
• recovery mechanisms for keys and the CA system.

This functionality may be provided by the operating system, or through a combination of operating system, PKI CA software, and physical safeguards.

6.5.2 Computer security rating

Computer Security Rating (CC Evaluation level) TBD.

CSE, NSA or other accredited third party laboratory must evaluate the security critical elements of the CA. Such an evaluation must include system-level analysis.

6.6 Life Cycle Technical Controls

6.6.1 System development controls

The CA must use CA software that has been designed and developed under development methodology such as MIL-STD-498, the System Security Engineering Capability Maturity Model (SSE CMM), or Information Systems Security Engineering Handbook.

The design and development process must be supported by third party verification of process compliance and ongoing Threat Risk Assessments to influence security safeguard design and minimise residual risk.

6.6.2 Security management controls

A formal configuration management methodology must be used for installation and ongoing maintenance of the CA system. The CA software, when first loaded, must provide a method for the CA to verify that the software on the system:

• originated from the software developer;
• has not been modified prior to installation; and
• is the version intended for use.

The CA must provide a mechanism to periodically verify the integrity of the software.

The CA must also have mechanisms and policies in place to control and monitor the configuration of the CA system.

Upon installation, and at least once a week, the integrity of the CA system must be validated.

Top of page

6.7 Network Security Controls

The CA server must be protected from attack through any open or general purpose network with which it is connected. Such protection must be provided through the installation of a device configured to allow only the protocols and commands required for the operation of the CA.

The CA must ensure that its CPS defines those protocols and commands required for the operation of the CA.

6.8 Cryptographic module engineering controls

All CA Digital Signature key generation, CA Digital Signature key storage and certificate signing operations must be performed in a hardware cryptographic module rated to at least FIPS 140-1 Level 2 or otherwise verified to an equivalent level of functionality and assurance. All other CA cryptographic operations must be performed in a cryptographic module validated to at least FIPS 140-1 Level 2 or otherwise verified to an equivalent level of functionality.

The LRA Administrator Digital Signature key generation and signing operations must be performed in a hardware cryptographic module rated to at least FIPS 140-1 Level 1 or otherwise verified to an equivalent level of functionality and assurance.

All other LRA cryptographic operations must be performed in cryptographic modules rated at FIPS 140-1 Level 1 or otherwise verified to an equivalent level of functionality and assurance.

End Entities must use cryptographic modules validated to at least FIPS 140-1 Level 1 or otherwise verified to an equivalent level of functionality and assurance.

7. Certificate and CRL Profiles

7.1 Certificate profile

7.1.1 Version number

The CA must issue X.509 Version 3 certificates, in accordance with the PKIX Certificate and CRL Profile.

The PKI End-Entity software must support all the base (non-extension) X.509 fields:

• Signature: CA signature to authenticate certificate
• Issuer: name of CA
• Validity: activation and expiry date for certificate
• Subject: subscriber's distinguished name
• Subject Public Key Information: algorithm ID, key
• Version: version of X.509 certificate, version 3(2)
• Serial Number: unique serial number for certificate

as well as the certificate extensions defined in section 7.1.2.

7.1.2 Certificate extensions

All Entity PKI software must correctly process the extensions identified in sections 4.2.1 and 4.2.2 of the PKIX certificate profile. The CPS must define the use of any extensions supported by the CA, its LRAs and End Entities.

The certificatePolicies field must be set as critical in all CCRA PKI certificates.

Top of page

7.1.3 Algorithm object IDs, CRL distribution points for different assurance levels

The CA must use and End-entities must support, for signing and verification, the following algorithms:

• RSA 1024 or 2048 in accordance with PKCS#1 -[OID TBD];
• SHA-1 in accordance with FIPS PUB 180-1 and ANSI X9.30 (Part 2) - [ID sha1WithRSAEncryption, OID 1 2 840 113549 1 1 5, Issuing Authority RSADSI].

Entities may use, for signing and verification, the following algorithms:

• RSA 1024, RSA 2048 in accordance with PKCS#1 - [OID TBD];
• DSA in accordance with DSS (FIPS PUB 186) and ANSI X9.30 (Part 1) - [OID TBD];
• MD5 in accordance with RFC 1321 - [OID TBD];
• SHA-1 in accordance with FIPS PUB 180-1 and ANSI X9.30 (Part 2) - [ID sha1WithRSAEncryption, OID 1 2 840 113549 1 1 5, Issuing Authority RSADSI].

7.1.4 Name forms

Every DN must be in the form of an X.501 printableString.

7.1.5 Name constraints

Subject and Issuer DNs must comply with PKIX standards and be present in all certificates.

7.1.6 Certificate Policy object identifier

The CA must ensure that the Policy OID is contained within the certificates it issues.

7.1.7 Usage of policy constraints extension

The CA must populate and mark as critical the policyConstraints extension.

7.1.8 Policy qualifiers syntax and semantics

The CA must populate the policyQualifiers extension with the URI of its CP. If the CA populates the userNotice extension, such text shall be limited to the text described in section 2.1.1.

7.1.9 Processing semantics for the critical Certificate Policy extension

Critical extensions shall be interpreted as defined in PKIX.

7.2 CRL Profile

7.2.1 Version number

The CA must issue X.509 version two (2) CRLs in accordance with the PKIX Certificate and CRL Profile.

Top of page

7.2.2 CRL and CRL entry extensions

All Entity PKI software must correctly process all CRL extensions identified in the PKIX Certificate and CRL profile. The CPS must define the use of any extensions supported by the CA, its LRAs and End Entities.

8. Specification Administration

8.1 Specification Change Procedures

8.1.1 Items that can change without notification

None.

8.1.2 Changes with notification

Prior to making any changes to this Certificate Policy, the CCRA PMA will notify the CCF and all CAs that are directly cross-certified with the CCRA CA.

8.1.2.1 List of items

All items in this Certificate Policy are subject to the notification requirement.

8.1.2.2 Notification mechanism

The CCRA PMA will notify, in writing, all CAs that are directly cross-certified with the CCRA CA of any proposed changes to this Certificate Policy. The notification must contain a statement of proposed changes, the final date for receipt of comments, and the proposed effective date of change. The CCRA PMA may request CAs to notify their Subscribers of the proposed changes. The CCRA PMA will also post a notice of the proposal on the CCRA PMA World Wide Web site.

8.1.2.3 Comment period

The comment period will be 30 days unless otherwise specified. The comment period will be defined in the notification.

8.1.2.4 Mechanism to handle comments

Written and signed comments on proposed changes must be directed to the CCRA PMA. Decisions with respect to the proposed changes are at the discretion of the CCRA PMA.

8.1.2.5 Period for final change notice

The CCRA PMA will determine the period for final change notice.

8.1.2.6 Items whose change requires a new policy

If a policy change is determined by the CCRA PMA to warrant the issuance of a new policy, the CCRA PMA may assign a new Object Identifier (OID) for the modified policy.

8.2 Publication and notification procedures

An electronic copy of this document, digitally signed by an authorised representative of the CA, is to be made available:

• at the CCRA PMA World Wide Web site, https://reg-pki-ext.ccra-adrc.gc.ca/pki/welcome-e.html
• via an e-mail request to pkiadminicp@ccra-adrc.gc.ca.

8.3 CPS approval procedures

The CA's accreditation must be in accordance with procedures specified by the CCRA PMA. Where a CPS contains information relevant to the security of the CA, all or part of the CPS need not be made publicly available.