Government of Canada's
Legal and Policy Framework for
It seems to be the goal of every government to be the "most connected" in the world, and the
Government of Canada is no exception. The federal Government's intention to become the
country the most electronically connected to its citizens was announced by the Prime Minister in
1999,2 giving departments their marching orders and a target date of 2004. The December
2001 Budget continued to support the Government On-Line (GOL) initiative and extended the
deadline to 2005.
GOL is being implemented through an iterative, staged approach. The first stage obliged
departments to establish a presence on the Internet. As most departments already had a web-
site of some sort, this objective was quickly accomplished and just as quickly declared a
The second and third stages are of a more interactive nature, and are proving to be more of a
challenge. Departments are directed to make their key services available on-line, going beyond
simply making Government forms available on-line, to making it possible to complete and
submit them on-line, as well as to facilitating on-line inquiries.
The third stage involves collaborating and co-ordinating with others, including with other
departments and programs within the Government of Canada, with other governments in
Canada, other countries, and the private sector.
The overall objective of GOL is a "service vision" - the Government must use information and
communications technology to enhance Canadians' access to improved citizen-centred,
integrated services, "anytime, anywhere, and in the official language of their choice". This
means that the Government needs to enhance its ability to provide services to citizens across
different communications channels, and across programs, departments, jurisdictions, and
sectors. It also means that work needs to be done across the Government to achieve those
Senior Counsel, Department of Justice, Treasury Board Legal Services. The views expressed herein are not
necessarily those of the Department of Justice; September 2002.
Prime Minister's Response to the Speech from the Throne, October 13, 1999. "Governments can, and should, be at
the leading edge of the information revolution. A model user of the new technologies to improve services to
Canadians. By 2004, our goal is to be the most electronically connected government in the world to its citizens. So
that Canadians can access all government information and services on-line at the time and place of their choosing."
From www.tbs-sct.gc.ca/pki-icp/gocpki/frame/frametb-eng.asp 12 October 2008
objectives, making federal services more available, accessible, and easier to find, while building
public trust and confidence in federal electronic-service delivery.
This work is being led by the President of the Treasury Board, who has been declared
champion of Government On-Line. The Government On-Line Project Management Office was
established under the Chief Information Officer Branch, and has responsibility for co-ordinating
the implementation, monitoring and reporting of GOL. It is responsible for "leading the
development of horizontal enablers, consolidating the departments' and agencies' progress,
issues, and successes, as well as reporting these to Ministers... ."
The work on GOL involves all departments and many disciplines within those departments, from
the techies, to the lawyers, the policy-wonks, and ultimately to the decision-makers. Older work
on electronic service-delivery has had to be revisited to determine its continued applicability and
relevance, and new work is underway, as evident in the proliferation of policies, papers,
programs, and laws that relate in some way to citizen-centric services in general, and to GOL in
This paper is intended to describe that framework of laws, policy, and technology, in relation to
a couple of GOL endeavours. The first relates to the security of electronic transactions with the
Government; the second relates to the concept of "collaborations".
The Government of Canada is committed to public key encryption to secure electronic
transactions where that level of security is required. The Government of Canada Public Key
Infrastructure (PKI) is being implemented through the Secure Channel, which is a single secure
channel for electronic communications being operated by Public Works and Government
Services Canada though a contract with a consortium of service-providers. The Secure
Channel project, and the first application to use it, is scheduled for launch this fall. It
demonstrates the iterative and evolutionary nature of PKI and of the processes for developing
PKI-enabled applications, all in a framework of law, policy and technology that must continually
evolve and shift to meet the sometimes conflicting, and sometimes shifting, goals of the various
Similarly, the Government of Canada is seeking ways to collaborate and cluster with others
which, in an on-line environment, challenges and tests existing governance and policy
There is no "Government On-Line Act" of Canada. GOL is situated within a complex and
sometimes confusing framework of laws of general application, including the Personal
Information Protection and Electronic Documents Act; departmental and program-specific
legislation; Treasury Board policies - of which there are many; common law and jurisprudence;
and other legal arrangements and Department of Justice legal opinions. It is hoped that this
paper will give some guidance through that maze.
A. Public Key Infrastructure
GoC PKI Update
Interoperation -internal cross-certification
Secure Channel - the first app
-Secure Channel and Epass
-Privacy Impact Assessment
B. Personal Information Protection and Electronic Documents Act Update
C. On-Line Collaborations with the GoC
-some types of internet collaborations
-applicable laws and policies
D. Other - a Few Loose Threads
- Government On-Line Procurement Strategy
- GOL Checklist of Legal Issues
- Retention of Digitally Signed and Encrypted Documents
A. Public Key Infrastructure3
Much has been said about the complexity and difficulty of implementing public key technology.
It is all true. The GoC PKI project has been under development for over 5 years, involving over
300 people across the Government of Canada. Progress has been made over the years, with
directions and strategies undergoing several re-alignments.
GoC PKI Update
New GOL Certificate Policies4:
The Policy on Public Key Infrastructure Management in the Government of Canada, called the
"PKI Policy", 5 was approved by the Treasury Board in May of 1999, and the Policy
Management Authority (the PMA) approved the Government of Canada Certificate
Policies.6(GoC CPs). Those Certificate Policies were "model" CPs, drafted with the hope that
departments and others would adopt them and, in fact, they have done so.
This year, the PMA has for approval a new set of Certificate Policies designed specifically for
Government On-Line and Secure Channel. These new CPs reflect three facets in the evolution
of the GoC PKI. The first is simply the fact that departments have acquired some experience in
implementing PKI for their programs, and have identified some things that they perceived as
interfering with that implementation, as well as with the take-up of PKI by citizens and
businesses outside of the Government.
The second is the decision to offer GOL services through a single central Certification Authority
offered by the Secure Channel.
The third is the acquisition of a license for a new PKI technology which has features different
from the technology upon which the earlier CPs were drafted.
i. Single Central Certification Authority. The old GoC CPs were drafted to be adopted by the
Canadian Central Facility (the GoC Bridge CA) and to act as the baseline against which other
CPs would be measured for purposes of cross-certification. Departments generally adopted
them with some variations to accommodate specific program requirements. The GOL CPs, on
the other hand, were drafted for a Certification Authority "tasked with the provision of CA
services for the Government of Canada". At present, the Secure Channel Certification Authority
is the only Certification Authority that has been named.
ii. Two types of Certificates. The GoC CPs created four levels of certificates based on a scale
of strength of assurance ranging from "rudimentary" to "high assurance". The level of
assurance increased according to the rigour of the authentication processes required, as well as
to the strength of the encryption used. Liability limits and recommended uses were established
accordingly, ranging from $5,000 for "basic assurance", to $1,000,000 for "high assurance".
For an introduction to PKI, see "PKI for Beginners" on the PKI web-site: http://www.cio-dpi.gc.ca/pki-
icp/beginners/beginners_e.asp. For convenience, attached as Annex A is an excerpt from the TB PKI Policy
When published, they will be on the PKI web-site referred to in footnote 3.
The GOL CPs create two types of certificates:
i. General Purpose certificates - these are digital signature and confidentiality
certificates intended for use where a program does not require assurance that the subscriber
(i.e. a citizen or a business) has a secure information technology environment; and
ii. Limited Purpose certificates - these are digital signature and confidentiality certificates
intended for use where a program does require assurance that the subscriber has a secure
information technology environment.
What constitutes a secure technology environment is defined in the GOL CPs. It includes an
obligation on certificate holders, or "subscribers", to certify that they have taken appropriate
measures to maintain anti-virus mechanisms, implement security patches and software
updates, maintain security policies, and adopt strong password policies. It is expected that
large organizations with sophisticated information technology security would most likely be
eligible for the use of Limited Purpose certificates.
The decision of which "level of assurance" is appropriate is to be made by program managers
and is based upon threat-risk assessments. In reality, most programs offered for individual
citizens, as opposed to businesses, will likely rely on General Purpose certificates.
iii. Authentication: The GoC CPs did not contemplate on-line authentication. For basic or
medium assurance certificates, a citizen had to submit two pieces of identification; for high
assurance, the subscriber had to present himself in person for authentication. Authentication
processes are time-consuming and expensive, particularly when dealing with large numbers of
citizens from across the country. Accordingly, other options were considered.
The GOL CPs, then, are more permissive in nature - they require only that a subscriber's
identity "be authenticated in any manner sufficient to satisfy the CA or an RA [a Registration
Authority] that the individual has the identity he or she claims to possess." [s. 3.2.3]
Identification and authentication can be done electronically, on-line, where a department already
has some private information about the citizen, that only that citizen and the department should
know, (often called "shared secrets") on file in its program legacy databases. The shared
secrets are submitted on-line and validated or verified against the legacy database. If there is a
match, then there is assurance that the citizen is the person with whom those secrets are linked
in the program database. It is up to the program manager to determine whether the shared
secrets are sufficiently secret, and therefore the strength of the authentication sufficiently strong,
for the requirements of a particular program, based on a threat-risk analysis.
iv. Liability: In the GoC CPs, the federal Crown's liability for the issuance and management of
public key certificates was capped at amounts which varied according to the assurance level of
the certificate. These amounts were established on the basis of commonly used financial
authorities for Government officials, but were largely arbitrarily defined. Program managers
found them difficult to reconcile with the estimated damages predicted in the event of losses
relating to their particular programs.
The GOL CPs take a different approach - they do not establish caps on liability; nor do they
mandate program managers to do so. The decision of whether or not to cap or otherwise limit
the federal Crown's liability to subscribers is left to program managers, to be determined on a
However, within the Government of Canada itself, the financial responsibility of the Certification
Authority for any PKI-related losses in relation to a program is established by the GOL CPs. In
other words, if the Crown is found liable for a loss suffered by a citizen, the loss will be paid out
of the Consolidated Revenue Fund, but is allocated to the budgets of the departments involved.
The allocation to the CA is limited and capped in the CPs, and this cap is imposed on
departments by Memorandum of Understanding. Program managers, then, need to take that
cap into consideration in their decision to limit their own department's liability or not.
v. Organizational Certificates: Under the GoC CPs, everyone to whom a certificate was issued,
or who was made responsible for a private key given to a device, was required to sign a
subscriber agreement with the Crown. This meant that departments were obliged to identify
and authenticate each and every such employee in a business, and to convince them to sign a
contract with the Crown. Needless to say, departments encountered resistance. Employees of
businesses were unwilling to sign user agreements containing indemnities and limits on liability,
and were uncomfortable with authentication processes being done by the Government.
Departments, at the same time, found the process burdensome.
The GOL CPs attempt to alleviate the burden while maintaining the safeguards. For certain
qualified organizations, the CA issues certificates to their employees on the direction of their
employer organization. The organization itself is made responsible, in a master subscriber
agreement, for the identification and authentication of its own employees. Employees are not
required to sign agreements with the Crown. Organizations are encouraged to have internal
policies governing the use by employees of their certificates, but it is not a condition of the
master agreement. The Crown does not ask for the names of the employees to whom these
certificates are allocated, but the organization is obliged to keep records and to provide them on
demand. In order to ensure that the organization takes its responsibilities seriously, it is
required to assume full responsibility for the use of the certificates by employees, and is bound
by their digital signatures.
vi. Devices, roles and groups: Like the GoC CPs, the GOL CPs permit digital certificates to be
issued to devices and roles if there are individuals who will assume responsibility for their use.
Those individuals must be authenticated by a qualified organization or by the CA or department.
There seems to be some demand for certificates to be assigned to "groups". There may be
circumstances in which a certificate is used for purposes other than "signature", where it is not
necessary to know the identity of the certificate-holder. For example, a group certificate could
be shared by more than one individual if it was to be used for controlling access to information
or for the additional security features provided by a digital signature.
Where a certificate is shared, though, it is not likely that it would constitute a "signature" within
the common law meaning of the word. Nor would it necessarily constitute a "secure electronic
signature" within the meaning of section 48 of the Personal Information Protection and
Electronic Documents Act7 which requires, among other things, that the certificate be used "by a
http://laws.justice.gc.ca/en/P-8.6/85538.html#rid-85654 The Governor in Council may prescribe a technology or
process only if the Governor in Council is satisfied that it can be proved that
(a) the electronic signature resulting from the use by a person of the technology or process is unique to the
(b) the use of the technology or process by a person to incorporate, attach or associate the person's electronic
signature to an electronic document is under the sole control of the person;
(c) the technology or process can be used to identify the person using the technology or process; and
person"; be "unique to the person"; and "under the sole control of the person". The risk, then, is
that a certificate would be used by a group with the expectation that it would be creating a
legally valid and enforceable signature binding on the group when that may not, in fact, be the
In a small, closed environment, the use of group certificates could likely be managed.
Certificate policies could create special classes of certificates expressly designed to be used for
access control, which could be used by groups for non-signature purposes. In addition,
instructions could be given to personnel in the course of training for the use of PKI. For non-
personnel, obligations concerning the use of the various types of certificates could be set out in
user agreements. For the GoC, though, it was felt that at this time, it would be too difficult to
control the use of such certificates; that the message may not be well understood by users that
group certificates should not be used for signature purposes.
vii. Security: The GOL CPs expressly recognize the fact that PKI is not in and of itself a
complete security solution; rather, it is part of a security package. For example, certificates
issued under the GOL CPs are not to be used for certain types of high-risk transactions unless
supplemented by additional security mechanisms.
(d) the electronic signature can be linked with an electronic document in such a way that it can be used to
determine whether the electronic document has been changed since the electronic signature was incorporated
in, attached to or associated with the electronic document.
The GOL plan is to foster and improve citizen-centric service delivery. Ease of access to
Government services and information means making it easier for citizens to access services
across programs, departments and jurisdictions. For PKI, it means being able to use and rely
on public key certificates issued by other certification authorities (CAs). In theory, cross-sectoral
certification would simplify the conduct of e-transactions for citizens, since they would have to
go through fewer authentication processes and remember fewer passwords.
There are two levels at which interoperation must be achieved: i. within the GoC; and ii.
outside the GoC.
The Government of Canada PKI is based on a "bridge certification authority" model. The
infrastructure and its rules are established by the Treasury Board's PKI Policy8. This means
that there is a central certification authority, the "bridge", which is in this case, the Canadian
Central Facility (CCF), as well as certification authorities maintained by departments
Departments are free to operate more than one certification authority. They can contract out for
their CA services, whether from another Government department or from a private sector
service-provider, but they must remain accountable for their own CAs.9 If a department wishes
to issue certificates to the public, then it must cross-certify with the Canadian Central Facility, or
ask the Policy Management Authority for an exemption.
In order for departments to be able to recognize and rely on certificates issued by other
departments, the GoC uses the method of "cross-certification".
What is cross-certification? In this model, the CCF issues cross-certificates to departmental
Certification Authorities, provided that they meet all the requirements for cross-certification. The
requirements are set out in the PKI Policy and in the Cross-certification: Methodology and
Guidelines10 published by the Policy Management Authority. Essentially, the process is
designed to establish a relationship of trust between two or more Certification Authorities, so
that each can rely on the other to issue certificates in accordance with standards and to a level
of assurance at least equivalent to its own.
In the cross-certification model, it is the PMA that determines whether a CA meets all the
conditions of cross-certification. The exchange of cross-certificates means that the PMA is
satisfied that the certificates issued by the subordinate CA are reliable. All departmental CAs
which are cross-certified with the CCF can trust and rely upon each others' certificates as if they
had issued them themselves.
Within the GoC, the cross-certifications are "mutual", meaning that each issues a certificate to
the other. There can be "unilateral" cross-certifications, where one CA issues a certificate to the
other, in which case the interoperability between the two would be one-way only.
See footnote 5.
By the Government Security Policy, deputy heads are responsible for the security of their departments. See:
The process for cross-certification is an arduous and burdensome one. It is a lengthy and
painstaking process of mapping one CA's certificate policies against the CPs of the PMA - in our
case, the GoC CPs of 1999. All variations and discrepancies between them are noted, and
decisions must be made as to whether these variations affect the overall security and
trustworthiness of the CA. At the same time, the legal arrangement has to be negotiated, and
trials are conducted for technical interoperability using test-beds.
The length of the process is further extended simply because the necessary resources are
scarce. There are few people qualified to carry out inspections and audits of CAs and of their
CPs and CPSs, and test-bed facilities are equally scarce.
For the Government of Canada, the cross-certification process is described in great detail in the
Cross-Certification: Methodology and Guidelines. This Methodology applies to cross-
certifications of departmental CAs, as well as to cross-certifications with CAs outside of the
Government. It sets out the process for cross-certification and the rules that the GoC follows,
from the application process through to the legal arrangement, and to enforcement and
maintenance. Ultimately, the decision of whether to cross-certify is made by the President of
the Treasury Board.
The Process is comprised of four phases. The first is the "Initiation" phase. Requests for
application to cross-certify are required to be submitted for review. This phase is an initial
screening mechanism to allow, with a minimum of effort, a preliminary review to determine
whether the applicant has policies which seem compatible with those of the GoC. If not, for
example, if the CP provides for mandatory key escrow, then the request to commence the
process could be refused.
On the other hand, the preliminary review may indicate that the applicant is a good candidate for
cross-certification, in which case the application will be placed in the queue. Requests must be
sponsored by a department of the GoC, to ensure that the cross-certification process and
resources are expended where there are legitimate business or other reasons for cross-
The second phase is the "Examination" phase. It details the steps for mapping the CPs to
determine the compatibility of the policies, for conducting a test-bed trial to determine technical
interoperability of the CAs, a survey of the information technology system, and finally, the
evaluation of the information technology security and policy processes.
The examination process involves a weighing and an assessment of sometimes different
approaches to security and authentication. In other words, CPs need not be identical - it is the
overall or cumulative equivalence of security, policy and processes that is assessed. Where
one CA, for example, may prohibit on-line authentication, another may permit it while bolstering
the strength of assurance in some other way.
The evaluation of a CA's compliance with its own security process and policies is based on a
"self-certify" approach, wherein a CA is required to conduct its own audit and inspection and to
certify, in a form prescribed by the Methodology, that it is in compliance with its Certificate
Policies. This certificate is supplemented by appropriate covenants in the legal arrangement.
The alternative to this approach would involve too great an expenditure of resources: it would
require an on-site audit and inspection by qualified personnel. Even if there were enough
qualified auditors to do the work, the cost is prohibitive. For internal cross-certifications with
GoC departments, they are already obliged by the Government Security Policy11 to have their
information technology systems certified and accredited in accordance with established
standards. For CAs outside of the Government, financial security may be required.
The third phase is the "legal arrangement". All departments must sign the same Memorandum
of Understanding - there is no negotiation - and in fact, the MOU is annexed to the Treasury
Board PKI Policy. Through the MOU, departments agree to abide by the decisions and
directives of the PMA, thereby creating a cross-Government infrastructure that continues to
support departmental autonomy.
"Liability" amongst GoC departments is not an issue, since departments cannot sue one
another, but financial responsibility is. Where a loss is caused by a department, the damages
would be paid from the Consolidated Revenue Fund, but would be allocated to that
department's budget. Accordingly, the MOU establishes rules for that allocation where more
than one CA is implicated in the event causing the loss.
That allocation of financial responsibility can lead to disputes, so the MOU establishes a dispute
resolution process. It provides for negotiation, followed by mediation, and finally, if all else has
failed, the PMA may appoint a PKI expert. The decision of the expert is made binding on the
parties as a term of the MOU, and enforced through termination of membership in the GoC PKI
and revocation of the cross-certificate.
The fourth phase of the cross-certification process is called "Maintenance". This involves the
continued assessment of compliance with policies and procedures; it permits audits on
occasion; it establishes a problem resolution process; and a change management process.
Finally, in conjunction with the provisions of the MOU or cross-certification agreement, it sets
out the procedures for termination, including revocation of the cross-certificate.
At every stage in the cross-certification process, there are "decision points". Cross-certification
with the Government of Canada is at the discretion of the Crown and is not an entitlement.
Ultimately, the decision to cross-certify is made by the President of the Treasury Board, on the
recommendation of the Secretary who receives the advice of the PMA.
At present, eight departments have cross-certified with the CCF. Among them is Public Works
and Government Services Canada which serves as a PKI service-provider for many other
departments. When the Department of Public Works and Government
Services (PWGSC) was cross-certified, it facilitated the cross-certification of 47 other
departments who had adopted PWGSC's CPs and use its services. In total, then, there are 55
departments and agencies cross-certified through the Canadian Central Facility.
The GoC recently conducted its first external cross-certification with the Ontario Provincial
Police. At the time of writing, the cross-certification agreement has been negotiated but not yet
signed. The process has illustrated for both parties the kinds of issues that can be expected
from cross-certifications with other governments.
The standard cross-certification agreement prepared by the GoC addresses issues similar to
those addressed in the internal MOU except that, while an MOU is not generally enforceable in
the courts, a cross-certification agreement has to be enforceable. So, in dealing with the OPP,
the nature of the agreement had to be addressed. Her Majesty the Queen is indivisible, and
has traditionally been thought not to be able to sue Herself. However, for some provincial or
federal agencies, a statute may give the express authority to contract; for others, such as some
regulatory statutes, provision is made for suits between different emanations of the Crown. As
dealings between governments take on a more commercial aspect, as opposed to being
"governmental" in nature, the contract is replacing the MOU as the vehicle for arrangements
between emanations of the Crown.
Elements of a cross-certification agreement
Appendix C to the PKI Policy sets out some mandatory minimum elements for a cross-
certification agreement with the GoC, and these are reflected in a standard form cross-
certification agreement. They include, not surprisingly, provisions dealing with liability and
indemnities. For cross-certifications with non-government entities, and even for some levels of
government, some sort of financial security may be required, such as a bond or letter of credit.
The agreement also deals with the nature of the CA's standard subscriber agreements, and
what amendments may be made to the CAs' CPs with or without prior notice to or the approval
of the other. Record-keeping requirements are dealt with, as are privacy and confidentiality
provisions, particularly with respect to personal information about citizens and access to the PKI
directory. The Government of Canada is self-insured, but the agreement contains insurance
requirements for others.
The standard cross-certification agreement also addresses the addition of new cross-certified
CAs by either party, sometimes called "transitive trust". Essentially, the concern is as follows:
CA1 cross-certifies with CA2. CA2 cross-certifies with CA3. CA1 may automatically become
cross-certified with CA3, in which case CA1 and CA3 will be able to verify and rely on each
others' certificates, against the wishes of CA1. Aside from the obvious issues of liability and
privacy, governments may have particular concerns about "transitive trust" - it may not be
desirable from a political perspective to be cross-certified in such an indirect fashion. The
cross-certification agreement requires notice of any additional cross-certifications and gives the
option to terminate. As an additional safeguard, certificate paths and fields can now be
appropriately constrained, so that departments within the GoC PKI may decide whose
certificates they wish to accept.
Whether a cross-certification is with another government or a private sector entity, there will
have to be continued requirements for assurance of compliance with the CPs and CPSs of the
parties, together with the right to cause audits to be made in certain circumstances where there
may be reason to believe that a CA is not meeting the standards agreed upon.
As mentioned, over 50 departments have cross-certified with the CCF as of the date of writing
and the first external cross-certification, being with the OPP, is almost completed. Future cross-
certifications are already being contemplated with the Province of Ontario, the Bank of Canada,
the Canadian Payments Association, and the U.S. Federal Bridge Certification Authority, among
It is clear that the cross-certification process is a time-consuming and expensive one. At the
early stages of PKI, where the number of external cross-certifications is small, it can and does
work. However, when the demand for cross-certification and interoperability increases, other
options may have to be sought.
There are a number of models out there to achieve interoperability for PKI, and these are being
examined in a number of different fora. The federal Government is starting to look more closely
at the "bridge CA" operated by the U.S., as well as at some kind of central PMA\CA model,
perhaps a national CA, being looked at by the Public Sector CIO Council. Other models that
may be examined in the future include: certificate trust lists; accreditation; licensing; or cross-
The GoC PKI is for all intents and purposes, a "bridge" CA. The model is also illustrated by the
U.S. Federal Bridge Certification Authority project13.
A bridge CA is defined as a "non-hierarchical hub designed to permit disparate agency public
key infrastructures to interoperate seamlessly."14. It allows different PKIs, using different CPs
and different technologies, to recognize the certificates of others.
In the U.S.F.B.C.A., each PKI exchanges a pair of cross-certificates with the Federal Bridge and
creates trust paths among the individual CAs. The Bridge does the policy-mapping and ensures
that the directories are compatible. Cross-certifying agencies so far include NASA, the Defense
and Treasury Departments.
The European Commission recently published a feasibility study of a bridge CA for the public
administrations of member states. 15 The Study recommends adopting a model similar to that of
See the PKI Forum: White Paper, CA-CA Interoperability, March 2001 at http://www.pkiforum.org/pdfs/ca-
Federal Bridge Certification Authority web-site: http://www.cio.gov/fbca/whatis/index.htm; and see:
http://www.cio.gov/fbca/documents/altermanpaper.doc, U.S. Federal PKI and Federal PKI Bridge Certification
Authority, by Peter Alterman.
See also PKI at the crossroads - Agencies aim to streamline secure data exchanges using federal PKI bridge,
Jennifer Jones, June 24, 2002; and Bridge partners span many levels of government, Jennifer Jones, June 24, 2002,
both downloaded Aug. 16, 2002 at http://www.fcw.com/fcw/articles/2002/0624/tec-pki-06-24-02.asp
A bridge CA for Europe’s Public Administrations – Feasibility Study,
the U.S.F.B.C.A., with some variations. The EC model contemplates a Europe-wide CP which
could support a trusted certificate path, or which each member state could include in a list of
trusted certificates. Member states would have the option of filtering out the certificates of the
CAs with which they did not wish to interoperate.
It is contemplated that the Bridge would be used for European e-procurement, administrative
services such as social security, and other services to citizens.
It would be governed by a PMA comprised of representatives from member states, and which
would derive its authority from an MOU with the participants.
The notion of a Canada-wide Bridge for all levels of Canadian governments is something that
the Public Sector CIO Council is starting to look at. The model would include a PMA comprised
of representatives from participating provinces, territories and municipalities, having a common
set of rules, principles and procedures enabling different jurisdictions to cross-certify with one
another through the Bridge.
The notion of a single national certification authority is another possibility that has not yet been
analyzed in any detail. It would entail a single certificate-issuing body to replace the PKIs of
other jurisdictions, issuing certificates to citizens for use with any participating government.
There would be single set of CPs and CPSs, and a single governing body.
The precise legal nature of these interoperational arrangements has not yet been developed.
However, it seems possible, if not likely, that the participation of various levels of Canadian
governments would entail legislative changes to deal with questions of jurisdiction, authority,
liability and funding.
Notwithstanding the choice of model for interoperation, whether within the Government or
among different jurisdictions, it is important to remember that the PKI-part is just one part of the
infrastructure. In particular, privacy laws and departmental statutes will govern and constrain
the sharing of public key certificates issued to citizens and access to any information about
them contained in a directory. This may be what the techies mean when they say that the
technology is the easy part.
Secure Channel - the first "app"
Why PKI?16 Surveys show that Canadians continue to be reluctant to transact business over
the Internet principally for reasons of security.17 In dealing with their government, they are
particularly concerned about the security of their financial and medical information.
PKI can provide a significant degree of security for on-line dealings with the Government. When
supported by a strong policy and procedural framework, public key technology provides
authentication services; it protects the integrity of data; it can provide evidence of non-
repudiation; and it can provide electronic signatures that are more reliable than other kinds of
Departments in the GoC have a choice as to whether or not to use PKI for their particular
program or service - use of the GoC PKI is not mandatory. While there may come a time when
it would be considered negligent not to use PKI18, when the question becomes "why not PKI?",
that time has not yet arrived. Right now, departments make the decision of what security their
programs require based on a threat-risk assessment and considering factors such as the need
for authentication; the need for data integrity and security; the legal and evidentiary
requirements for the particular transaction; and some basic privacy principles.
i. The need for authentication. It is not always necessary for on-line service-providers to know
who you are. The GoC respects the right of people to deal with it anonymously as its default-
setting, except where there is a need to identify and authenticate them. For example, where an
individual is simply requesting information, or is seeking to personalize his web-browsing, then it
is not necessary for the Government to know his identity. However, where someone is seeking
a Government benefit or entering into a contractual relationship with the Government, or fulfilling
a statutory filing or reporting requirement, then it may be necessary to know who they are, and
to ensure that they are who they claim to be.
Programs that require authentication services do so to varying degrees, depending again on the
nature and type of the electronic communication. For some programs or transactions, such as
information filing or reporting, a PIN and password approach may be adequate, using Secure
Socket Layer (SSL) for confidentiality. However, where the transaction involves access or
changes to personal information, or to sensitive business information, or where enforcement
mechanisms are criminal or quasi-criminal in nature, then PKI will be necessary for more
assurance of identity.
Even in a PKI, there are various degrees of authentication, and the strength of assurance of the
identity of the person, and the binding of that person to a public key in a digital certificate, will
depend on the method of identity-proofing or verification conducted by the CA. Authentication
procedures range from "in-person identification" where the person must physically present
himself to an official with identity documents and a guarantor; in-person identification without a
See Annex B: TBS graph of levels of security. See also Online Authentication: a guide for Government
Managers, National Office for the Information Economy (NOIE), Australia, http://www.noie.gov.au/publications
Canadians steering clear of on-line shopping, Canadian Press, globeandmail.com, posted Sunday, August 18,
See T.J. Hooper v. Northern Barge, 60 F (2d) 737 (1932); United States v. Carroll Towing, 159 F 2d 169 [2d Circ.
1947]; Pittman Estate v. Bain (1994), 112 D.L.R. (4 ) 257 (Ont. G.D.)
guarantor; submission of original identification documents by mail; to on-line authentication
using secrets shared by the applicant and the program.19
ii. The need for data security and integrity. In order for citizens to trust the Internet, it is
necessary to provide adequate security for their on-line transactions. Where information is
personal or sensitive, then program managers are obliged to consider implementing appropriate
technologies to provide security.
SSL can provide for confidentiality of information in transit, as it encrypts messages between
servers. It is very useful for submitting information that needs to be kept confidential, and it can
be used in conjunction with PINS or passwords to provide some authentication. However, only
a digital signature using public key technology offers the additional feature of ensuring that a
message is not tampered with in transit. A digital signature can be combined with SSL in order
to provide strong authentication, confidentiality encryption, and data integrity.
Public Key technology and SSL alone are not, of course, the only elements of data security.
Physical access controls, proper training, firewalls, and virus scanners, are all part of an
information technology security plan.
iii. Legal and evidentiary requirements. The legal nature of the electronic communication and
the degree of proof that may be required if something goes wrong are also factors in the
decision to use Public Key technology. Where there may be a need to enforce a contractual
obligation, or to prove the elements of a criminal or regulatory offence, then strong
authentication and evidence of non-repudiation may be required.
In addition, Part 2 of the Personal Information Protection and Electronic Documents Act gives
certain benefits where a "secure electronic signature" is used to substitute for a paper one.
Data signed with a secure electronic signature may constitute an "original", a "certificate", or a
statement made under oath. Proposed secure electronic signature regulations may facilitate
proof of identity by creating a presumption that a person named in a certificate is the signer, in
the absence of evidence to the contrary.
iv. Basic, fundamental privacy principles. The Privacy Act provides a minimum code of privacy
practice applicable to all federal Government institutions named in the schedule to the Act.
Various Treasury Board Policies, such as the Policy on Privacy and Data Protection20 and the
more recent Privacy Impact Assessment Policy21, provide guidance on the implementation of
the Act and its application to particular projects.
Essentially, the fundamental privacy principles set out in the Privacy Act are in the Code of Fair
Information Practice in the schedule to Part 1 of the Personal Information Protection and
Electronic Documents Act.
From this statutory and policy framework, a number of guiding principles emerged in relation to
the implementation of authentication services. These include:
Note that the Treasury Board Policy on Electronic Authorization and Authentication requires public key certificates
to be used for a wide range of "business transactions". See http://http://www.tbs-
a. authority to collect - personal information can only be collected if it is necessary
for the purposes of some program or activity that is based in statute. This means that a
person's identity should be authenticated only where it is necessary for the program;
b. only the department which is responsible for the program can collect that
c. the department cannot collect any more information than is necessary for the
d. personal information cannot be shared among programs without free and
informed consent, unless otherwise provided in some statute. This means that
information silos must be preserved;
e. citizens will have a choice of communications channels with the federal
Government; services will continue to be offered via mail, in-person, and telephone;
f. certificates will not be held in a public directory and citizen common names will
not be used in certificates. Rather, certificates will contain an "MBUN", being a
Meaningless But Unique Number, stored in an access-controlled directory; and
g. citizens will have a choice of using one certificate for a number of Government
programs or of having different certificates for different programs.
Secure Channel and Epass
The first implementation of the GoC PKI through the Certification Authority operated by Secure
Channel is scheduled for launch early this fall. At that time, individual taxpayers will be able to
change their address with the Canada Customs and Revenue Agency on-line for all income tax
programs. The public key certificates issued to taxpayers for this purpose are called "Epasses".
It has taken close to a year to develop this Epass model, and it has involved the collaborative
efforts of a number of people, including the Secure Channel contractors, PWGSC project
managers, CCRA program and PKI experts, Treasury Board's PKI and information technology
security experts, Treasury Board's privacy experts, lawyers for all
stakeholders, and contractors to do the requisite Privacy Impact Assessment. It used to be said
of PKI that it was a combination of law, policy and technology, and this has proven to continue
to be true in the development of this first Epass-enabled on-line service.
As mentioned, the model was designed to reflect the fundamental privacy principles
enumerated earlier. Whether that objective was achieved is measured through the Privacy
Impact Assessment process. The project is also subjected to a legal and policy impact
assessment of the various elements of the model.
An Epass is a public key certificate issued using technology that has a roaming capability.22
The Epass process provides the capability for digital signature, and uses SSL for confidentiality
encryption, up to and including the recipient server. The process uses shared secrets for on-
line authentication, which means that only those individuals who have filed income tax returns
with the Canada Customs and Revenue Agency are eligible to change their address on-line.
The Epass process is tied to the program that uses it. A user enters via the CCRA Address
Change On-line (ACO) web-site, and is presented with a choice of changing his address on-line
or by some other means. If he selects on-line ACO, then he is redirected to the Epass site.
There, he is directed to provide his shared secrets: the SIN, Web Access Code23, date of birth,
and line 150 from a previous tax return. That information is sent directly to CCRA where it is
verified against CCRA's legacy database. Once CCRA verifies that the person is in fact known
to them, and that the information matches, then the user is sent back to the Secure Channel
Epass system where he is directed to select his own userid and password. He is also prompted
to select a number of recovery questions and answers, which may later be used for on-line
password and key recovery. The Epass certificate, which contains an MBUN, is then issued,
and CCRA links the MBUN to the taxpayer's file in its tax database. The user profile, containing
the certificate and the keys, is stored, doubly-encrypted, in the Secure Channel server. The
taxpayer is then passed back to CCRA where he can digitally sign his change of address
In the event a user loses his password, or wants to change it, he can do so on-line using the
recovery secrets that he previously selected. If he loses his userid, then he must register for a
The Certification Authority in this model is essentially a certificate pump, operated by the Secure
Channel under contract with PWGSC. It issues certificates only on the direction of CCRA. It
holds the certificate profile, userid and MBUN, and the recovery secrets, which are hashed for
The model that is soon to be on-line was the result of a lengthy and evolutionary process. It
was discovered at an early stage that coordination of the efforts of all stakeholders is crucial at
the beginning of the design stage. The construction of the architecture has to be done in
tandem with the design of the application itself (in this case Epass and ACO), and has to reflect
the privacy principles as well as other legal and policy considerations. Without such
coordination, the system architecture can get ahead of things and can fail to properly address
This means that the keys can be used at a remote location such as a kiosk or publicly-available desktop without
leaving a footprint. See Annex C for a diagram of the epass issuance process.
This is a number on the Assessment Notice mailed directly to taxpayers by CCRA.
the policy and legal constraints, so that the program design may end up having to work around
an architecture that is sometimes "carved in stone".
Briefly, the process involved the development of the Epass concept, the design of the
authentication process, and drafting of initial screen-shots. At the same time, the system
architecture was being designed, and the screens were subjected to focus-testing. Initial legal
and privacy impact assessments were done. This process was repeated over a number of
months to the point in time at which the screens were declared "frozen" and no further changes
For the privacy, legal, and policy work to be done, we quickly learned that it is essential to have
a data-flow that is both comprehensive and understandable. The data-flow has to reflect the
movement of any information relating to the ultimate user, throughout the Epass and program
architectures. The development of a usable data-flow is, in itself, an arduous and time-
Like the rest of the process, the data-flow has to be continually revised as the program design
evolves, and each change necessitates another privacy, legal, policy and security review.
The Privacy Impact Assessment
The Treasury Board Privacy Impact Assessment Policy24 came into effect on May 2, 2002. The
objective of the Policy is to provide assurance that privacy principles are taken into account at
all stages of the development of a program or service. While it was first initiated because of the
heightened perception of the risk of privacy infringements from on-line transactions, it is not
limited to those; rather, it applies to programs or services offered through any service-delivery
The Policy requires that:
i. a department must develop and maintain a Privacy Impact Assessment. The assessment
itself is a step-by-step evaluation of the flow of personal information throughout the program or
service. It can follow the Guidelines25 that are annexed to the Policy, and which use a question-
and-answer format to identify privacy risks in relation to the collection, use and disclosure of
ii. a Privacy Impact Assessment (PIA) must be conducted for all new programs and services
that raise privacy issues, and where existing programs and services are substantially re-
designed or switched to a different delivery channel.
iii. a detailed data-flow is necessary together with a detailed description of the system and
architecture to document the separation of personal information or security mechanisms that
prevent improper access to personal information or preserve silos.
iv. privacy analysis and report - The data-flows are analyzed for compliance with privacy
principles, and risks are identified together with risk mitigation strategies. The report must
provide assurance that there are no outstanding privacy implications, or it can serve as an early
warning, in which case the system or program may have to be redesigned.
v. a copy of the final PIA must be provided to the Privacy Commissioner at a "reasonably early
stage" prior to implementing the program. The results of the PIA must be made available to the
The Guidelines themselves form an outline for the PIA report, identifying the stages of analyses
required, from project initiation, data-flow analysis, privacy analysis, through to the report. They
also highlight the more "common" privacy risks that a PIA is designed to assess, including data-
matching and profiling, transaction monitoring, identification of individuals, publication or sharing
of databases containing personal information, and the lack of or doubtful lawful authority.
The Privacy Impact Assessment for Epass26
The PIA process is an iterative one. For the Epass/ACO program there were a total of four PIAs
completed over time. This is not because any serious privacy risks were identified, but rather
that the design of the program, the architecture and specifications, and consequently the data-
flows, continued to evolve over the course of several months.
The PIA process confirmed that the fundamental privacy principles set out for the program had
in fact been respected.
i. Silos are preserved. The architecture separates the Secure Channel central Certification
Authority function from CCRA so that personal information collected for authentication purposes
is held only by CCRA. In other words, the process for issuing an Epass is separate.
ii. There is no sharing of personal information between the Secure Channel and CCRA.
iii. There is no aggregation of personal information in the Secure Channel, and no central
database of identifying information. The Secure Channel database holds the userid, which the
user selects, and the MBUN, which is not linked to any program identifiers. Any linking is done
within CCRA's legacy database. This means that the certificate cannot be used for data-
matching. Users are also discouraged from using their common names for the userid.
iv. Use of the on-line program is voluntary. Users are informed that they may use other
channels if they wish.
v. The Secure Channel personnel have no access to the users' keys in the Secure Channel
server, since they are doubly-encrypted and can be accessed only by the user. Also, the
recovery secrets, used for key recovery in the event of loss of password, are protected by
hashing. Secure Channel contractors and their personnel are bound contractually to abide by
federal privacy laws and policies.
vi. The Epass program has the requisite privacy, security and legal notices. The privacy
statement gives notices of the authority to collect personal information and the intended uses.
The security statement gives notice of the use of session cookies, and any transaction
monitoring. The user agreement asks for consent to the collection and use of personal
Government On-Line Secure Channel, Build 3 Load 2 Privacy Impact Assessment, June 17, 2002, Gowlings
Consulting Inc. and Deloitte and Touche.
information for the Epass and ACO programs. While such consent is not required under the
Privacy Act, it is a requirement of the GOL CPs.
The Legal Assessment
While the PIA is being conducted, so too is a legal review of the data-flows, system design and
architecture, and the development of the screens, notices and statements.
The legal analysis checks primarily for compliance with applicable laws and polices, but must
also seek to find the appropriate balance between somewhat competing interests, such as
enforceability and user-acceptance.
i. Authority: Section 4 of the Privacy Act prohibits an institution from collecting personal
information unless it is required for purposes of a program or activity of that institution. Here,
there are 2 institutions involved - the ACO program is CCRA's, and the Income Tax Act applies;
the Epass program is the Secure Channel, which contract is under the authority of Public Works
and Government Services Canada, and the information that Secure Channel collects is under
the authority of the Department of Public Works and Government Services Act.
ii. User Agreement: In the annexes to the PKI Policy, there are three model subscriber
agreements for citizens to whom certificates are issued: a long form, a medium-long form, and
a short form. For this project, the instructions were that the user agreement could not take up
more than one screen. That meant retaining only the most essential elements of a PKI user
agreement. It contains:
consent to the collection of personal information. As mentioned, while this is not a
requirement of the Privacy Act, it is a requirement of the GOL CPs, and is a good privacy
the obligation to keep the password and userid private. Without this obligation, the utility
of a digital signature for purposes of attribution and non-repudiation is compromised.
disclaimers of liability. As discussed earlier in this paper, the decision respecting liability
is made by the program manager. The user agreement is an Epass agreement and not
a program one, and so contains only general disclaimers for system failures,
unavailability of the Epass service, or breach by a user of the agreement. Any other
liability or disclaimer clauses are found in the ACO program itself.
the contract is an on-line contract.27 Acceptance is indicated by a "click", and
supplemented at a later stage by having the user digitally sign his shared secrets in
order to link the agreement to an identifiable user. In future models, it is expected that
the user agreement would be digitally signed. Note that the agreement provides for its
amendment by publication of notice on the web-site. The recent case of Kanitz v.
Rogers Cable Inc.,28 gives some assurance of the efficacy of that process.
iii. Authentication: Authentication for purposes of issuing the Epass is done by CCRA by
verifying income tax-related secrets against its legacy income tax database. The strength of
that authentication was determined by CCRA to be sufficient, based on a threat-risk
assessment, and in view of other internal processes that it uses to verify the identity and
capacity of a tax-filer. The existence of such shared secrets in itself acts as a screening device,
because it means that CCRA must already have an established relationship with the user. In
See Rudder v. Microsoft Corp.,  O.J. No. 3778; (1999) 2 C.P.R. (4th) 474; and Kanitz v. Rogers Cable Inc.,
 O.J. No. 665.
the future, if an Epass were to be used for programs of other departments, those other
programs might wish to supplement the assurance level by collecting additional information.
iv. Sharing of personal information: Generally, information collected for a program cannot be
used for another program unless authorized by statute, or unless the user consents, except
where the use is considered "consistent" with the purpose for which the information was first
collected. This is not an issue for this project, but may be an issue in future projects where a
certificate could be used for more than one program.
v. Choice of one or more certificates: Again, this is not an issue for this project. In the future,
the principle of choice will give assurance that certificates and MBUNs are not being used for
purposes of data-profiling or matching, and will not, then, suffer from "function-creep".
vi. What information needs to be retained and for how long? Under the Privacy Regulations,29
personal information which is used for the purpose of making an administrative decision must
be retained for two years.
vii. What is "personal information"? What is "personal information" within the meaning of the
Act is not always clear. The Act defines personal information as being information about an
identifiable individual. That definition casts a broad net, including information that may be only
remotely capable of being linked to a person, and which may not, in and of itself, be sensitive
information. The net includes IP addresses, the MBUN and the private keys.
viii. Evidentiary Requirements: There are evidentiary requirements and statutes of limitations
that apply in relation to user agreements. In the model, if the user is issued an Epass, then he
must have assented to the user agreement that was on the screen at the date the Epass was
issued. In other words, the only way to get an Epass is by assenting to the user agreement. Is
it sufficient, then, to prove the contract with evidence of what version was on-line at that time?
or must the entire user agreement, somehow linked to the identity of the signatory, be retained
in a database for the requisite period of time? There is no case law yet on point, and the
statutes give little guidance. The Canada Evidence Act30 and provisions of Part 2 of the
Personal Information Protection and Electronic Documents Act31 seem to suggest that the
traditional record-retention rules persist; that the data must be readable and perceivable to a
user at any time. Is it then sufficient that the user be able to obtain the version of agreement
from a database somewhere? or must he be able to download or view the version that he
accepted from the Epass website? There is some indication that the courts will continue to
accept functional equivalents in an electronic environment, so that it may not be necessary to
retain all the data of the user agreement.
The Policy Assessment
In addition to the privacy and legal assessments, there are a number of other Government
policies that must be complied with. For example, there is the Common Look and Feel for the
Internet: Standards and Guidelines"32. This Policy mandates a "common look and feel" for GoC
web-sites. It contains standards which are mandatory, and guidelines which are not, and is
meant to achieve consistency in the appearance and substance of GoC web-sites.
Included as mandatory standards are a Privacy Notice and a Privacy Notice Statement. The
general Privacy Notice usually appears at the bottom of most gc.ca web-sites. It provides for
notice of the collection of personal information; a description of personal information which is
collected automatically, if any; it must disclose the purpose of the collection, and identify the
information bank where the information is retained.
At any point where users are given the opportunity to voluntarily provide personal information,
the department must have a Privacy Notice Statement. This Statement has to be located next
to the text and gives notice of the use to which the information will be put, and notice of any
consistent or other uses. Users must also be made aware of the right to access their own
The Privacy Notice must also include a statement concerning whether cookies are used and, if
so, whether they collect any personal information, such as IP addresses. The Notice must also
describe the security practises of the site, such as virus checking or intrusion monitoring.
The Federal Identity Program Policy33 establishes rules for departments to identify programs
and services as those of the Government of Canada in a consistent manner, so that a federal
Government web-site will be easily recognizable as such. It governs the use, for example, of
the Canada flag symbol and the Canada wordmark.
The Secure Channel and Epass platforms are being designed with the expectation that much of
the architecture and processes can be used for additional PKI-enabled programs. Because
each program has its own statutory requirements, including obligations with respect to the
treatment of personal information, the re-usability of the platform will have to be examined on a
program-by-program basis. At a minimum, it is hoped that certificates will be able to be used for
more than one program if a citizen wishes to do so. As each program is added on, the same
kinds of privacy, legal and policy reviews described above will have to be done.
B. Personal Information Protection and Electronic Documents Act Update
Part 2 of the Personal Information Protection and Electronic Documents Act is the "electronic
documents" part. It is important to note that it does not have the same application as Part 1 -
being the "personal information protection" part. Part 2, in brief, provides a tool by which federal
statutes and regulations containing certain impediments to going on-line, may be amended. It is
not a mandatory statute - departments may choose to opt in to PIPEDA by placing the offending
provisions in the Schedules to the Act, and by enacting regulations to tailor the technology and
electronic equivalents to their own programs and services.
At the date of writing there is nothing in Schedules 2 and 3. While it is not possible to predict
how many departments will actually "opt in", there are some possible explanations for why none
have done so to date.
For one thing, departmental funding has obliged them to prioritize. The emphasis so far has
been to put information on-line, rather than enabling electronic transactions and services. For
another, the acquisition of the requisite technologies by the GoC is relatively recent for those
programs requiring PKI and digital signatures. Some departments are able to rely on section 33
of PIPEDA which clarifies that a general power to deal with documents which does not specify
paper requirements includes the power to use electronic means. Some are able to rely on, for
example, subsection 35(4), which clarifies that the authority to prescribe a form includes the
authority to prescribe an electronic form. Others who are amending their own legislation for
some other reason are able to take advantage of that opportunity to remove impediments to
electronic media. Finally, some departments are choosing to wait for the promulgation of
regulations defining a "secure electronic signature" for purposes of section 4834 of PIPEDA.
At the time of writing, Treasury Board Secretariat is preparing to submit draft regulations to the
Treasury Board for approval for pre-publication in Part 1 of the Canada Gazette. It is hoped that
at the date of the conference, we will be better able to advise of an estimated date for that pre-
In the meantime, there is a program that cannot wait for the regulations. The Federal Real
Property and Federal Immovables Act35, (FRPA) has several requirements for the form and
content of instruments dealing with interests in federally-owned real property. In Ottawa, the
land registration system is now entirely electronic. Instruments are created, transmitted, signed
and registered in electronic form, using proprietary software sold by Teranet. The electronic
See footnote 7.
form of deed prescribed by the Province of Ontario does not fulfill the writing and signing
requirements of FRPA. Accordingly, it is the intention to opt in to PIPEDA as soon as possible.
FRPA may, then, become the first statute to be listed in the Schedules to PIPEDA.
C. On-Line Collaborations with the GoC
The GOL strategy involves a transformation of Government services and programs. It is not
intended to simply replicate paper processes in an electronic media. Rather, the federal
Government is seeking to transform services, following an approach that is "citizen-centric", or
oriented to meeting client priorities, and easy to use.
In the early stages of GOL, this meant starting to group governmental information by subject-
matter rather than by agency. This type of approach is reflected in the blue pages of your
phone book. In GOL, it is illustrated by the Canada Site, found at http://canada.gc.ca. There,
you will see the three "gateways", under the headings of "Services for Canadians; Services for
Non-Canadians; and Services for Canadian Business".
The notions of "clusters", "portals", and "gateways" are all designed to group together various
pieces of federal Government information or services. Programs and services offered within a
department may be consolidated or coordinated. Taking that one step further, programs and
services offered by different departments may be "clustered" together. This "clustering" within
the GoC alone raises legal challenges. Departmental boundaries, program boundaries, and
ministerial mandates are crossed in the face of a legislative framework that creates and
maintains silos. Questions of governance, ministerial accountability, authority, funding, privacy
and confidentiality, and security all arise.
The federal Government is now embarking on the third stage of GOL. This stage takes the
collaborative approach to its natural evolution, expanding it to include other levels of Canadian
government, both provincial/territorial and municipal, governments of other states, and non-
The federal Government's interest in collaborations is not by any means restricted to the context
of the Internet. In the paper entitled "The Federal Government as 'Partner': Six Steps to a
Successful Collaboration", 36 dated November 1995, Appendix 11 contains a bibliography with
some 30 references to alternative means of service-delivery and program-administration, with
some material dating back to 1989.
More recently, Treasury Board approved a new Policy on Alternative Service Delivery37. Annex
D outlines the context for ASD:
The government is constantly reviewing its programs and services in order to identify
opportunities for innovative ways of improving services to Canadians. Fundamental to this
process is a commitment to a citizen centred approach, public service values, managing for
results and ensuring value for money. These four commitments act both as drivers for innovative
organizational arrangements for service delivery and as constraints and tests to ensure that such
arrangements are in the public interest and contribute to good governance.
Furthermore, departments "should continually assess their programs and services to identify
opportunities for improving service to Canadians, including opportunities for alternative or
innovative organizational arrangements to improve organizational performance, cost-
effectiveness and the delivery of services to Canadians."38
This exhortation, coupled with the GOL strategy for service-transformation, and with limited
GOL funding, has led departments to consider a number of different kinds of collaborations for
e-services and programs. In and of themselves, collaborative arrangements are constrained by
a number of laws and policies, many of which are well-understood in the non-Internet context.
However, departments are just starting to develop collaborative arrangements for the Internet
and issues are just starting to emerge.
Some Types of Internet Collaborations
At one extreme are those collaborations that involve creating some new organization or
corporation, and which may require legislation.39
At the other end are the more 'local' collaborations, which may involve a contractual
arrangement, a procurement of goods and services, or contracting out of programs and
They can include arrangements designed to allow the participation of non-governmental
agencies or the private sector in the development of government policies and programs40; or
they may involve contributions or sharing of resources amongst different parties.
More particularly, in relation to the Internet, some arrangements are starting to take shape:
government-hosted web-sites with content provided by others
contracts for the provision of content or the development of some application, or the
provision of these things in exchange for a link
Ibid., p. 4.
Ibid., Annex A.
For example, there is the GOL Advisory Panel, mandated to provide advice and recommendations to the President
of the Treasury Board with respect to GOL matters. See: http://www.gol-ged.gc.ca/pnl-grp/index_e.asp
Applicable laws and policies
There is a plethora of Government policies dealing with collaborations with the GoC. The
following are some of them.
1. The Financial Administration Act 41 prescribes and governs the funding arrangements that
the GOC can enter into. For example, where it is proposed that the Government hold a
membership interest in even a non-profit corporation, section 90 of the FAA provides that,
subject to exceptions, legislation is required.
2. The Official Languages Act42 and Official Languages (Communications with and Services to
the Public) Regulations43, govern the use of French and English in communications. The
Treasury Board Policy on using the Official Languages on Electronic Networks44 provides
guidance on the application of the OLA in the context of the Internet. In particular, it addresses
language requirements in hyperlinks, and in third-party content hosted on GoC web-sites.45
3. The Contracting Policy46, the Interim Policy on Indemnities in Contracting,47 and the
Government Contract Regulations48 must be referred to when procuring goods or services.
Note that the ability of the Crown to indemnify others, whether directly or indirectly, for losses
not caused by the Crown is limited.
4. The Communications Policy of the Government of Canada,49 was published in April of this
year. The policy deals with communications across the GoC, covering subjects such as the
provision of information to the public, the right of the public to communicate with their
government, the provision of information services in a "citizen-centred and client-focused
manner" and the coordination of communications within the GoC.
Section 18 deals with the "Internet and Electronic Communication". Section 23 prohibits
publication of private sector advertisements and requires departments to avoid the appearance
of endorsing or giving an unfair competitive advantage to any private sector entity.
Ibid. For example, s. 6.1.1(a) "If an office designated as bilingual sets up a contract or agreement for a third party
to provide communications to the public on an electronic network on its behalf, the contract or agreement must state
that the information must be posted in both official languages." For hyperlinks, see s. 6.3 on page 5: "Hyperlinks on
a site of an office designated s bilingual for service to the public that give access to texts found on sites of other
offices do not automatically create official languages obligations for the latter. However, if these hyperlinks refer to
texts that are clearly intended as part of the service the bilingual office is required to provide to the public these texts
must be available in the official language of the user."
Section 24 deals specifically with "Partnering and Collaborative Arrangements" from a
communications perspective. Collaborative arrangements must establish the communications
roles of the parties, including official languages requirements, branding, and promotional
activities. The contributions of all parties must be acknowledged, and corporate names or logos
may be used for that purpose (but not for the purpose of advertising products or services). The
Federal Identity Program applies and Government departments must use the Canada
5. The Policy on Alternative Service Delivery50 was approved in April, 2002. Section 2 of the
Policy describes ASD as being the "pursuit of new and appropriate organizational forms and
arrangements, including partnerships with other levels of government and other sectors, in order
to improve the delivery of programs and services."
The policy contemplates the establishment of appropriate forms of organization and
"collaborative arrangements", such as "single windows", co-locations, or clustering of services
to citizens. It states, in section 4, that "[i]nnovative organizational forms and arrangements can
play an important role in improving performance. Alternative service delivery arrangements
must deliver sustainable results for Canadians and reflect the public interest."
Departments are required to look for opportunities for collaborations. However, for an ASD
arrangement to be approved, it must meet some criteria: It must reflect Canada's official
languages; it must ensure appropriate ministerial accountability; it must meet a "Public Interest
Test" described in Annex B; it must address client and citizen satisfaction and service
improvement; and it should contribute to the department's mandate.
6. The ASD Policy is accompanied by the Alternative Service Delivery Policy Guide.51
It contains guidelines and checklists to define the collaboration process.
7. "The Federal Government as 'Partner': Six Steps to Successful Collaboration"52, November
1995, offers guidance to public sector managers and to outside parties who are contemplating a
collaboration with the Government. While some of its content may appear to be obvious or
common sense, it may be new information to web-site managers or system architects who may
be involved for the first time in designing collaborations.
As the title suggests, it sets out six steps:
i. assess the arrangement for propriety, value to Canadians, accountability of the
parties, and the ability to provide sound management;
ii. determine the nature of the relationship and the funding. A true "partnership", for
example, is rare, and may require legislation;
iii. internal consultations with legal and financial specialists;
iv. ensuring ministerial accountability and third party accountability;
v. a planning checklist that will provide guidance for the eventual contract or
memorandum of understanding;
vi. management techniques.
The document describes some funding mechanisms, including grants or contributions53, cost-
sharing agreements, and sponsorship arrangements where no money changes hands, joint
project agreements, etc.
It also highlights some legal, financial and contracting issues. For example, in contracting, the
Financial Administration Act prescribes that payment under contracts is subject to there being
an appropriation of funds. Also, the federal Government is subject to internal contract
regulations under the FAA, as well as to trade agreement obligations in its procurements.
Donations and sponsorships are funding options for certain collaborations, either from or by the
Government, but the Government may not be seen to be endorsing any particular entity or
product. Rights to intellectual property are discussed in the Policy on Title to Intellectual
Property arising under Crown Procurement Contracts.54 Generally, the Crown does grant
ownership of intellectual property outside of the Government to encourage its full commercial
exploitation, but often reserves to itself the right to use it for its own purposes.
It notes that the Crown is its own insurance underwriter, and does not purchase insurance
coverage. At the same time, it cannot expose itself to liability for the consequences of actions of
Deputy heads of departments are responsible for the security of their departments.55 This
includes ensuring the protection of sensitive and personal information and assets, and
subjecting contractors to the requirements of the Privacy Act.
8. The Government of Canada Internet Guide56 is a lengthy and comprehensive document
intended to provide guidance for web-site design and maintenance. It touches on some matters
that are pertinent to "collaborations".
For example, it discusses the use of hyperlinks in connection with on-line publishing, as well as
the need to maintain the links. It sets out criteria for adding content to GoC web-sites, including
ensuring that the content is relevant to the goals of the organization. Chapter 4 - "Other
Considerations"57 in particular discusses collaborative arrangements, including issues of
branding, reciprocal linking practices, and advertising.
9. The Common Look and Feel: Standards and Guidelines58 has a section relating to web-sites
that reflect collaborative arrangements. It sets out rules for branding through the use of the
Canada wordmark or flag symbol. Even if a collaborative site is not a gc.ca domain, standards
relating to accessibility, collaborative arrangements, notices and official languages apply to the
GoC web-sites cannot display third-party icons or logos that represent the products and
services of private enterprises to ensure that there is no creation of unfair competitive
advantage through the appearance of an endorsement.
See Policy on Transfer Payments, (repayable contributions and conditional grants) at http://www.tbs-
Government Security Policy, footnote 11.
See footnote 32.
Liability disclaimers are suggested for web-sites that host information provided by third parties.
For some hyperlinks, exit notices may also be used to ensure that the user is
aware that he is leaving the GoC site. Departments may wish to use disclaimers for the content
of those linked sites.
Official languages requirements apply to content posted on collaborative sites, and the Common
Look and Feel guidelines elaborate on these obligations.
10. The Federal Identity Program Policy of 1990,59 requires that federal institutions identify
themselves in accordance with corporate standards for the Government of Canada. It is
intended to make GoC premises, buildings and web-sites recognizable as being those of the
GoC. It covers the use of federal symbols such as the Coat of Arms, the Canada wordmark and
the flag symbol. It also, in Appendix C, lists the "applied titles" of federal organizations. An
"applied title" may be different from the legal title of an organization. For example, the
Department of Transport's applied title is "Transport Canada".
In the "Additional Requirements" at the end of the Policy is the requirement that the GoC identity
requirements be part of any collaborative arrangement with the private sector.
These policies all offer general guidance, but nonetheless, as departments become more
creative and anxious to find innovative ways of improving services to citizens at low cost, some
issues start to appear with some regularity.
One is simply the use or misuse of the word "partner". In the Alternative Service Delivery
Policy, it is made clear that it is not being used in the legal sense of the word. The use of true
"partnerships" by the GoC is rare, because of the liability implications and the commercial
nature of such arrangements. Nevertheless, it is not rare to see collaborative arrangements
describe the relationship as one of 'partnership'. Legal counsel, given an opportunity, will
discourage this, or will define the term so that it not have the legal connotation.60
Another relates to linking practises, and the Treasury Board Secretariat is presently working on
linking practise guidelines.61 The Government may agree to link to a particular site in return for
some product or service. The ability to agree to such an arrangement will depend on its exact
structure, but generally, the Crown must not
See footnote 33.
See Central Mortgage & Housing Corp. v. Graham (N.S. S.C.), (1973) 43 D.L.R. (3d) 686, where the court found a
joint venture and held CMHC liable for construction defects.
For an example of a hyperlinking policy, see http://www.jobsetc.ca/jobs.jsp?highlighted_category_id=1&lang=e
appear to be endorsing a product or service of a commercial entity so as to avoid conferring an
unfair advantage. Accordingly, departments are advised not to give any rights of exclusivity.
Opportunities for links to others would be given equal consideration.
If the arrangement is in reality a procurement, then the procurement rules would apply, including
the Government Contract Regulations, the Contracting Policy, and applicable trade laws.
The Government has to be careful about what information it links to, and how it represents the
linked information. While the risk of being found liable for negligent misrepresentation based on
information contained in the linked-to site is low, it is worthwhile to take precautions. The policy
of the GoC is to stand behind its own information, but not to accept responsibility for third party
information on its web-sites. Similar considerations apply to linking practises. Departments are
encouraged to make it clear when a user is leaving a GoC web-site, and to take care not to be
perceived as endorsing the quality or accuracy of information on a linked site. Exit notices can
be valuable tools, but may become a nuisance if over-used.
There is no "Government On-Line Act" of Canada, and GOL is being shaped in the context of
the existing framework of laws, policies and technology. This may sometimes mean that
creative and innovative ways of using existing technology, and new technologies, need to be
designed to obtain a more comfortable "fit".
We know that clusters and groupings present particular challenges when they entail services
that may need some personal information. Similarly, programs that can facilitate citizen access
to services, such as automatic form-fill, also need to be carefully crafted. Privacy laws and
policies, as well as departmental statutes, place constraints on how and when a portal or
gateway can collect information that is "personal" within the meaning of the Privacy Act, even if
not sensitive. Collaborative web-sites will have to take care to respect privacy principles and
silos, by ensuring that personal information is only collected when there is a program that needs
it, and that only the program that needs it has access to it.
We also know that close co-operation amongst departments and program managers is essential
for the interoperation of technology and policies.
The end result, and the objective of "e-government", is to give citizens more options for
obtaining information and services from their government, in ways that are transparent to them,
easy to use, and easy to find, regardless of the channel that they choose.
Accenture's third annual survey of eGovernment Leadership - Realizing the vision, gives
Canada a top rating as an "innovative" and "mature" leader in attaining that objective,
concluding as follows:
The leaders remain unchanged. Canada has maintained its position in first place, despite Singapore closing
the gap, and continues to advance toward its stated goal of providing Canadians with electronic access to all
federal programs and services by 2004.
The federal Government is moving steadily towards its third stage objective, by first building the
platform and winning citizen trust, then by adding incrementally to that platform, first within the
See Accenture Report, Executive summary, at
GoC, and ultimately, moving towards collaborations with other governments and the private
D. Other - a Few Loose Threads
i. The Government On-Line Procurement Strategy - "The Supply Arrangement".63 The GOL
Procurement Office is located in PWGSC. The "Supply Arrangement" method of procurement
was adopted for GOL. It is a streamlined approach to procurement that is intended to improve
access to the goods and services necessary for GOL.
Requests for Supply Arrangements were issued on the MERX system, offers received and
evaluated, and supply arrangements were issued to qualified suppliers.
This allows departments to access these pre-approved suppliers through a competitive system,
and to enter into contracts within their financial authorities.
ii. The Government On-Line Checklist of Legal Issues64 on the Department of Justice web-site,
contains a number of links to statutes and policies, as well as to some case law of significance
to a governmental legal practice.
iii. Retention of Digitally Signed or Encrypted Documents.
The National Archives of Canada published Guidelines for Records Created under a
Public Key Infrastructure using Encryption and Digital Signatures65. If an electronic
record is deleted or cannot be decrypted, then there may be a de facto disposal of
records contrary to subsection 5(1) of the National Archives of Canada Act. The policy
adopted by the National Archives is not to preserve the encrypted form of records in
electronic form; and not to accept any encrypted records. A department will have to
supply the records in de-crypted form. They may, if they choose, add a notation
regarding the encryption history of a document.
The ITS and PKI Sector of the Treasury Board Secretariat has published a paper entitled
Information Management - PKI Guidance, dated March 31, 2002.66 It discusses three
options for departments to manage encrypted and digitally signed information:
o establish processes and policies so that only documents that have been properly
validated will be used or retained. Digital signatures and encryption are used
only for purposes of transmission, and the transmission information is not
o to the above option, add supplementary information about the context of the
creation and validation of the records. Context information includes the name of
the key-holder, the validity period of the digital certificate, the name of the CA
that issued it, and the date and time that the record was validated.
o use the information and retain a copy in digitally signed but decrypted format.
Can be obtained from the National Archives of Canada at www.archives.ca
ACO Address Change On-Line
ASD Alternative Service Delivery
CA Certification Authority
CCF Canadian Central Facility
CCRA Canada Customs and Revenue Agency
CIO Chief Information Officer
CPs Certificate Policies
CPS Certification Practice Statement
FAA Financial Administration Act
FRPA Federal Real Property and Federal Immovables Act
GoC Government of Canada
GOL Government On-Line
IP Internet Protocol
MOU Memorandum of Understanding
MBUN Meaningless but Unique Number
OLA Official Languages Act
OPP Ontario Provincial Police
PIA Privacy Impact Assessment
PIPEDA Personal Information Protection and Electronic Documents Act
PKI Public Key Infrastructure
PMA Policy Management Authority
PWGSC Public Works and Government Services Canada
SSL Secure Socket Layer
U.S.F.B.C.A. United States Federal Bridge Certification Authority
Introduction to Public Key Infrastructures
Public key infrastructures support the use of applications that encrypt data and that use digital
signatures. Public key infrastructures are based on principles associated with public key
Public key cryptography encrypts information by using two mathematically related keys: one is
kept private; the other is made public. The private key cannot be determined from the public
key. An individual who wants, for example, to send a message uses the public key of the
recipient to encrypt the message. The recipient uses his or her private key to decrypt the
message. The sender therefore knows that only the intended recipient can read the message.
Public key cryptography can also be used to create digital signatures. A digital signature is
made when a mathematical function produces a value dependent on the content(s) of a
message, which is then attached to the message and encrypted using the sender's private key.
The recipient of the message can decrypt the digital signature using the sender's public key.
The recipient then passes the message through the same mathematical function to produce a
second summary of the message. If the digital signature can be decrypted and the summaries
are identical, then the recipient is assured of both the sender's identity and the integrity of the
message, i.e., the message was not altered from the moment it was digitally signed. Because
the digital signature of a message depends on the private key used to produce it, the sender's
ability to repudiate the message is reduced.
A Certification Authority is a third party trusted to associate a public and private key pair with a
particular individual or entity. It identifies the individual or entity which is to receive a key pair;
issues keys; revokes keys when a private key may have been lost, stolen or otherwise made
public; and provides notice as to those key pairs which have been revoked. It is possible that an
individual, instead of a Certification Authority, may generate his or her own keys. A
public/private key pair is a set of two numbers. The electronic document or record which links
the key pair to an individual or entity is a digital certificate issued by a Certification Authority.
The digital certificate, which has been digitally signed by the Certification Authority, contains the
public key and serves as evidence that the individual identified in the certificate holds the
corresponding private key.
The Government of Canada Public Key Infrastructure will operate with certificates at four levels
of assurance: rudimentary, basic, medium and high. The greater the assurance required, the
greater the degree of effort that is taken by the Certification Authority to confirm the identity of
the individual named in a certificate and the greater the security in place to protect the
Certification Authority. Departments will operate at the level or levels of assurance based on
their business, security and legal requirements.
Two or more Certification Authorities linked together by cross-certification, form a public key
infrastructure. A public key infrastructure is relevant to electronic commerce or electronic service
delivery in that it can provide security services for electronic communications and the electronic
exchange of information between parties, including those who do not have a previously
established relationship. Encrypting data or "affixing" a digital signature is a simple process for
the user, done automatically by clicking on an icon in Public Key Infrastructure-"enabled"
software. The process is transparent to the user but usually the software will allow for the visual
inspection of the information in the certificate.
Introduction to Certificate Policies and Certification Practice Statements
Certificate Policies and related Certification Practice Statements play an important role in the
operation of a public key infrastructure. The following briefly describes these instruments and
why they are needed.
A Certificate Policy is a named set of rules that indicates the applicability of a certificate to a
particular community and/or class of application with common security requirements. It indicates
whether or not the public key certificate in question is suitable for a particular application or
purpose. A Certification Authority may adopt more than one Certificate Policy, but in each case
the document serves as the cornerstone of establishing trust in a public key certificate, and it
constitutes a basis for cross-certification.
The act of issuing a certificate is a Certification Authority's representation to a certificate user
that a particular public key is bound to an entity whose identity has been authenticated
according to rules established by a Certificate Policy. When Certification Authorities issue cross-
certificates, they establish a trust relationship in which each Certification Authority recognizes
one or more Certificate Policies of the other. This recognition permits those who wish to validate
certificates to do so. In the Government of Canada Public Key Infrastructure, these trust
relationships, i.e. cross-certifications, are established through the Canadian Central Facility.
This is done deliberately to simplify cross-certification within the Government of Canada Public
Key Infrastructure. Cross-certification between Certification Authorities can also be established
directly. An example of this would be between the Canadian Central Facility and an external
Certification Practice Statements
A Certification Practice Statement is more detailed than a Certificate Policy. It is a
comprehensive description of how all of the policy requirements stated in the Certificate Policy
will be implemented and maintained by a Certification Authority.
A Certification Authority with a single Certification Practice Statement can support more than
one confidentiality Certificate Policy and more than one digital signature Certificate Policy. A
number of Certification Authorities that do not have identical Certification Practice Statements
may support the same Certificate Policy.
ePass Issuance Process…
1. Citizen browsing 2. “Shared secret” identity-proofing done
CCRA website is by the CCRA/ACO with rigor meeting 3. Shared secrets (includes web access
provided option to its business and security needs. code) verified by the CCRA/ACO
enroll for ACO against its records.
service and obtain a
Citizen is seamlessly passed to the ePASS central key management system
4a.Citizen chooses 5. For recovery purposes, 6. Certificate (ePass) is issued and
a User ID and citizen selects a number of downloaded to citizen’s browser.
password – the pre-determined questions
User ID must be and provides answers.
should not be
the citizen’s 4b. Encryption and signing Citizen passed back to program area
actual name. keys are generated and 7. CCRA/ACO 8. MBUN-Identifier
stored in a profile that is completes bindings remain only
protected with double enrollment process with the CCRA/ACO
encryption – accessible by associating – in an encrypted
only to the citizen. the MBUN with database.
From www.tbs-sct.gc.ca/pki-icp/gocpki/frame/frametb-eng.asp 12 October 2008
…for CCRA’s Address Change Online (ACO) service