Government of Canada Guidance on Using Electronic Signatures

1.1. Background

In keeping with the objectives of the Government of Canada’s (GC’s) Digital Government initiative, the GC continues to:

• streamline its internal and external business processes
• improve how it delivers services to Canadians

The GC can achieve these goals, in part, by replacing paper-based processes with electronic practices that are more modern, faster and easier to use.

The concept of conducting business electronically is nothing new. A number of jurisdictions, including the GC and Canada’s provinces and territories, have developed laws, policies and standards for electronic documents and electronic signatures (e-signatures) since the mid-1990s. These laws:

• rely on internationally recognized rules to create a more certain legal environment for electronic communications and electronic commerce
• recognize that electronic communications should not be denied legal effect simply because they are in electronic form

Whether a signature is paper-based or electronic, the fundamental purpose of the signature is the same. A signature links a person to a document (or transaction) and typically provides evidence of that person’s intent to approve or to be legally bound by its contents. The primary function of a signature is to provide evidence of the signatory’s:

• identity
• intent to sign
• agreement to be bound by the contents of the document

The requirement for a signature can be:

• imposed by an act of Parliament
• imposed by policy
• a customary practice

A signature can be that of a government official or a member of the public (an individual or a business representative).

In the context of the federal government, a signature may be required to:

• express consent, approval, agreement, acceptance or authorization of everyday business activities (for example, to approve a leave request or formally agree to the terms and conditions of a contract)
• emphasize the importance of a transaction or event, or to acknowledge that a transaction or event occurred, such as confirming that a contractor’s bid was received by a deadline
• provide source authentication and data integrity, such as verification that a public health-related notice originated from Health Canada and has not been altered
• certify the contents of a document (that is, a document complies with certain requirements, or a particular process was followed)
• affirm that information contained in a document is true or accurate
• support third-party attestation, such as for an electronic notary function
• support accountability, such as being able to trace individuals to their actions

In some cases, the ability to support e-signatures from more than one individual is required. This requirement can be met in several ways, including through the use of email or a workflow management system.

1.2. Purpose and scope

This document provides guidance on using e-signatures in support of the GC’s day-to-day business activities. It aims to clarify:

• what constitutes an e-signature
• what forms of e-signature are appropriate in the context of the business activity

This document is not intended to be:

• a substitute for legal advice (business owners should always consult with their legal counsel)
• a framework to protect sensitive information from unauthorized disclosure (this document does not address confidentiality requirements)

1.3. Intended audience

This guidance is for GC departments^{Footnote 1} that are exploring the use of e-signatures in support of their day-to-day business activities.

2.1. E-signature laws

Jurisdictions throughout the world have adopted laws that recognize the validity of electronic documents and e-signatures. Although frameworks and definitions vary by jurisdiction, their principles are largely the same. Appendix A lists a number of these sources and their associated definitions.

In Canada, Part 2 of the Personal Information Protection and Electronic Documents Act (PIPEDA) provides a regime that establishes electronic equivalents to paper-based documents and signatures at the federal level. Part 2 of PIPEDA defines an e-signature as “a signature that consists of one or more letters, characters, numbers or other symbols in digital form incorporated in, attached to or associated with an electronic document.” Essentially, an e-signature can be virtually any form of electronic representation that can be linked or attached to an electronic document or transaction, including:

• user authentication to an internal application to approve something, such as when a supervisor logs into an application to approve a leave request
• using a stylus on a tablet touchscreen to write a signature by hand and capture it in electronic form
• a typed name or signature block in an email
• user authentication to access a website, coupled with a mouse click on some form of acknowledgment button to capture intent
• a scanned hand-written signature on an electronic document
• a sound such as a recorded voice command (for example, a verbal confirmation in response to a question)

There are also some cases where Part 2 of PIPEDA requires the use of a particular class of e-signatures, referred to as a “secure electronic signature.” A secure e-signature is a form of e-signature that is based on asymmetric cryptography. Specific use cases where Part 2 of PIPEDA requires a secure e-signature are:

• documents used as evidence or proof (see PIPEDA Part 2, section 36)
• seals (see PIPEDA Part 2, section 39)
• original documents (see PIPEDA Part 2, section 42)
• statements made under oath (see PIPEDA Part 2, section 44)
• statements declaring truth (see PIPEDA Part 2, section 45)
• witnessed signatures (see PIPEDA Part 2, section 46)

Although Part 2 of PIPEDA set outs clauses for general application, many of the electronic equivalents it outlines are based on an “opt in” framework. Therefore, such provisions do not apply to departments and agencies unless they choose to opt in and list the federal law or provision that includes the signature (or other applicable requirement) to Schedule 2 or Schedule 3 of PIPEDA.^{Footnote 2}

Over the years, rather than choosing to opt in to PIPEDA, several departments and agencies have amended their own statutes to provide clarity regarding e-signatures and electronic documents more generally. For example, Employment and Social Development Canada has addressed this through its:

• Department of Employment and Social Development Act
• Electronic Documents and Electronic Information Regulations^{Footnote 3}

Related federal regulations (which were enacted before PIPEDA came into effect) are:

• Electronic Payments Regulations, issued pursuant to the Financial Administration Act’s (FAA’s) subsection 10(f)
• Payments and Settlements Requisitioning Regulations, issued pursuant to the FAA’s subsection 10(a) and section 33

Both of these regulations set out a requirement to support digital signatures in association with online electronic transfers. The Secure Electronic Signature Regulations^{Footnote 4} also uses the term “digital signature” in its definition of a secure e-signature. Therefore, from a technical perspective, a digital signature and a secure e-signature are essentially the same since both:

• are a form of e-signature based on asymmetric cryptography
• rely on public key infrastructure (PKI) to manage the associated private signing keys and public verification certificates

However, the Secure Electronic Signature Regulations (SES Regulations) go further in several respects, including:

• section 2 of the SES Regulations prescribes a specific asymmetric algorithm to support digital signatures
• section 4 of the SES Regulations specifies that the issuing Certification Authority (CA) must be recognized by the Treasury Board of Canada Secretariat by verifying that the CA has “the capacity to issue digital signature certificates in a secure and reliable manner.”^{Footnote 5}
• section 5 of the SES Regulations includes a presumption that, in the absence of evidence to the contrary, the electronic data has been signed by the person who is identified in the digital signature certificate or who can be identified through that certificate.

2.2. Determining when an e-signature should be used

As mentioned, there are cases where a law (or policy) specifies:

• a requirement for an e-signature
• the type of e-signature required

There are also cases where:

• the legal requirement is only implied
• the need for a signature has been established for some other non-legislative reason
• in either case, the type of e-signature may be unspecified or unclear

Figure 1 outlines the steps to determine whether an e-signature is required and, if so, what type of e-signature is required. While Figure 1 emphasizes the importance of obtaining legal advice throughout the process, note that the various steps illustrated in Figure 1 will need to be performed in collaboration with other key personnel where appropriate as noted in Annex D. In addition, this document offers guidance on assessing assurance levels (see subsection 2.3), which can be used:

• in the absence of specified legal or policy requirements
• when requirements for implementing an e-signature are not specified or are unclear

Figure 1 - Text version

Figure 1 outlines the steps to determine whether an e-signature is required and, if so, what type of e-signature is required. The figure is a process flowchart that represents the following steps:

• Step 1: identify the business requirement
• Step 2: informed by legal counsel, determine if a requirement for a signature is identified in existing legislation or policy and if so proceed to Step 3; if not proceed to Step 4
• Step 3: informed by legal counsel, determine if the type of electronic signature is also identified and if so proceed to Step 6; if not proceed to Step 5.
• Step 4: informed by legal counsel and this guidance document, determine if there is an implicit requirement or other legitimate business reason for a signature and if so proceed to step 5; if not then there is no requirement to implement an electronic signature for the identified business requirement
• Step 5: determine the type of electronic signature required informed by legal counsel, assurance level assessment and this guidance document and proceed to Step 6
• Step 6: implement the identified electronic signature solution followed by reassessment over time

2.3. Assessing assurance levels

The Guideline on Defining Authentication Requirements outlines a methodology to determine the minimum assurance level^{Footnote 6} needed to achieve program objectives, deliver a service or properly execute a transaction.

This methodology can be applied in the context of e-signatures.^{Footnote 7} An assessment of assurance levels should consider the impact of threats, such as:

• impersonation (the signer is not who they claim to be)
• repudiation (the signer attempts to deny that they originated an e-signature)
• loss of data integrity (the electronic data has been altered since it was signed)
• exceeding authority (the signer is not authorized to sign the associated electronic data)

Once the assessment is complete and the assurance level requirement has been determined, procedural and technical controls can be selected and implemented. Implementation guidance based on each assurance level is provided in Section 3: Guidance on implementing e-signatures.

3.1. Considerations for user authentication

As noted previously, associating individuals with a signed electronic record is one of the fundamental requirements for an e-signature, and therefore the assurance level of the authentication process and the e-signature are closely coupled. Current GC guidance on authenticating users includes the following:

• Standard on Identity and Credential Assurance, which establishes the four assurance levels associated with identity assurance and credential assurance
• Guideline on Defining Authentication Requirements, which describes a methodology for determining the minimum assurance level needed for user authentication (discussed in subsection 2.3 of this document)
• Guideline on Identity Assurance, which specifies the minimum requirements to establish the identity of an individual for a given level of assurance
• User Authentication Guidance for Information Technology Systems, which provides guidance on selecting security controls for user authentication.

Essentially, the assurance level required for an e-signature dictates the assurance level required for user authentication, which in turn dictates the assurance level required for identity assurance and credential assurance. The guidance documents listed above should be used to determine specific requirements at each assurance level, based on the following recommendations:

• at Assurance Level 1:
  • the minimum identity assurance requirements set out in the Guideline on Identity Assurance for Assurance Level 1 must be met
  • any of the token types identified in ITSP.030.31: User Authentication Guidance for Information Technology Systems for Assurance Level 1 or higher can be used for user authentication
• at Assurance Level 2:
  • the minimum identity assurance requirements set out in the Guideline on Identity Assurance for Assurance Level 2 must be met
  • any of the token types identified in ITSP.030.31 for Assurance Level 2 or higher can be used for authentication
• at Assurance Level 3:
  • the minimum identity assurance requirements set out in the Guideline on Identity Assurance for Assurance Level 3 must be met
  • two-factor authentication is required (refer to Appendix B for additional information)
• at Assurance Level 4:
  • the minimum identity assurance requirements set out in the Guideline on Identity Assurance for Assurance Level 4 must be met
  • a multi-factor cryptographic hardware device such as a smart card must be used

Additional information on authentication factors and token types associated with user authentication is provided in Appendix B.

3.2. Determining the method to be used to implement e-signatures

Section 2 discussed the various forms of e-signatures. This section sets out the type of e-signature recommended at each assurance level.

Recommendations for e-signatures at each assurance level are as follows:

• at Assurance Level 1, any type of e-signature is acceptable
• at Assurance Level 2, any type of e-signature can be used in conjunction with the authentication requirements for Assurance Level 2 or higher
• at Assurance Level 3, a non-cryptographic e-signature may be used in conjunction with acceptable two-factor authentication, or a digital signature or secure e-signature may be preferred in some circumstances, depending on the target environment and the security controls that are in place
• at Assurance Level 4, a secure e-signature is required in conjunction with a multi-factor cryptographic hardware device

From a technical perspective, an e-signature at a higher assurance level can also be used at lower assurance levels (for example, an Assurance Level 3 e-signature can also be used to support Assurance Level 1 and 2 e-signature requirements). However, other factors such as cost, usability and operational requirements must also be taken into consideration to determine the most sensible approach.

3.3. Supporting information

As discussed in subsection 2.1, an e-signature is any electronic representation where:

• the identity of the individual signing the data can be associated with the electronic data being signed
• the intent of the individual in signing the electronic record is conveyed in some way
• the reason for signing the electronic data is conveyed in some way

There may be requirements to include other supporting information, such as the time that the electronic data was signed.

Supporting information recommended at each assurance level is as follows:

• at Assurance Level 1, supporting information should include:
  • the e-signature
  • the signed electronic data
  Note that this information may be implicitly identified, depending on the type of electronic transaction.

• at Assurance Level 2, supporting information should include:
  • the authentication method
  • the e-signature
  • the signed electronic data
  • a time-stamp based on standard local system time that indicates the time that the electronic data was signed
  Note that some of this information may be implicitly identified, depending on the type of electronic transaction

• at Assurance Level 3, the supporting information will depend on the type of e-signature:
  • for a non-cryptographically based e-signature, supporting information should include the same information as for Assurance Level 2
  • for digital signatures or secure e-signatures, the supporting information should include:
  • the verification certificate
  • the certification path
  • associated revocation information or status at the time the electronic data was signed
• at Assurance Level 4, supporting information:
  • is the same as a digital signature or secure e-signature at Assurance Level 3
  • must also include a secure time-stamp^{Footnote 8}

Other supporting information may also be required in order to meet specific business needs.

3.4. System and information integrity

System and information integrity is another key factor that applies to:

• the original signed electronic data
• the e-signature
• any other supporting information that may be associated with the electronic transaction (discussed in subsection 3.3 of this document)

In addition, the integrity of the association between all of these elements must remain intact over time. Some of these elements may be captured and protected in different ways, including the use of system audit logs and, or as part of, the digital signature or secure e-signature. All the supporting information, regardless of where or how it is stored, is collectively referred to as the transaction record.

It is expected that certain system and information integrity security controls will be in place to protect the integrity of:

• the electronic transactions
• the transaction records

ITSG-33, Annex 1, defines three integrity levels: low, medium and high. This document anticipates that GC systems and information will be protected at the medium integrity level. The profile of Protected B, medium integrity and medium availability, defined in ITSG-33, Annex 4A, Profile 1, should be consulted to determine the minimum security controls that should be in place, particularly with respect to the following security control families:

• access control (AC)
• audit and accountability (AU)
• identity and authentication (IA)
• system and information integrity (SI)

Recommendations for integrity requirements at each assurance level are as follows:

• at Assurance Level 1, medium integrity applies; however, there is no requirement to maintain or retain transaction records

• at Assurance Level 2:
  • medium integrity applies to the electronic transaction and the transaction record
  • the transaction record should be retained as stipulated for Assurance Level 2 in ITSP.30.031 (see Table 9, Records Retention column) or by applicable legislation, policy or business requirement
• at Assurance Level 3:
  • medium integrity applies to the electronic transaction and transaction record
  • when using a digital signature or secure e-signature, at least some of the integrity requirements will be supported by the signature itself, including the integrity of the signed electronic data
  • algorithms and associated key lengths approved by the Canadian Security Establishment (CSE) must be used as stipulated in ITSP.40.111
  • any supporting elements that are not explicitly integrity-protected by the digital signature or secure e-signature must be captured in an audit log
  • transaction records should be retained as stipulated for Assurance Level 3 in ITSP.30.031 (see Table 9, Records Retention column) or by applicable legislation, policy or business requirement
• at Assurance Level 4:
  • the secure e-signature applied by the individual signing the electronic data protects the electronic data being signed, and a combination of factors protects the signature process itself
  • a secure time-stamp is required and may be provided by a trusted third party
  • CSE-approved algorithms and associated key lengths must be used as stipulated in ITSP.40.111
  • transaction records should be retained as stipulated for Assurance Level 4 in ITSP.30.031 (see Table 9, Records Retention column) or by applicable legislation, policy or business requirement

3.5. Considerations for long-term validation

For non-cryptographic e-signatures, all the information necessary to validate the signature is expected to be available for as long as the record needs to be retained. The e-signature must be able to be verified and confirmed over time.

For a digital signature or secure e-signature, there are a number of steps to ensure that the signing operation is performed with legitimate credentials at the time the electronic record is signed. These steps include verifying that the public key certificate that corresponds to the private signing key:

• is within its specified validity period
• has not been revoked
• successfully chains to a recognized trust anchor

However, over time, some aspects of validation that were in place when the electronic record was signed may change. For example, the public key certificate may expire, or it may be revoked. In addition, advancements in cryptography and computing capabilities may make a cryptographic algorithm (or the associated key length) used to perform the signing operation vulnerable at some point in the future.

This is where the concept of long-term validation (LTV) becomes important. Because circumstances will change over time, it is important to cryptographically bind certain information to the originally signed electronic document or record. Such information includes:

• the time at which the electronic document or record was signed
• the public key certificate(s) required to verify the signature
• the associated certificate revocation status information at the time the electronic record was signed

The procedure for LTV can be recursive to accommodate changes in circumstances over a long period so that the originally signed electronic document or record can be verified for many years or even decades. Technical specifications have been developed to support LTV based on the format or syntax of the electronic document or record as follows:

• the Portable Document Format Advanced Electronic Signature (PAdES) standards
• the eXtensible Markup Language Advanced Electronic Signature (XAdES) standards
• the Cryptographic Message Syntax Advanced Electronic Signature (CAdES) standards

Another consideration is a change to the format of the original electronic data document or record, such as when it is converted for long-term archiving. Changing the format will render the original digital signature or secure e-signature invalid, as the embedded data integrity check will fail. In fact, the signature may be removed altogether because of the conversion. In some cases, it may be possible to create a new digital signature or secure e-signature (for example, by using a trusted source to verify that the converted content was originally signed by a specific individual at a certain time). Another possible solution is to adopt standards that are specifically designed to address LTV issues, such as PDF/A-2. However, such options may not be possible in all circumstances, and there may need to be another solution such as retaining metadata that indicates the circumstances under which the original content was signed (such as who signed it, when it was signed, etc.).

Although expected to be extremely rare, there may be cases where a public key certificate is revoked with the invalidity date and time set to sometime in the past. This could be due to several reasons, including discovering that the private signing key had been compromised but the compromise was not detected until some point in the future. This could mean that a digital signature or secure e-signature that was thought to be valid at the time it was created is actually invalid, as the certificate status should have been revoked at the time the electronic document or record was signed. In this case, procedural steps (which are outside the scope of this document) must be taken to determine whether the signature was created by the claimed individual and under the appropriate circumstances.

3.6. Using third-party service providers

Third-party service providers offer various forms of e-signature services that the GC can use, under appropriate circumstances. Business owners must assess whether a third-party service can be used based on:

• specific business requirements
• associated minimum assurance levels

In addition, third-party solutions should be based on industry-accepted standards. Proprietary solutions should be avoided wherever possible to prevent vendor lock-in and to promote interoperability.

There are a number of reasons that services provided by third parties may be considered. For example, a third-party vendor may offer a suitable workflow product that meets the needs of the department (that is, it supports a given business requirement and meets the e-signature and audit requirements). Another example is where a cloud service provider offers acceptable e-signature capabilities to support a GC application hosted in the cloud.

Another consideration is when the GC is interacting with external businesses and individuals. Digital signatures created by the GC need to be verified by these external entities, and therefore it will be necessary to use certificates that have been issued by CAs that are recognized external to the GC.^{Footnote 9} There may also be circumstances where a digital signature is generated by an external entity that will also need to be recognized by the GC.