CERTIFICATION POLICY QUEBEC CERTIFICATION CENTRE. 2015 Notarius Inc.

CERTIFICATION POLICY QUEBEC CERTIFICATION CENTRE 2015 Notarius Inc. Document Version: 4.5 OID: 2.16.124.113550 Effective Date: July 17, 2015

TABLE OF CONTENTS 1. GENERAL PROVISIONS...8 1.1 PURPOSE...8 1.2 SCOPE...8 1.3 OBJECT IDENTIFIERS (OID)...8 1.4 INTERPRETATION...8 1.5 COMPLIANCE WITH RFC 3647...8 1.6 PKI PARTICIPANTS...8 1.6.1 Certification Authority (CA)... 8 1.6.2 Certification and Directory Service Provider (C/DSP)... 9 1.6.3 Local Registration Authority (LRA)... 9 1.6.4 Identity Verification Agent (IVA)... 10 1.6.5 Guarantor... 10 1.6.6 Subscriber... 10 1.6.7 Other Participants... 11 1.7 USE OF KEYS AND CERTIFICATES... 11 1.7.1 Authorized Use of Keys and Certificates... 11 1.7.2 Limitations of Use... 12 1.7.3 Authorized Subscribers... 12 1.7.4 Available Certificates... 12 1.7.5 Certificate Trust Levels... 12 1.8 POLICY ADMINISTRATION... 13 1.8.1 Organization Administering the Policy... 13 1.8.2 Contact Information of the Policy Administrator... 13 1.8.3 Policy Approval Procedure... 13 1.9 ACRONYMS AND DEFINITIONS... 13 1.9.1 Acronyms... 13 1.9.2 Definitions... 13 2. PUBLICATION AND DISSEMINATION OF INFORMATION... 13 2.1 PUBLICATION SERVICES... 13 2.1.1 Publication of the Policy... 13 2.1.2 Publication the CA Certificate... 13 2.1.3 Publication of the CRL... 13 2.2 PUBLISHED INFORMATION... 14 2.3 TIME AND FREQUENCY OF PUBLICATION... 14 2.4 ACCESS CONTROLS ON PUBLISHED INFORMATION... 14 3. IDENTITY VERIFICATION... 14 Public page 2 of 37

3.1 CERTIFICATE FORMAT AND CONTENT... 14 3.1.1 Certificate Format... 14 3.1.2 Certificate Content... 14 3.1.3 Uniqueness of Names... 15 3.1.4 Anonymity or Use of a Pseudonym... 15 3.1.5 Rules for Interpreting Various Name Forms... 15 3.2 IDENTITY VERIFICATION... 15 3.2.1 Appointment and Obligations of an IVA... 15 3.2.2 Obligations of the Guarantor... 16 3.2.3 Identity Verification for a First-Time Application... 16 3.2.4 Identity Verification at Delivery of Activation Codes... 17 3.2.5 Identification Verification Throughout a Certificate s Life Cycle... 17 3.2.6 Identity Verification for a Renewal... 17 3.2.7 Identity Verification for a Reissue... 18 3.2.8 Identity Verification for Changes to a Certificate... 18 4. KEY AND CERTIFICATE MANAGEMENT... 18 4.1 APPLICATION FOR THE ISSUE OF KEYS AND CERTIFICATES... 18 4.1.1 Authorized Persons... 18 4.1.2 Application Procedure... 18 4.1.3 Processing an Application... 18 4.1.4 Processing Period for an Application... 18 4.1.5 Acceptance or Rejection of an Application... 19 4.1.6 Notification of Issue... 19 4.1.7 Acceptance of Certificates... 19 4.1.8 Using Keys and Certificates... 19 4.2 REISSUE REQUEST (NEW APPLICATION)... 19 4.2.1 Authorized Persons... 19 4.2.2 Procedure for a Reissue Request... 19 4.2.3 Processing a Reissue Request... 19 4.2.4 Processing Period... 19 4.3 RENEWAL REQUEST... 19 4.3.1 Authorized Persons... 20 4.3.2 Procedure for a Renewal Request... 20 4.3.3 Processing a Renewal Request... 20 4.3.4 Processing Period... 20 4.3.5 Renewal Notice... 20 4.4 RECOVERY OF A CERTIFICATE... 20 Public page 3 of 37

4.4.1 Authorized Persons... 20 4.4.2 Recovery Procedure... 20 4.4.3 Processing a Recovery Request... 20 4.4.4 Processing Period... 21 4.5 REQUEST FOR A MODIFICATION TO A CERTIFICATE... 21 4.5.1 Authorized Persons... 21 4.5.2 Circumstances for a Modification... 21 4.5.3 Processing a Modification Request... 21 4.5.4 Processing Period for a Modification Request... 21 4.6 CERTIFICATE REVOCATION... 21 4.6.1 Authorized Persons... 21 4.6.2 Processing a Revocation Request... 22 4.6.3 Processing Period for a Revocation Request... 22 4.6.4 Verification Requirements for Business Partners... 22 4.6.5 Frequency of Publication of the CRL... 22 4.6.6 Certificate Status Service... 22 4.7 CERTIFICATE SUSPENSION... 22 5. PHYSICAL AND ADMINISTRATIVE SECURITY CONTROLS... 22 5.1 PHYSICAL SECURITY CONTROLS... 22 5.1.1 Site Location... 22 5.1.2 Physical Access... 22 5.1.3 Power and Climate Control... 22 5.1.4 Vulnerability to Water Damage... 23 5.1.5 Fire Prevention and Protection... 23 5.1.6 Media Storage and Protection... 23 5.1.7 Disposal of Media... 23 5.1.8 Off-Site Backup Copies... 23 5.1.9 Compromise and Disaster Recovery... 23 5.1.10 Physical Security Controls for the IVA or guarantor... 23 5.1.11 Physical Security Controls for the Subscriber... 23 5.2 ADMINISTRATIVE AND OPERATIONAL SECURITY CONTROLS... 23 5.2.1 Trusted Roles... 23 5.2.2 Separation of Duties... 24 5.2.3 Security Controls Relating to Personnel... 24 5.2.4 Initial Training... 24 5.2.5 Continuing Training... 24 5.2.6 Changes in Personnel... 24 Public page 4 of 37

5.2.7 Sanctions... 24 5.2.8 Documentation... 24 5.2.9 Contractual Personnel... 24 5.3 AUDIT LOGGING PROCEDURES... 24 5.3.1 Type of Events Recorded... 24 5.3.2 Frequency for Auditing Logs... 25 5.3.3 Archival of Audit Logs... 25 5.3.4 Security Controls for Audit Logs... 25 5.3.5 Vulnerability Assessment... 25 5.4 DATA STORAGE AND ARCHIVAL... 25 5.4.1 Types of Data Stored and Archived... 25 5.4.2 Retention Period of Archives... 25 5.4.3 Protection of Archives... 25 5.4.4 Requirements for Time Stamping Records... 25 5.4.5 Archive Collection System... 25 5.4.6 Archive Recovery and Verification Procedure... 25 5.5 COMPROMISE AND DISASTER RECOVERY... 26 5.5.1 Compromise and Disaster Recovery Procedure... 26 5.5.2 Business Continuity Plan... 26 5.6 QCC TERMINATION... 26 5.6.1 Termination of CA Activities... 26 5.6.2 Termination of C/DSP Activities... 26 5.6.3 Termination of LRA Activities... 26 5.6.4 Termination of IVA Activities... 26 6. TECHNICAL SECURITY CONTROLS... 26 6.1 KEY PAIR GENERATION AND DELIVERY... 26 6.1.1 Key Pair Generation... 26 6.1.2 Delivery of Signature Keys... 26 6.1.3 Delivery of Private Keys... 26 6.1.4 Delivery of the CA Public Key... 27 6.1.5 Generating Subscribers Certificates... 27 6.1.6 Certificate Length and Validity Period... 27 6.2 PRIVATE KEY PROTECTION AND CRYPTOGRAPHIC MODULE CONTROLS... 27 6.2.1 Cryptographic Module Security Standards... 27 6.2.2 Protecting the PKI s Private Keys... 27 6.2.3 Protecting Subscribers Private Keys... 27 6.3 OTHER ASPECTS OF KEY AND CERTIFICATES MANAGEMENT... 28 Public page 5 of 37

6.3.1 Archiving Public Keys... 28 6.3.2 Public and Private Key Usage Period... 28 6.4 ACTIVATION DATA... 28 6.5 PKI SECURITY CONTROLS... 28 6.6 CONTROL MEASURES... 28 6.6.1 Cryptographic Module Engineering... 28 6.6.2 Evolution and Management of PKI Components... 28 6.6.3 Security... 29 6.7 TIME STAMPING... 29 7. CERTIFICATE AND CRL PROFILES... 29 7.1 CERTIFICATE CONTENT AND FORMAT... 29 7.1.1 CA Certificate Fields... 29 7.1.2 Subscriber Certificate Fields... 29 7.2 CRL PROFILE... 30 8. COMPLIANCE AUDITS... 30 8.1 FREQUENCY AND CIRCUMSTANCES FOR AN AUDIT... 30 8.2 AUDITOR QUALIFICATIONS... 30 8.3 EXTERNAL AUDITORS... 30 8.4 TOPICS COVERED IN AN AUDIT... 30 8.5 ACTIONS TAKEN AS A RESULT OF A DEFICIENCY... 30 9. LEGAL PROVISIONS... 30 9.1 FEES... 30 9.1.1 Subscription Fees... 30 9.1.2 Access Fees to the CRL and Certificate Status... 30 9.1.3 Fees for Identity Verification... 30 9.1.4 Other Services... 31 9.2 CONFIDENTIALITY OF INFORMATION... 31 9.2.1 Scope... 31 9.2.2 Security of Confidential Data... 31 9.3 PRIVACY OF PERSONAL INFORMATION... 31 9.4 INTELLECTUAL PROPERTY... 31 9.5 FINANCIAL RESPONSIBILITY... 32 9.6 REPRESENTATIONS AND WARRANTIES... 32 9.6.1 Regarding Certificate Information... 32 9.6.2 Regarding Directory Information... 32 9.7 LIMITATIONS OF LIABILITY... 32 9.8 INDEMNITIES... 33 Public page 6 of 37

9.9 INSURANCE COVERAGE... 33 9.10 APPROVAL PROCEDURES... 33 9.10.1 Approval of the Policy... 33 9.10.2 Approval of the Declaration of Certification Practices... 33 9.10.3 Validity... 33 9.10.4 Applicability in Cases Invalidity... 33 9.11 DISPUTE RESOLUTION PROCEDURES... 33 9.11.1 Complaints... 33 9.11.2 Litigation... 33 9.11.3 Governing Law... 33 9.12 INTERPRETATION... 33 9.12.1 Compliance with Applicable Laws... 33 9.12.2 Validity of Provisions... 33 9.13 EFFECTIVE DATE... 34 APPENDIX A ACRONYMS... 35 APPENDIX B - DEFINITIONS... 36 Public page 7 of 37

Introduction The Quebec Certification Centre 1 (QCC) is a public key infrastructure (PKI) established in 1998. The QCC issues keys and certificates to authorized subscribers enabling them to digitally sign and encrypt electronic documents. With digital signatures, subscribers are able to ensure the authorship and integrity of their electronic documents whereas with the encryption feature, they can maintain the confidentiality of the information contained therein. The QCC is also an external certification authority recognized by the Government of Quebec to issue keys and certificates to clients of the Quebec Land Registry. This document also aims to meet the needs of this clientele. 1. General Provisions 1.1 Purpose The Certification Policy, hereafter referred to as the "Policy", enacts the rules applicable to the certification services provided by the Quebec Certification Centre (QCC). This document applies, among others, to the creation, issue, management and use of digital certificates, to the requirements related to identity authentication of subscribers and stakeholders involved, as well as to the management of the service and infrastructure. In order to provide these services, the certification and directories services provider (C/DSP) describes in the Declaration of Certification Practices, hereafter called the "Declaration, the processes followed to provide the service and meet the requirements of the Policy. 1.2 Scope This Policy applies to all individuals who subscribe to QCC certification services. 1.3 Object Identifiers (OID) All certificates issued by the PKI must be identified by an object identifier (OID). The OID is a number that appears within the certificate and that links the certificate to the trust level assigned to it in accordance with the Policy. Therefore, the OID allows a third-party user, whose actions rely on a certificate, to ensure that the certificate meets an acceptable trust level for the purpose they intend to use it. 1.4 Interpretation The Policy constitutes a policy statement within the meaning of Article 52 of the Act to Establish a Legal Framework for Information Technology (R.S.Q., chapter C1-1). 1.5 Compliance with RFC 3647 The Policy is based on RFC 3647's Internet Engineering Task Force (IETF) Public Key Infrastructure X.509 (IETF PKIX) Certificate Policy and Certification Practices Framework which is the de facto global standard for the development of a certification policy. 1.6 PKI Participants 1.6.1 Certification Authority (CA) The Certification Authority (CA) is Notarius Technologies et systèmes d information notariale Inc. as represented by its Board of Directors. The CA may delegate its duties to a physical person it designates. The CA is responsible for certificates signed in its name as well as for the public key infrastructure 1 Official brand name Public page 8 of 37

(PKI) in its entirety, which bears the name Quebec Certification Centre (QCC). The CA is also responsible for: Adopting the Policy, as well as making any modifications to it. Selecting the C/DSP. Approving agreements concluded by the C/DSP regarding the services provided. Negotiating mutual recognition agreements with other certification authorities or certification and directory service providers. Designating identity verification agents (IVA). Publishing the Certificate Revocation List (CRL). Publishing the Authority Revocation List (ARL). 1.6.2 Certification and Directory Service Provider (C/DSP) The CA retains the C/DSP to administer certification services for the issue and management of certificates. The C/DSP may also act as a Local Registration Authority (LRA). The C/DSP is responsible for: Developing a Declaration of Certification Practices in accordance with this Policy s requirements. Heading all administrative and technological aspects associated with issuing certificates as well as subsequent operations related to their life cycle. It also heads directory services enabling the validation of a certificate in accordance with CA s requirements. Ensuring that the necessary validations have been made to confirm the information embedded in certificates. Collecting and recording information pertaining to subscribers. Ensuring that the CA publishes the Certificate Revocation List (CRL), the Authority Revocation List (ARL), and subscribers public certificates. Ensuring that CA s private key is used only to sign subscriber certificates, the CRL, and the ARL. Implement the necessary means, in accordance with best practices, to ensure the safety of directory services. Ensuring the protection of lists containing the numbers of cancelled certificates as well as the information associated with them. Ensuring that support is available to subscribers. C/DSP duties are entrusted to Solutions Notarius Inc. 1.6.3 Local Registration Authority (LRA) A Local Registration Authority (LRA) is a recognized association of professionals (RAP) or a legal entity. An LRA must have a written agreement with the CA or C/DSP except in such cases where the LRA is the C/DSP. The following duties are delegated to an LRA: Nominating individuals to act as an IVA on its behalf. Authorizing individuals or legal entities who may act as guarantors on its behalf. Public page 9 of 37

Issuing and managing, in whole or in part, certificates in accordance with the Policy. Confirming that the information embedded within certificates has been verified in accordance with the Policy. When applicable, confirming the professional status. Collecting and recording information relating to subscribers. 1.6.4 Identity Verification Agent (IVA) An IVA is a physical person working for an LRA and is responsible for verifying and confirming the identity and/or professional status of the subscriber for whom the certificate is requested. More specifically, an IVA s responsibilities are: Verify the applicant s identity in accordance with the Policy and confirm it to the C/DSP using the submitted identity documents. In case on doubt on their validity or authenticity, the documents must be rejected. Obtain a written confirmation of the identity verification if it was performed by a guarantor. Securely transmit to the C/DSP the applicant s information required to issue and manage keys and certificates. Confirm the applicant s professional status, when applicable, in order to authorize the issue of keys and certificates. Meet the operational requirements of the C/DSP. Respect and protect the confidentiality of the information collected, and that they handle in the performance of their duties. Protect their equipment against any attack on their security and integrity. To quickly inform the C/DSP of any changes of employer or professional status. 1.6.5 Guarantor The guarantor is an individual authorized by the C/DSP and LRA to verify the identity of the applicant. The guarantor must confirm that they performed this verification with the LRA or C/DSP according to the procedures defined by the C/DSP. 1.6.6 Subscriber The subscriber uses their certificates to sign, authenticate their identity and/or encrypt as needed or according to the features available. The subscriber s responsibilities are to: Fulfill the obligations related to their subscription as required by the C/DSP. Provide the required information, identification and documents in accordance with the Policy. Use their certificates only for authorized purposes. Protect the confidentiality of their activation data, authentication data, as well as their private key, its medium, and its password. Ensure that they are the only person to use their certificates. Similarly, when certificates are assigned to a group, a device, or an application, the subscriber must ensure that these are used only by authorized persons and systems. Use their computer equipment in a secure manner, more specifically by closing each digital signature session or work session prior to leaving their workstation. Public page 10 of 37

Notify the C/DSP as soon as possible should they suspect that the confidentiality of their keys and certificates, or password, has been compromised. Notify the C/DSP as soon as possible of any changes made to their email address or contact information. Not use their certificates when they have been revoked or are expired. 1.6.7 Other Participants 1.6.7.1 Business Partner The business partner is a legal entity wanting to electronically transact with certificate subscribers. They must have authorization and have concluded a prior agreement to this effect with the CA. The business partner s responsibilities are to: Align its business processes to the use of keys and certificates issued by the PKI. Conform to both functional and technical specifications required by the C/DSP. Decide who within its organization will hold keys and certificates issued by the PKI. Manage accesses and permissions to its computer applications. Implement the necessary updates as the PKI evolves. Notify subscribers of authorized uses within its applications. Ensure that the subscriber has the necessary means to comply with the obligations stemming from the Policy, including, among others, the obligation to maintain the confidentiality of their private keys. Notify the C/DSP of any event that may require an intervention regarding their keys and certificates, more specifically, their revocation. The C/DSP may require that the business partner submit to an audit or that they provide an audit report on topics that it specifies. 1.6.7.2 Third-Party User A third-party user is an individual who acts on the basis of a certificate issued by the PKI. They may or may not themselves hold keys and certificates issued by the PKI. They who want to act on the basis of a certificate must verify that the certificate: Is issued by the QCC. Meets the required trust level. Has a validity period that is not expired. Is not revoked. 1.7 Use of Keys and Certificates 1.7.1 Authorized Use of Keys and Certificates Keys and certificates issued by the PKI may only be served for the purposes as authorized by the Policy. Certificates are used to: Confirm an individual s identity. Authenticate an individual s identity in order to access information assets. Digitally sign electronic documents to ensure their integrity and non-repudiation. Public page 11 of 37

Encrypt a document to ensure its confidentiality. Entries appearing in the PKI s directories are used by subscribers or third-party users only to access a subscriber s public encryption certificate and to access the CRL and ARL. 1.7.2 Limitations of Use The policy places no limit on the value of a transaction under which the keys and certificates can be used. However, the CA and the C/DSP may restrict the use of keys and certificates insofar as the specific subscribers are explicitly informed of this. The subscription agreement may limit how the subscriber uses their keys and certificates. 1.7.3 Authorized Subscribers An authorized subscriber of keys and certificates is: A member of an RAP that has concluded a prior agreement with the C/DSP. An individual acting on behalf of a legal entity (employee, agent, etc.) wishing to use keys and certificates for professional purposes and on behalf of said legal entity. An individual who desires to transact with the Quebec Land Registry. An individual who desires a certificate for his own needs and meets the requirements of the C/DSP. A subscriber can themselves hold keys and certificates assigned to a group, a device, or an application. However, this does not relieve the subscriber of any liability towards the third-party user(s). 1.7.4 Available Certificates Two types of certificates are available: Professional digital signature: the subscriber must be a member of an RAP. Corporate digital signature: the subscriber is an employee or agent of a legal entity or company. Personal digital signature: the subscriber is an individual 1.7.5 Certificate Trust Levels Each certificate issued by the PKI must indicate a trust level. The Policy defines the rules applicable to each trust level offered to the subscriber. The trust level is indicated by the object identifier (OID). The following lists the OID used for each available trust level: Trust Level Certificate Type Object Identifier (OID) TEST Signature Encryption 2.16.124.113550.1.1.0 and 1.2.840.113583.1.2.2 2 2.16.124.113550.1.1.9 and 1.2.840.113583.1.2.2 MEDIUM Signature 2.16.124.113550.1.1.2 Encryption 2.16.124.113550.1.1.5 2 OID defined by Adobe which Indicates that the given certificate has been issued for testing purposed only, and displays a warning to indicate that it should not be trusted or relied upon. Public page 12 of 37

MEDIUM-HIGH HIGH Signature 2.16.124.113550.1.1.3 Encryption 2.16.124.113550.1.1.6 Signature 2.16.124.113550.1.1.7 Encryption 2.16.124.113550.1.1.8 1.8 Policy Administration 1.8.1 Organization Administering the Policy The Policy is the responsibility of Notarius Technologies et systèmes d information notariale Inc. 1.8.2 Contact Information of the Policy Administrator Contact information for the person or department responsible for the development of the Policy is the following: Notarius Technologies et systèmes d information notariales Inc. Attention: Management 465 McGill, suite 300 Montreal, Quebec H2Y 2H1 Phone: 514-879-1577 or 1-888-588-0011 Email: legal@notarius.com 1.8.3 Policy Approval Procedure The CA approves amendments to the Policy in accordance with the rules of its internal operations. 1.9 Acronyms and Definitions 1.9.1 Acronyms Appendix A describes the acronyms used in the Policy. 1.9.2 Definitions Appendix B describes the terms and their definitions most used in the Policy. 2. Publication and Dissemination of Information 2.1 Publication Services The CA is responsible for the publication of the Certificates Revocation List (CRL) and the Authority Revocation List (ARL). This duty is delegated by the CA to the C/DSP who will ensure that the CRL and ARL are published. The directories are accessible online at all times except during maintenance or in the case of an act of God that would necessitate the deployment of the Compromise and Disaster Recovery Plan for certificate subscribers, third-party users and any other member of the PKI. Although the directory is accessible at all times, fees may be required for high-volume transactions from the same entity. For this purpose, an agreement must be made with the C/DSP. 2.1.1 Publication of the Policy The Policy is published on the C/DSP s website. 2.1.2 Publication the CA Certificate The C/DSP must publish the CA s certificate «AC1=CENTRE DE CERTIFICATION DU QUEBEC». 2.1.3 Publication of the CRL The C/DSP must publish the distribution points for the CRL. CRL addresses must be identified within subscribers certificates. Public page 13 of 37

2.2 Published Information Information that must be published in the CRL and ARL by the CA «AC1=CENTRE DE CERTIFICATION DU QUEBEC» are: The CA distinctive name. The serial number of revoked certificates. The date and time of the revocation. The reason code identifying the revocation. The date and time of the CRL s last publication. The date and time of the CRL s next publication. The CRL s number. The key and certificate management application s integrity seal. The CA s signature. 2.3 Time and Frequency of Publication The CA s certificate must be available at all times. The CRL must be updated and published at the minimum every two (2) hours. The CRL s validity must be a maximum of forty-eight (48) hours. The publication by the C/DSP of a certificate s status constitutes a notice to third-party users. In this view, third-party users must consider a certificate revoked from the moment this information is published. 2.4 Access Controls on Published Information Published CRL and ARL information must be available in a readable format to subscribers and third-party users. The C/DSP ensures that all necessary security controls are in place to protect and assure the integrity of CRL and ARL published information. 3. Identity Verification This section covers the applicable rules regarding the verification of a certificate subscriber's identity over the course of their keys and certificates life cycle. 3.1 Certificate Format and Content 3.1.1 Certificate Format Certificates are issued in a format that meets the specifications set out by the X.509 version 3standard. 3.1.2 Certificate Content A subscriber s certificates must be signed by the PKI and contain the following information: PKI s distinctive name. Object identifiers referring to the Policy. Certificate s version and serial number. Certificate s issue and expiration date. The subscriber s distinctive name. This name may, when applicable, be replaced by the name of the group, role, device, or application to which the subscriber has assigned a certificate. The subscriber s member number or administrative code. The group to which the subscriber belongs. Public page 14 of 37

A certificate may also contain the subscriber s address. 3.1.3 Uniqueness of Names The C/DSP must be sure to issue certificates that bear a distinctive and unique name in the Subject DN field, in accordance with the X.501 standard and with RFC 3280. The subscriber s distinctive name that appears on their certificates must contain the following: The subscriber s name. The subscriber s distinctive name may, when applicable, be replaced by that of a group, role, device, or application to which the subscriber has assigned the keys and certificates. For subscribers who are members in good standing of an RAP who has concluded a prior agreement with the C/DSP to issue certificates to their member: their member number. For subscribers who are not members of an RAP: an administrative code. The identification or acronym of the group to which the subscriber belongs. It is the C/DSP s responsibility to ensure that the distinctive name must be unique for all issued certificates. A distinctive name s uniqueness is the result of a combination of identification elements, such as the subscriber s first and last name, member number or administrative code and the group to which the subscriber belongs. 3.1.4 Anonymity or Use of a Pseudonym The C/DSP must not, under any circumstance, issue certificates using a pseudonym or an anonymous identifier to identify a subscriber. The term Test or any other reference of a similar nature may be used within the name or the administrative code for signing in test purposes only. Since these certificates are issued without authenticating the identity of the subscriber, they cannot reasonably be relied upon. 3.1.5 Rules for Interpreting Various Name Forms The name used by the subscriber is explicit and requires no special interpretation. 3.2 Identity Verification This step is to establish the identity of a future subscriber according to the procedure described in this section. Identity verification can also be used to establish the identity and existence of a legal entity, device, application or group as well as their relationship to the subscriber. 3.2.1 Appointment and Obligations of an IVA 3.2.1.1 Appointing an IVA The CA appoints as IVAs those individuals designated by the LRA and who meet the conditions set by the C/DSP for this position. 3.2.1.2 Obligations of the IVA To act as IVA, the individual must follow the instructions provided by the C/DSP, sign an agreement to perform these duties, and subscribe to a digital signature. In the performance of their duties, the IVA must collect, store and handle information in accordance with the laws and requirements regarding confidentiality and privacy. Should the IVA doubt the validity or authenticity of the documents presented, they must then reject them. It is up to them to judge whether the documents provided by the applicant satisfy the conditions of sufficient evidence. The IVA must confirm the C/DSP the following: The identity of the individual applying for keys and certificates has been verified. Public page 15 of 37

Whether the applicant for keys and certificates is a member of an RAP or works for the legal entity that commissioned them, when applicable. The authorization to issue keys and certificates to the applicant. 3.2.2 Obligations of the Guarantor When an identity verification is performed by a guarantor, it is the guarantor s obligation to confirm having verified the identity of the applicant according to section 3.2.3 and declare it to the LRA or C/DSP. 3.2.3 Identity Verification for a First-Time Application 3.2.3.1 Verifying an Individual s Identity 3.2.3.1.1 Test Trust-Level Identity Verification No verification of identity is required for an individual wanting to obtain keys and certificates of a Test trust level. Such a request is made by sending a request to the C/DSP along with the individual s contact information. 3.2.3.1.2 Medium and Medium-High Trust-Level Identity Verification The individual wanting to obtain keys and certificates of a Medium or Medium-High trust level must: Make an application to the C/DSP. Have their identity verified by an authorized guarantor or IVA by presenting two identification documents issued by a recognized government authority, one of which includes a photo and a signature. Comply with all conditions and requirements of the C/DSP. Forward the necessary documents in support of the application to the authorized IVA. 3.2.3.1.3 High Trust-Level Identity Verification The individual wanting to obtain certificates of a High trust level must: Make an application to the C/DSP. Appear in person before an IVA authorized to review said application. Appear in person before an IVA to have their identity verified and present two documents issued by a recognized government authority, one of which includes a photo and signature. The IVA must approve the application via the C/DSP. Obtain and immediately activate their physical security device which contains their keys and certificates, and this, in the presence of the IVA. 3.2.3.2 Confirmation of Professional Status The RAP s IVA must confirm the professional status of the applicant and confirm it to the C/DSP. 3.2.3.3 Confirmation of Membership to a Legal Entity Confirmation of the employment relationship must be confirmed to the C/DSP by the IVA authorized by said legal entity. 3.2.3.4 Confirmation of a Device or Application Confirmation of the association between an applicant wishing to obtain keys and certificates for a corporate digital signature which will be assigned to a device or application, and the legal entity that owns said device or application, must be made by the IVA authorized by said legal entity, and then confirm it to the C/DSP. Public page 16 of 37

3.2.4 Identity Verification at Delivery of Activation Codes Activation codes must be delivered in the following manner: For certificates of Medium or Medium-High trust levels, by at minimum two of the following methods: i. Email. ii. iii. iv. Registered Mail or by a trusted courier service with a signature required upon receipt. Application that meets the C/DSP s requirements that allows for the transmission of activation codes in a secure manner. Bailiff who hand delivers the activation codes once the recipient s identity has been verified. v. Directly to the subscriber once their identity has been verified with their shared secret. vi. IVA who hand delivers the activation codes to the recipient after having verified their identity. For certificates assigned a Test trust level, the C/DSP is not bound to use the aforementioned methods to transmit activation codes and may use any method it deems appropriate. For certificates of a High trust level, activation codes must be delivered either by an application that meets the C/DSP s requirements for transmitting activation codes in a secure manner, or by an authorized IVA. 3.2.5 Identification Verification Throughout a Certificate s Life Cycle Throughout the life cycle of keys and certificates, the C/DSP may have to verify the identity of the subscriber should they require an operation be performed that will impact their certificates. To this end, the C/DSP can use one of the methods listed in this section. 3.2.5.1 Using the Private Signature Key If the confidentiality of the subscriber s signature key has not been compromised, they may use it to sign their application form and thus authenticate their identity to the C/DSP. 3.2.5.2 Shared Secret The C/DSP may resort to a shared secret to identify and authenticate the subscriber. The shared secret may have been previously communicated to the C/DSP in one of the following ways: After having been collected during the initial application process by the IVA who then transmitted it to the C/DSP in a secure manner to ensure its confidentiality. By the subscriber via sealed post. By the subscriber via signed and encrypted email. By the subscriber via an application that meets the C/DSP s requirements. For members of an RAP, the shared secret may come from information available within the RAP s registries. 3.2.5.3 Resorting to an IVA or Guarantor The C/DSP may request that the subscriber s identity, and when applicable, professional status, be verified by an authorized IVA or guarantor. 3.2.6 Identity Verification for a Renewal Verifying the subscriber s identity for a renewal must be performed by the C/DSP s application that will verify the digital signature created by the subscriber s private key, all in accordance with the PKI s Public page 17 of 37

technical specifications. 3.2.7 Identity Verification for a Reissue An individual requesting the reissue of their keys and certificates within twelve (12) months following their revocation, expiration, or cancellation, the C/DSP may verify the applicant s identity with their shared secret. However, the C/DSP must ensure that the information embedded within the certificates is still accurate. If the request for a reissue takes place after said date, identity verification must be performed as if for a first-time certificate issue, section 3.2.3. 3.2.8 Identity Verification for Changes to a Certificate When a subscriber requests that changes be made to the information embedded within their certificates, the C/DSP must verify unequivocally the accuracy of said information. To accomplish this, the C/DSP may resort to an IVA. If the information that needs to be changed pertains to the subscriber s email address or contact information, the request must be made in writing or via an application that meets the C/DSP s specifications. 4. Key and Certificate Management 4.1 Application for the Issue of Keys and Certificates 4.1.1 Authorized Persons A physical person may apply for keys and certificates for themselves, for a group of individuals, or for a device by subscribing to the service as described by the C/DSP. A legal entity may apply for keys and certificates for their employees, or for one of their devices or applications. In the latter case, it will assign a physical person to be responsible for said keys and certificates. All applications are subject to authorization by an IVA as provided by the Policy. 4.1.2 Application Procedure The individual authorized by the Policy wanting to obtain keys and certificates must: Make an application to the C/DSP and accept the terms of use. Have their identity verified as provided in section 3.2.3. Pay all related fees. Comply with all other obligations expressly brought to their attention by the C/DSP. 4.1.3 Processing an Application When an application for the issue of keys and certificates is received, the authorized IVA must the identity and been dully verified, and must then perform all necessary verifications and confirm to the C/DSP their authorization to issue keys and certificates to the applicant. The C/DSP will then forward the activation codes to the applicant as provided in the Policy. The C/DSP must be able to follow up on applications. The C/DSP must, as part of its responsibilities, collect and save relevant information pertaining to an application, as well as to all subsequent actions taken with regards to an application as provided for in section 5.4. 4.1.4 Processing Period for an Application An application is processed as soon as possible by the C/DSP and the IVA. For certificates of Medium or Medium-High trust levels, the applicant must generate their keys and certificates within fifteen (15) days from reception of their activation codes. If activation codes expire, the applicant can request that new ones be issued by authenticating himself Public page 18 of 37

to the C/DSP. For certificates of a High trust level, the subscriber must generate their keys and certificates and keep them on a cryptographic device as of reception of their activation codes. Failure to do so will result in the application being cancelled. 4.1.5 Acceptance or Rejection of an Application The affixing of the CA s signature to the subscriber s certificate signals the CA s complete and final approval for a first-time application. The C/DSP or IVA must reject an incomplete application. Depending on the type of certificate applied for or the level of trust attributed, they may insist that the applicant submit to a new identity verification or restart the application process. 4.1.6 Notification of Issue The C/DSP must publish encryption certificates in the directory that third-party users may consult online. By publishing a certificate in the directory, the C/DSP certifies that it has issued certificates to the subscriber and that the subscriber has accepted them. 4.1.7 Acceptance of Certificates The subscriber is presumed to have accepted the keys and certificates when they activate them by using a device compatible with the PKI. 4.1.8 Using Keys and Certificates By accepting the terms of use, the subscriber agrees to use their keys and certificates only in the performance of their duties. The subscriber may use their keys and certificates as their official electronic signature within the limitations of applicable law. They may use their keys and certificates to ensure the confidentiality, integrity, and security of electronic documents and to identify and authenticate themselves in order to access information assets or applications. Any other use is prohibited and is the responsibility of the subscriber. 4.2 Reissue Request (New Application) A reissue consists of issuing new keys and certificates to the subscriber whose previous certificates are revoked, expired, or cancelled. 4.2.1 Authorized Persons Only the subscriber may request that their keys and certificates be reissued. 4.2.2 Procedure for a Reissue Request When a subscriber requests that their certificates be reissued, they must do so according to the procedure described in section 4.1.2, and when applicable, in section 3.2.7. 4.2.3 Processing a Reissue Request The C/DSP must process the reissue request in the same manner as for a first-time application, except with regards to the identity verification which can be performed as is described in section 3.2.7. 4.2.4 Processing Period The processing period is the same as for a first-time application. 4.3 Renewal Request Renewing certificates consists of issuing new keys and certificates to a subscriber by using their current private key. Public page 19 of 37

4.3.1 Authorized Persons It is the subscriber who initiates the renewal process for their certificate. 4.3.2 Procedure for a Renewal Request The renewal is initiated automatically by the subscriber s client application that is compatible with the PKI, which, prior to the expiration date of the private signature or encryption key, may request online the renewal of the certificates so long as these are still valid. None of the information embedded within the certificates will change; only the serial number and validity period change. 4.3.3 Processing a Renewal Request For a certificate renewal, it is necessary to: Authenticate the identity of the subscriber and verify that they are in possession of a valid private signature key issued by the QCC. Generate the subscriber s keys, affix the CA s signature on the signature certificate, and transmit it to the subscriber. Generate, when applicable, an encryption certificate on which the CA s signature is affixed, transmit it to the subscriber, and publish the certificate in the directory that is available to users. 4.3.4 Processing Period The renewal request is automatic and is processed immediately upon reception. 4.3.5 Renewal Notice Generally, the subscriber is notified automatically by the client application that their certificates are renewed. 4.4 Recovery of a Certificate A recovery may be requested when it becomes impossible to access private keys, especially in cases where the password is lost or the keys have been destroyed. 4.4.1 Authorized Persons Individuals who may request a recovery of encryption keys are: The subscriber. The C/DSP in the case of technical difficulties. An IVA for one of his employees. A person authorized by ruling that was granted by a competent tribunal. 4.4.2 Recovery Procedure The person authorized to request a recovery must transmit said request by filling out the form provided for this purpose or via the application compatible with the PKI. 4.4.3 Processing a Recovery Request Upon reception of a certificate recovery request, the C/DSP must: Verify that the request comes from an authorized person as described in section 4.4.1. Generate activation codes and transmit them to the subscriber after having verified their identity as described in section 3.2.4, or transmit them to the person designated by court order. Upon reception of activation codes, the subscriber must complete the recovery process by entering their codes in the client application in order to communicate with the PKI. Public page 20 of 37

4.4.4 Processing Period The C/DSP must ensure that the activation period between the moment the activation codes are transmitted and the moment the certificates are recovered by the subscriber does not exceed the period of time specified in section 4.1.4. 4.5 Request for a Modification to a Certificate Modifying a certificate implies issuing a new certificate to the subscriber who is in possession of a valid certificate containing erroneous or inaccurate information. 4.5.1 Authorized Persons Modifications to a certificate may be requested by the following: The subscriber. The IVA of an LRE for one of its members or one of its employees, as is the case. The C/DSP. 4.5.2 Circumstances for a Modification A modification can be made in the following circumstances: To correct an error made when the certificate was generated. To change information embedded within a certificate. 4.5.3 Processing a Modification Request The C/DSP must collect and keep documents pertaining to the processing of a modification request as well as of any subsequent operation thereof. In processing a modification request, the C/DSP must: Verify the identity of the subscriber as described in section 3.2.4. Verify the accuracy of the information that is to be modified as described in section 3.2.8. Generate new keys and certificates embedded with the modified information. The subscriber must complete the modification process by communicating with the PKI using the client application. 4.5.4 Processing Period for a Modification Request For certificates of Medium or Medium-High trust level, the modification request is processed by the C/DSP as soon as possible. For certificates of High trust level, the modification request is processed immediately upon reception. 4.6 Certificate Revocation Revocation is rendering a subscriber s keys and certificates unusable. 4.6.1 Authorized Persons Any individual may transmit to the C/DSP information leading to the revocation of keys and certificates. An IVA from an LRA can revoke the keys and certificates of one of their members or employees, as is the case. Keys and certificates are revoked in the following circumstances: The subscriber requests it. The service s fees have not been paid. An IVA from an LRA requests it for one their members or employees, as is the case. The confidentiality of the subscriber s private key or password has been compromised or they Public page 21 of 37

suspect it has been. The subscriber does not respect the terms of use regarding their certificates. 4.6.2 Processing a Revocation Request The C/DSP must collect and keep documents pertaining to the processing of a revocation request. 4.6.3 Processing Period for a Revocation Request A revocation request is processed maximum the next business day following its reception by the C/DSP. 4.6.4 Verification Requirements for Business Partners It is up to business partners applications to verify the validity of a certificate by referring to all CRLs published by the CA. 4.6.5 Frequency of Publication of the CRL Please refer to Time and Frequency of Publication in section 2.1.3. 4.6.6 Certificate Status Service There is no service to verify the validity of certificates other than the publication of the CRL. 4.7 Certificate Suspension Certificate suspension is not an available service. 5. Physical and Administrative Security Controls 5.1 Physical Security Controls The Policy outlines the following: Security and control measures for physical access points. Protection against natural disasters, theft and break-ins. Safety measures against fire, public utilities failure (electricity, telecommunications), structural collapse, water damage. Disaster recovery. The Declaration describes in more detail the physical security measures and controls described in this section. 5.1.1 Site Location Sites where the PKI s computer systems are stored must be in buildings that are geographically located at a minimum of five kilometres away from each other. These buildings must comply with building codes that normally apply. To access the premises, security and controlled access zones must be crossed in order to prevent or detect unauthorized access to the systems. The security measures that are in place must be proportionate to the risks identified through the C/DSP S risk analysis. 5.1.2 Physical Access The PKI s facilities must be controlled and monitored to ensure that only authorized persons can access them. Removable media and paper documents containing sensitive information must be stored so that only authorized individuals can access them. 5.1.3 Power and Climate Control The C/DSP must ensure that power and climate control facilities are sufficient for the proper functioning of the PKI s computer system. Public page 22 of 37

Sites must be equipped with a primary electrical system as well as a backup system to ensure continuous and uninterrupted access to electricity. In addition, sites must be equipped with a primary and secondary ventilation or air conditioning system to control temperature and relative humidity. 5.1.4 Vulnerability to Water Damage Sites must be built or equipped to protect against water exposures. 5.1.5 Fire Prevention and Protection Sites must be built or equipped to protect against fire. These measures must meet applicable laws. 5.1.6 Media Storage and Protection The C/DSP must protect media containing critical data or all other sensitive information against any damage, deterioration, theft, and unauthorized access and use. 5.1.7 Disposal of Media The C/DSP must have a procedure in place for disposing media to protect against unauthorized use, access or divulging of sensitive information. 5.1.8 Off-Site Backup Copies The C/DSP must keep backup copies off site. Backup copies must enable the restoration of service following a system failure within an acceptable period of time. 5.1.9 Compromise and Disaster Recovery A compromise and disaster recovery plan must guarantee that services and information are maintained in the following events: Primary system failure. Failure of software essential to the delivery of PKI services following a disaster. Storage medium failure. Backup equipment and recovery procedures must be regularly tested to ensure their proper functioning. 5.1.10 Physical Security Controls for the IVA or guarantor The IVA or the guarantor must take all necessary precautions to protect confidential information that is collected in the course of authenticating the identity of a subscriber. When this information resides on their workstation, it must be protected via data encryption. The IVA must prevent any access to their workstations when they are not working on it. Similarly, it must prevent any access to their private signature key. 5.1.11 Physical Security Controls for the Subscriber The subscriber must take all necessary precautions to ensure the physical security and confidentiality of their private keys. To this end, the subscriber must not leave their workstation when their certificates are accessible or when they are in use by a device or application. The subscriber must also prevent any unauthorized access to their workstation and to the media containing their private key. 5.2 Administrative and Operational Security Controls 5.2.1 Trusted Roles To ensure that no one person acting alone can circumvent the security measures and thus undermine the integrity of the service provided, the C/DSP must distribute certain duties related to the management of operations (trusted roles) between several people. Public page 23 of 37

5.2.2 Separation of Duties Certain operational duties must be performed by two people to ensure a high trust level in the management of operations related to the PKI s services. The Declaration details this separation of duties. 5.2.3 Security Controls Relating to Personnel 5.2.3.1 Required Qualifications, Skills, and Abilities The C/DSP must employ enough people who possess the necessary knowledge, experience, and qualifications to ensure the provision of the PKI s services. 5.2.3.2 Background Check Procedure C/DSP employees should not hold a position that could cause a conflict of interest and undermine the impartiality of operations linked to the provision of PKI services. The C/DSP may not appoint to a trusted role a person who has been convicted of a serious crime or any other offense that would affect their ability to occupy a role of trust. A C/DSP employee may not perform duties related to the provision of PKI services until the necessary background checks are completed. Before appointing a person to a trusted role, the C/DSP must conduct a criminal background check of the candidate. 5.2.4 Initial Training C/DSP employees who hold a position related to the provision of PKI services must have received appropriate training to perform their duties. The C/DSP must verify that the professional qualifications of their personnel are commensurate with their assigned tasks and duties. 5.2.5 Continuing Training To ensure that their personnel maintain an adequate level of competency to perform their duties in a satisfactory manner, the C/DSP must provide training when there is a change in duties, a change to the PKI system, an upgrade to a procedure, or any other reason determined by the C\DSP. 5.2.6 Changes in Personnel The C/DSP must ensure that any change in personnel will affect neither the system s operational efficiency nor the system s security. 5.2.7 Sanctions The C/DSP must establish, maintain, and apply a disciplinary procedure for cases when an employee performs an unauthorized action. The disciplinary procedure may include measures up to termination and must take into account the frequency and severity of the unauthorized action. 5.2.8 Documentation The C/DSP must make available to personnel the Policy, the Declaration, administrative and technical procedures pertaining to the certificate management service, as well as all other documentation relevant for the performance of their duties. 5.2.9 Contractual Personnel The C/DSP s security controls must also apply to all contractual personnel. Otherwise, contractual personnel must be escorted and supervised by the C/DSP employees. 5.3 Audit Logging Procedures 5.3.1 Type of Events Recorded The C/DSP must enter in the audit logs 3 information regarding events related to the certificate management system s security. All logs, regardless of their medium, must contain the date, time, and identification of the event. The C/DSP must list in the Declaration the logs and event types it records. 3 Audit logs do not include management operations history (logs), which is instead recorded in the PKI system s database. Public page 24 of 37