1
Implementing Public Key Infrastructure in Government
Report from an international meeting In Oslo, Norway, May 2000
Table of Contents
Foreword and acknowledgements*
1. Introduction, purpose of the meeting*
2. Round table reports*
2.1 Canada*
2.2 Japan*
2.3 Ireland*
2.4 The Netherlands*
2.5 United Kingdom*
2.6 United States*
2.7 Finland*
2.8 Sweden*
2.9 Norway*
3. Discussion – key points*
3.1 Internally vs externally manged PKI*
3.2 Trust levels*
3.3 EESSI and global PKI interoperability*
3.4 Interoperability issues*
4. Summary and conclusions*
Annex I
List of participants
Annex II
Agenda of the meeting
Annex III
Opening key note speech by political adviser til the Minister of Government Administration, Ms. Hilde
N. Thorkildsen
Annex IV
Pictures from the meeting
Annex V
Glossary
Foreword and acknowledgements
This report is a summary of proceedings from an international meeting convened in Oslo on May 2526th 2000 to discuss in-depth issues related to implementation of PKI in government.
The meeting was a follow-up to the work initiated in 1999 by the International Council of IT in Public
Administrations (ICA) in a separate Study Group for PKI. The report from this work was published in
February 2000 and is available on ICA web site. The report gives an overall picture of strategies for
PKI in government pursued in various countries that participated in the ICA survey. For information on
strategic framework we therefore refer to the ICA Study Group report.
This report discusses some in-depth PKI-related issues that were considered important to follow up by
the informal group, consisting of representatives of governments from Canada, Japan, United States,
United Kingdom, Ireland, the Netherlands, Sweden, Finland and Norway, that met in Oslo.
The views expressed here are conveyed as a record of discussions at the meeting and do not necessarily
represent official policy of the respective governments.
The report has been edited by Katarina de Brisis, Norway. The list of participants that contributed at
the meeting is included in Annex I. We would like to thank all the participants for their contributions to
this publication. Special thanks to Mr Richard Guida for permission to use his own meeting
memorandum as a basis for this report. We also thank Ms Sue Bryant and Mr Jan Timmermans for the
use of photographs they have taken during the Oslo meeting.
Additional material from the meeting, such as slide presentations and various policy documents, as
well as the electronic version of this report may be found at the address
http://forvaltningsnett.dep.no/ftp/pki.
Oslo, 18th of August 2000
2
1 Introduction, purpose of the meeting
PKI (Public Key Infrastructure) has been recognized as a key element for supporting secure and
reliable electronic communications in the framework of e-government and e-service delivery. Several
countries have implemented, or are in the process of implementing, PKI for internal purposes. Several
pilot projects for PKI-supported electronic services are being conducted with the view to providing egovernment within the coming years.
In the framework of electronic government strategies pursued by all of the attending countries, PKI
might be seen as a prerequisite for implementing electronic support for internal administrative
procedures as well as a prerequisite for electronic service delivery to citizens and businesses.
PKI seems to offer a coherent and efficient security solution to authentication and other security
challenges when communicating electronically on the Internet. However, in order to fulfill its promise,
PKI implementation needs to be coordinated on a national, regional and global level.
The complex nature of PKI and rapid technology development pace render it quite difficult for
government policy makers to make right decisions about its implementation and use.
In order to establish a national policy on the management of PKI in the government many issues need
to be addressed, such as:
Certificate policies and trust levels
Cross certification methodology
Cross-border interoperability with other governments
Public access issues related to the use of PKI for e-services to citizens and businesses
Information management issues related to digitally signed documents and retention over time
Interoperability testing of PKIs, certificates, certificate directories
Naming and identification of subjects
Rules for the use of PKI for confidentiality purposes
Technical specifications for government PKI – standards
Market policies (government use of the PKI-market)
Management of a large scale rollout of PKI.
The purpose of the meeting was to exchange views and experiences on the policies for, implementation
and use of Public Key Infrastructure in government, both internally and for secure communications
with citizens, companies etc. when delivering services electronically. Some common problems to
implementing PKI were discussed and views exchanged on how to solve them.
2 Round table reports
2.1 Canada
Canada has been a pioneering country as far as PKI in government is concerned. A strategic decision to
develop a government PKI was made in 1993 when the government outlined its requirements for
secure transmission of electronic transactions. In 2000, PKI supports the government direction to
become a model user of information technology and the internet by providing for confidentiality and
privacy.
Key drivers for the use of PKI include the government’s decision to use the Internet for electronic
service delivery; the Government On Line (GOL) initiative; and the development of a common
infrastructure for government departments. Under the GOL initiative government departments are to
have all key services on line by 2004. The Canadian provinces are also looking at a PKI, with many
involved in the development of similar initiatives. PEI, one of the smallest provinces, has implemented
a digital signatures for billing purposes in the health care sector.
The management of PKI policy is anchored at Treasury Board Secretariat. A policy framework has
been developed and includes the Management of PKI in the Government of Canada; the Model
Certificate Policy; and the Cross-Certification Methodology. The policy framework supports another
key government policy, that of Electronic Authorisation and Authentication.
3
The Management of PKI in the Government of Canada policy requires departments to:
establish responsibility centres
cross-certify with the CCF
implement an employee use policy
establish use agreements with non-employees
establish a repository for certificates
comply with key back-up policy as set out
establish liability limits and agree to a mechanism to allocate financial responsibility.
The policy affects only departments that issue digital certificates ( or have them issued on their behalf).
Departments can outsource the CA function but always remain the responsibility centre.
The policy also indicates responsibilities: TBS is the policy arm; Communications Security
Establishment is the home to the Canadian Central Facility( the bridge connecting government
certification authorities and portal for connection to external CAs); and Government
Telecommunications and Informatics Services is responsible for the X500 directory.
The Policy Management Authority ( a senior interdepartmental committee )is responsible to the
Secretary, Treasury Board, for the direction and management of the Government of Canada Public Key
Infrastructure. It makes recommendations to the Secretary, Treasury Board, with respect to
membership in the Government of Canada Public Key Infrastructure and cross-certification.
The GOC Certificate Policy was developed as a model policy for departments and is based on the
PKIX framework. The standard used for certificates is X.509v3 and the directory standard is X500.
Standards use is key to interoperability; the various ways that standards can be profiled is of concern.
Procedures and criteria for cross certification with the Canadian Central Facility of the Government of
Canada PKI have been developed. The Policy Management Authority is responsible for
recommending, to the Secretary of the Treasury Board, the approval or rejection of requests for crosscertification. For cross certifications internal to the federal community, the Government of Canada PKI
Management Policy requires departments to be members of the GOC PKI, and to sign a crosscertification arrangement formally describing the terms and conditions of the cross-certification. Crosscertifications with the private sector or with certification authorities not part of the GOC PKI require
the implementation of formal cross-certification arrangements between the GOC and the external
entity.
To date 2 cross certifications have been completed with an additional 6 in process. Cross certification is
key activity which requires policy mapping and requires meticulous effort.
The government encourages other departments and the private sector to adopt the model certificate
policy, in order to facilitate interoperability. The GOC certificate policy supports 2 key pairs (digital
signature and confidentiality) and four levels of assurance(rudimentary, basic, medium and high). In all
there are eight individual certificate policies. Confidentiality keys for public servants are backed up in
the event of key loss or destruction. The digital signature key is never backed up. This applies to
government employees only.
There is no proposed regulation of certification authorities outside of the federal government being
planned.
The Government of Canada has been implementing projects using PKI for 2 years. Key
implementations form part of the Pathfinder Program and include:
Customs Internet Gateway Project (CCRA)
Business Registration Internet Pilot (CCRA)
New Payroll Savings - Secure Website (Bank of Canada)
Internet Auction of Radio Licenses (Industry Canada) – raised 800 mill. C $
Canada Education Savings Grants (Human Resources Dep. Canada)
Labour Market Development Agreements (HRDC) – access to central government databases
Secure Electronic Service Delivery (HC)
Network Security Strategy (INAC)
4
Record of Employment on Web Pilot (HRDC)
Secure Messaging Pilot (GTIS/TBS) – this project has been run in 20 departments, with some 200
users, covering documents with status lower than Classified; PKI has worked well, but integration with
various e-mail systems was a challenge. Special problems with Entrust software included resigning and
multiple signatures. The certificates used were for authentication, and not non-repudiation. One
important lesson learned from the project was the need to "visualise" the digital signature, i.e. give the
user the appropriate "look-and-feel" when digitally signing documents.
Large Value Transfer System (CPA)
Investment Review (IC)
Spectrum Radio Licensing (IC)
Secure Applications and Key Management Services (GTIS)
Secure Remote Access (GTIS)
Electronic Regulatory Filing (NEB)
Travel Management System (Statistics Canada)
The lessons learned to date from PKI implementation in the Canadian government can be summarised
into the following points:
the introduction of PKI must be based on real business needs
it is necessary to carry out an effective risk and threat analysis
security issues must be given priority
PKI implementation needs to be a collaborative effort
information and awareness of PKI are important parts of the process.
The Government On-Line initiative provides new challenges for PKI: how to deliver secure electronic
services to business and citizens; how to retain digitally signed electronic documents; and how best to
ensure awareness of PKI and related issues.
The use of PKI within government is a given. PKI is also established in the business-to-government
transactions. The citizen-to-government communication, however, poses new challenges, among them
various PKI-vendors and enrolment process. A strategy for PKI-enabled citizen access is being
developed, based on government-issued plug-in for Internet browsers, secure enrolment process with
minimum disadvantages for personal data protection and secure key protection devices (tokens). This
strategy will be further developed and implemented towards the goal date of 2004, by which 100% of
key government services are expected to be online.
An authentication framework for e-services does not preclude the use of PIN-based authentication and
SSL-based secure transactions, but these solutions are meant to support "one-time" transactions and not
multiple filing of information with the government.
Retention of electronic records requires more guidance. Electronic filing systems are unable to store
"Entrust-documents" (Entrust-signed records). Departmental statutes require some records to be
retained anywhere from 2 to 100 years. For digitally signed, electronic records guidance needs to be
developed. Digital signature keys are changed every two to three years which makes the retention of
keys impractical. Other solutions need to be found. One possibility is the retention of verification data
instead of actual digital signature.
2.2 Japan
The Japanese government had decided to build the foundations of a paperless government by fiscal
year 2003. This involves, a.o. , digitalisation of applications, registrations, and other procedures based
on the "Master Plan for Promoting Government-wide Use of Information Technology" (Cabinet
Decision of December 20th, 1997). These forms, procedures, etc. are to be available on-line using the
Internet.
The individual ministries and agencies are required to draw up and announce Action Plans for
realisation of these goals, indicating time schedules for each year until fiscal year 2003. Each fiscal
year, Action Plans will be followed up by the ministries and agencies and the results announced.
Necessary revisions will also be made.
5
Electronic service delivery from the government to the people is to be supported by a PKIinfrastructure (GPKI). This infrastructure shall enable authentication of applicants and authentication
systems for administrative organs.
It is foreseen that Certification Authorities will be established in each Ministry and Agency. Also, a
Bridge Certification Authority will be developed as a system whereby mutual authentication between
Certification Authorities can be simplified and the applicant can efficiently verify their digital
signatures.
The bridge authority shall be established by the end of fiscal year 2000 (which in Japan covers April
2000 to March 2001) and begin operation in fiscal year 2001. Management and Coordination Agency
under the Prime Minister’s Office has the lead responsibility for this task. Furthermore, each ministry
and agency shall stand up their own CA by fiscal 2003. Ministry of International Trade and Industry,
Ministry of Transport, and Ministry of Posts & Telecommunications will be the pioneering
departments and have their CAs set up by fiscal year 2001. Basic specifications of authentication
system will be compiled by the Inter-Ministerial Council of Government Information Systems by July
2000.
Ministries and agencies will be able to select whatever CA product they desire – there will not be
constraints for what products to select. Each agency’ s CA shall manage the secret keys and
repositories. The Inter-Ministerial Council of Government Information Systems will develop
Government Procurement Principles for utilisation of high level security products, etc. (including CAproducts).
The Japanese government also plans to enact legislation and regulations covering electronic signatures
and certification services during fiscal year 2000. The law on electronic signatures had been already
approved by the parliament and will come into effect in April 2001. The law defines an equivalence
between an electronic signature and handwritten signature or seal impression (the Japanese "hanko").
The lead responsibility for this task lies with Ministry of Posts & Telecommunications, Ministry of
International Trade and Industry and Ministry of Justice.
The Ministry of Justice will develop a "Electronic Certification System Based on Commercial
Registration" during fiscal 2000 and will put it into operation promptly thereafter. This will enable
commercial use of certificates by enterprises. A private sector CA for the public is also envisaged.
There’s also a plan to establish a mechanism for payment over the Internet of fees government agencies
charge for services or products (direct bank to government funds transfers), by fiscal 2003. It is
expected that the private sector will develop commercial PKIs (to service business to citizen and
business to business uses) following the government’s lead.
The government has established a Government PKI Forum which includes private vendors (Entrust,
VeriSign, and Baltimore, a.o.) to provide advice and exchange of views on the technology and
applications.
The government intends to use their bridge CA model not only to effect interoperability among
ministry and agency CAs, but also with external commercial and international CAs including those of
other governments. Details on how the policy and technical interoperability will be accomplished are
now being worked out, but it is clear that cross-certification is the intended mechanism.
The government does not envision licensing or accreditation of commercial CAs, but rather intends to
let the marketplace determine the utility of certificates. The government plans to employ, a.o., DSA,
RSA and ECDSA for digital signatures.
The GPKI CP (Certificate Policy) is currently under development. It has not been decided what levels
of assurancethe policy will support. At present, a single level of assurance is being considered.
2.3 Ireland
The Government of Ireland is focused on electronic service delivery in general, but has not yet decided
on any single authentication technology. The Government’s Action Plan for the Information Society,
6
published in January 1999 recommends a three stranded approach to implementing electronic
government to include:
Electronic information services;
Interactive electronic services (stand-alone); and,
Integrated electronic services.
A dedicated fund of £110m has been established to support the implementation of electronic
government services over the three-year cycle 2000-2002 of the Action Plan. Electronic services will
be delivered around "life events" such as registering a birth, applying for a government grant,
becoming redundant, establishing a company, getting married, and so on.
To support this strategy, an electronic service delivery model based on the concept of an e-Broker
(electronic broker) has been developed and has recently been approved by Government. The e-Broker
is a portal which will provide a single gateway to all electronic services being delivered by
Government. A new cross-departmental organisation called REACH has been set up to implement the
e-Broker and to develop policies on the integration of services, user registration, authentication,
identity and security. REACH will also develop policy on trust levels and possible use of trusted third
parties.
The e-Broker will deliver the user experience in dealing electronically with Government and will in
turn interface to existing and planned applications operated by individual Government Departments
and agencies. It will also provide authentication services to these applications whereby the e-Broker
will vouch for the identity of a user. Access to the e-Broker will be provided through a variety of
channels including dial-up services, WAP, digital TV and one-stop shops. It is intended to ensure a
high quality service by providing a managed dial-up service via an ISP.
The e-Broker will effectively allow government to be viewed as a single virtual enterprise, with a
single access point and single sign-on. It will incorporate a super-registration process allowing citizens
to deliver information about themselves to a PKI-protected "vault" resident on the e-Broker. Ownership
of this information will remain with the user who will decide when and to what electronic service to
release this information. Users could, for example, decide to deliver their digital photograph into the
vault for use in applying for a passport or driving licence.
A PKI is currently being implemented by the Revenue Commissioners to support the Revenue Online
Service (ROS) which is due to be introduced in Autumn 2000. This effectively represents a pilot
implementation of PKI in the context of the Irish Government. The ROS service will in time become
available through the E-Broker and will use the authentication services available there.
The Irish administration employs a single government Intranet. This is a standards based infrastructure
providing inter-departmental e-mail facilities as well as access to common data repositories across
central government. The Intranet has been in operation for several years and provides a sound basis for
the delivery of electronic services and particularly integrated services involving numbers of
departments.
The e-Broker will interface, through the government Intranet, with departmental information systems,
as well as with a central "authentication engine", which among other technologies will also support
PKI. Confidentiality protection will be implemented by encryption solutions which have already been
agreed by Departments.
Once PKI is adopted, it is expected that there will be a single CA serving all government needs, with
one identity certificate issued to each citizen. Role-based certificates will not be issued as such
information is already contained in government databases and could also be made available through the
PKI-protected vaults resident on the e-Broker. Some consideration is also being given to accepting
privately issued credentials (e.g., by a mobile phone or cable TV company). These would of course
have to meet exacting government standards.
Within government, credentials will be issued to support a "government process channel", which will
be used to exchange internal government documents supporting the work of the Cabinet, and also
supporting authenticated e-mail. Credentials (certificates) will mostly be issued at organisational level
7
only and there are no plans at present to issue electronic certificates to individual government workers.
Furthermore, "authenticating engines" on sectoral intranets will serve the needs of internal,
government-wide information exchange.
The use of an intranet may acceptably allow the use of authentication technologies that are weaker than
PKI provides, at least for some applications, but PKI is seen as central technology in delivering
services to users via the PC and mobile phone channels.
2.4 The Netherlands
The Netherlands Government plans to have 25% of public services available on line by 2002. The
framework for electronic government also calls for an improvement of internal government processes.
In order to achieve these goals, confidentiality and authentication issues need to be addressed. An
infrastructure to support that is planned to fall in place by 3Q of 2002. The task force working on this
was established in January 2000. PKI has been selected as the infrastructure to provide authentication
and encryption capabilities for reasons of strength and application interoperability.
The present market situation in the Netherlands is such, however, that there is far more "supply" for
certificates than there is "demand" for them. The government is viewed as a "launching customer,"
playing a major role in getting PKI usage stimulated. There is a need, still being evaluated, to adjust the
laws to provide full legal effect for digital signatures. That will contribute to further uptake of PKI
solutions in the private sector.
The Netherlands is in the process of implementing the European directive on electronic signatures. The
existing voluntary accreditation scheme ttp.nl is viewed as not being sufficient to implement the
directive’s requirement for supervision of CSPs providing qualified certificates. New criteria are being
developed in cooperation between business and governments. There are some doubts in the
government whether the trust level provided by qualified certificates will be sufficient for all
government use. There seems to exist a need to develop additional requirements for CSPs and
electronic signatures that will serve government purposes. The issues between businesses and
businesses and consumers will be left for the market to decide the level of trust needed.
The PKI task force (PKI Overheid) is charged with the short term task to implement a limited PKI in
government by end of 2000. This involves completing a certificate policy with a security level
conforming to the administration needs. The PKI shall be transparent, simple and applicable for all
users. The long term goal is to implement a fully operational PKI by 2002, involving selv-evident use
of digital certificates both for authentication and confidentiality purposes.
The Dutch government’s view is that there should be as few trust levels as possible. Certificate
assurance level (for government employee use) is targeted at meeting 75% of the applications that are
internal to the government and between government and businesses and the public. The remaining 25%
applications are national defense applications that entail classified information. The overall goal is to
have as few levels of assurance as possible, preferably just one. The same type of certificate is
envisaged both for internal and public use. The private keys are to be protected by smartcards, for
greater assurance.
Considerations are in progress whether the government would accept certificates issued by others,
banks, e.g. There are some doubts, a.o., about the enrolment process, whether the assurance level for
bank certificates will be sufficient for government use.
As of now, there has been a limited number of PKI-projects carried out within the areas of taxes,
unemployment benefits, social care and "citizens service card". The critcal issues identified by the
projects were:
secure and user-friendly user environment
matching back-office-processes
privacy (the Netherlands does not have any national unique personal identification number).
8
Today, 20% of citizens file their tax returns electronically. There’s a plan to implement PKI for tax
filing from businesses within the next year. By the end of 2000, a governmental certificate policy as
well as standards for naming and identification shall fall into place.
2.5 United Kingdom
Her Majesty’s Government has several PKI initiatives underway, some covering internal government
uses and others covering uses with the public.
UK law already recognized digital signatures as legally binding implicitly, but has enacted legislation
(which has passed through Parliament and received the Royal Assent) making that recognition explicit.
The Electronic Communications Act recognises electronic signatures as valid. This act does not
address liability issues, as they are covered by existing contract law. Regulation of Trust Service
Providers (TSPs) is voluntary and driven by the private sector industry with government involvement.
This approach is called "co-regulation". The voluntary accreditation scheme is called "t-scheme".
Government representatives sit on the board of t-scheme.
In March 1999, the Modernising Government White Paper was presented by the Government. This led
to adoption, in April 2000, of the "e-government Strategy" which covers the implementation of egovernment in UK. The main targets are: by 2002, 25% of government dealings with the citizens shal
be done electronically, and by 2005 - 100%. Under this initiative, several guidelines had been produced
so far, among them guidelines for:
Digital TV-based service delivery
Call centres
Web-based service delivery
Interoperability
Security
Authentication
Smartcards.
Examples of early electronic services are:
personal tax filings (done using PIN-codes and SSL, shall move to PKI),
value-added-tax filings,
pay-as-you-earn tax filing by businesses, and
some life event services such as birth of children and moving to a new location (address update which
propagates across multiple agencies/uses).
In December 1999, a "mock-up" pilot for digitally signed address change was carried out, involving
two TSPs – a bank and the Post Office. The lessons learned from that project imply that there’s a need
to give greater attention to privacy and data protection issues and the need to make smartcard-based
user interfaces more intuitive. Furthermore, there was a positive reaction to postal services acting as a
TSP, while there was a more reserved reaction to private sector organisations acting in the same role.
Postal services are likely to play a major role as a TSP for citizen transactions.
PKI is viewed as a necessary infrastructure, even though it is complex and costly. The drivers for
implementing PKI are: the need for legal admissibility of documents, the need for assurance of identity,
and the need for assurance of authority for some transactions.
To support electronic service delivery to citizens, an Authentication framework has been developed
(http://www.iagchampions.gov.uk/guidelines/authentication/authentication.html). The framework
defines three non-hierarchical levels (or types) of assurance:
level 1 for transactions of minor significance, (might involve PIN-codes or passswords only),
level 2 for transactions of some significance,
level 3 for transactions of particularly high significance (e.g. involving personal safety or substantial
sums of money).
9
It is envisaged that certificates that are to be used on those various levels for transactions with the
government will have to be approved under t-scheme. Accordingly, profiles are being developed under
t-scheme for this purpose.
There’s no direct alignment with the requirements of the e-signatures directive. t-scheme does not
make any distinction between "qualified" and "not qualified" certificates.
Government departments are encouraged to adopt the framework and t-scheme profiles. The
government will also promote the use of t-scheme certificates in the private sector.
Additionally, it is intended that government profiles can be employed by (and accepted by) private
companies as well for commercial transactions – that is, the marketplace may find those government
profiles useful without being compelled by regulation to use them.
Citizen and business authentication will take place at the Government Gateway, which is part of the
UK Online portal. It is not intended to take place on an agency by agency basis. Agencies will liaise to
decide what level of authentication is necessary for a particular transaction. The portal will also have
receipting and auditing functions embedded. The UK Online portal is under procurement now.
SSL is generally viewed as an acceptable security mechanism for data in transit, recognizing that most
attacks occur on stored data where SSL provides no benefit. XML is being adopted as the standard for
obtaining and sharing data among agencies. For authentication, smart cards are considered to be a the
best solution, although the policy is technology-neutral.
Within the government, an initiative called "Cloud Cover" has been taken to provide PKI for internal
use. The aim of Cloud Cover is to ensure that agencies have access to "the widest possible range of
secure, interoperable and cost-effective PKI solutions." The strategy is not to provide one PKI for all of
government. Agencies may implement their own PKIs based on competitive procurement. Cloud Cover
has recently established a root CA that is managed by CESG (Communications Electronic Security
Group), based on the product Baltimore Unicert. Agency CAs will be subordinate to the root. Ministry
of Defence, however, is planning to use a bridge for their internal departmental uses. There is a plan to
migrate to OCSP for certificate status determination. This has been started based on own development,
but procurement will be considered when adequate products will be available. This service will
ultimately be integrated into the GSI (Government Secure Intranet), including integration with the GSI
directory.
Interoperability between Unicert and other CA products is being tested in a controlled test
environment. Products from five vendors are being tested. Numerous interoperability problems have
been identified among different products. A report summarising the test results will be published after
the test period.
Another part of the Cloud Cover initiative it the plan to issue smartcards to all civil servants. This
"campus card" will have multiple functions included – like opening the doors, starting up the PCs and
digitally signing e-mail and documents. Common Criteria will be used to assess product acceptability.
Profiles will be developed for CA, client and generic services. Cryptographic product assessment is to
be carried out by CESG, on the basis of CAPS (CESG-Assisted Products Scheme).
It should be noted that interoperability problems and slow take-up of smart cards continue to hamper
the deployment of PKI.
2.6 United States
In the United States Federal government, several categories of electronic transactions are relevant for
PKI. These are: intra-agency, interagency, agency to trading partner and agency to the public. In order
to coordinate PKI-development in the Federal government, a Federal PKI Policy Authority (FPKIPA)
is being established [actually done in late June 2000] that will map agency certificate policies to a
central certificate policy developed by the Policy Authority. This approach is necessary because each
agency may develop its own PKI - select its own policy, and purchase whatever
10
product or services it wishes; there is no centrally controlled process. The Policy Authority thus
accomplishes policy interoperability among agencies; technical interoperability is being addressed
through establishing a Federal Bridge CA (FBCA), with which agency PKIs will cross-certify.
The mapping of agency certificate policies to the FBCA certificate policy will be done by the Policy
Authority, and the results of that mapping will be placed into the certiticates issued by the FBCA (in
the policyMapping extension field pursuant to X.509). The Policy Authority, which operates under the
Federal Chief Information Officers Council, will not control agency behavior as relying parties - that is,
agencies are free to accept
whatever certificates they desire. Instead, the Policy Authority and FBCA will allow agencies to make
informed decisions about which certificates to accept for what transactions. Agencies will not be
required to interoperate their PKIs using the FBCA, but agencies have indicated that they plan to do so
because it is more efficient than establishing bilateral relationships with every other agency.
Although the FBCA is intended initially to support interagency PKI interoperability, it will also be
capable of supporting interoperation with external parties as well - e.g., companies, state and local
governments, and foreign governments. Such interoperability will be controlled by the Policy
Authority.
The FBCA will have a directory service supporting both X.500 chaining and LDAP with referrals; the
directory will contain all certificates issued by any node of the FBCA, as well as ARLs (Authority
Revocation Lists). The FBCA technical infrastructure shall be based on COTS (Commercial Off The
Shelf) products. A prototype of the FBCA
is operational with two CA products (Entrust and Cybertrust; the latter has
recently been replaced with Baltimore Unicert) cross-certified within the FBCA membrane. The plan is
to add further CA products in establishing the production version of the FBCA, which is planned for
later in the year depending upon funding from Congress. The operational authority - i.e., the entity
running the FBCA - is the General Services Administration (GSA).
The prototype FBCA was tested as part of the Electronic Messaging Association Challenge 2000 in
April 2000 in Boston, Massachusetts. The prototype FBCA cross-certified with six disparate PKI
domains employing five different CA-products (Entrust, Cybertrust,CygnaCom, Spyrus, Motorola) and
five different directory products (PeerLogic, ICL, Nexor, CDS, Chromatix). The effort demonstrated
the ability to validate digital signatures on S/MIME messages across the different domains, which
included the Department of Defense, the National Aeronautics and Space Administration, the Georgia
Tech Research Institute, the Government of Canada, the General Services Administration, and the
National Institute of Standards and Technology.
The FBCA certificate policy provides four levels of assurance (Rudimentary, Basic, Medium and High)
modeled after the Government of Canada's certificate policy. Only identity certificates are supported at
this time - no role- or attribute certificates, although there is no technical reason why the model cannot
be extended to such certificates in the future. The assurance levels differ depending on identity
proofing (strength of the enrollment process), strength of cryptoalgorithms used, and protection of
private keys.
As far as certificate directories are concerned, the intent is that every agency establishing a PKI will
build a "border directory" that will mirror data from their internal repositories which the agencies
wishes to expose publicly. Border directories will likely contain names, e-mail addresses, phone
numbers and digital certificates.
Examples of PKI use within the federal government are:
Department of Defense ( over 250.000 certificates issued, target is well over 4 million by 2002; high
assurance with smartcards)
Federal Aviation Authority ( ca 1.000 certificates issued, this will increase to ca 20.000 in 2000;
software-based now, migrating to smartcards)
Federal Deposit Insurance Corporation (ca 4.000 certificates issued, over 7.000 in 2000)
11
NASA (ca 1.000 certificates issued, over 25.000 expected issued in 2000)
United States Patent and Trademark Office ( ca 1.000 certificates issued, expect ca 15.000 in 2000).
There are also plans to employ PKI in intra-agency communications, specifically within the following
areas:
Department of Veterans Affairs (VA) and Social Security Administration (SSA): information exchange
on medical evidence
Department of Education, SSA, VA: exchange on student loan applications, disbursements
National Finance Center for on-line payroll matters (all employees of Federal government civil
agencies)
Federal Deposit Insurance Corporation and other financial regulators for sharing information (financial
regulators' PKI).
For public use of PKI, a special type of certificates will be provided - ACES (Access Certificates for
Electronic Services). The certificates will be provided under three framework contracts managed by the
GSA (General Services Administration). Early users are expected to be SSA and VA. The goal is to
issue ca 100.000 certificates to the public by the end of 2000. The issuance cost of an ACES-certificate
is expected to be under 20 USD and it will be valid for 6 years. Transaction costs will vary between
1.20 USD and 0.40 USD depending upon volume. It will be the agencies that pay for the certificate
issuance and use, not the public.
The registration process for getting ACES certificates is carried out on-line, with the applicant
providing private information to the ACES registration authority over an SSL connection. The
registration authority then uses commercial financial and other databases to verify identity. Once
identity is verified, a one-time PIN-code is then mailed (by regular mail) to the user's address (this is
the "out of band" process). The user then generates his or her signature key pair, and provides the
public key with the PIN over an SSL connection to get the certificate, which is downloaded into the
user's browser. No encryption certificates will be issued. The public's communication with government
agencies will be protected by SSL for confidentiality.
Due to privacy considerations, the ACES-certificates will contain the user's common name as the only
identification. Agencies will therefore need to implement procedures for disambiguation of persons
when a certificate is used for the first time, based on exchange of one or more "shared secrets." Once
an agency determines exactly to whom the certificate belongs through this disambiguation process, it
retains a record thereafter which allows the certificate holder to use the certificate without needing to
go through the process again.
Regarding the legal status of electronic signatures (of which digital signatures are a subset), the
Government Paperwork Elimination Act was enacted in October 1998. The Act requires agencies to
accept electronic forms and signatures from the public by 2003 if the volume of submission is greater
than 50.000 annually. Additionally, the Act gives full legal effect to electronic signatures and
recognizes electronic record keeping.
The OMB (Office of Management and Budget) published guidance on electronic signatures as required
by GPEA in May 2000.
In June 2000, Congress passed and the President signed the Act on Electronic Signatures in Global and
Interstate Commerce (called "E-Sign") that gives legal recognition to electronic signatures and
electronic records for transactions between private parties, not involving government.
From an international interoperability standpoint, the US Federal government is interested in several
potential applications which may benefit from government to government PKI interoperability. One
example is the US Patent and Trademark Office's
efforts with the Canadian Intellectual Property Office. While inter-governmental interoperability of
PKIs will take some time to emerge, the US Federal government intends to pursue such interoperability
with the Canadian government as soon as the Federal PKI Policy Authority is operational and the
production Federal Bridge CA commences operation.
12
US Federal government PKI efforts are fully described in a report, "The Evolving federal PKI",
published in June 2000 and available in pdf at the government PKI web site, http://gits-sec.treas.gov.
2.7 Finland
The Government of Finland has several recently enacted and implemented laws dealing with the
issuance of national identity cards ("population registration") which are smartcards with digital
certificates. These cards are regarded as an "open key" to electronic services from the government.
The relevant acts include:
Identity Cards Act & Amendment of article 23 of the Population Registration File Act, which entered
into force 1.12.99, dealing with issuing and cancelling of Electronic Identity Cards (EID) and
certificates for the card and also other platforms, by the PRC (Population Register Centre). The
Amendment defines PRC´s role as a CA in electronic services in the administration and allows for
storing of FINUID in the Population Information System File and the certificate issued by PRC.
Act on Electronic Communications in Court Procedures, entered into force 1.12.93 that deals with
electronic lodging of civil/criminal court matters. It stipulates that no signature required if contact
information is provided.
Act on Electronic Service in the Administration, entered into force 1.1.2000, dealing with electronic
lodging of administrative matters with an authority and possibility to deliver requested documents and
messages, electronic signing and notification of administrative decisions, as well as requirements for
CAs and certificates used in the public sector.
Law on Electronic Signatures, which is at drafting stage in the Ministry of Transport and
Communications. It is expected that the law will og to Parliament in the autumn of 2000. The draft law
follows the EU directive´s wordings to a great extent.
Issuance of EID-cards requires in-person identity proofing done by the Finnish national police acting as
the Registration Authority. The cards contain two certificates, one for signature, the other for
encryption/authentication. Keys are generated on the card by the government when the card is
manufactured. It is done after the citizen goes through the registration process. The cards are physically
delivered at the police station, so the citizen must return to pick up her card – thus the citizen is identity
proofed to register for the card, and then identity proofed to receive the card. The card also comes with
two pre-determined PINs (one for the signature certificate and one for the authentication/encryption
certificate) for unlocking the private keys; the PINs cannot be later changed. Three failed sequential
attempts lock the card requiring a visit to the police station to unlock.
The certificates are based on X509v3, with RFC 2459 Certificate Profile for the extension fields. The
card is PKCS#15 compliant, with internal memory of 16K . 32K cards are expected to be used by the
end of the year. The Finnish company SETEC provides the cards. The cards cost about 200 Finnish
Marks (about USD 30) each, the citizen pays 180 FIM. The cards are also physical identity cards with
printed information and a picture of the holder. The cards can be used as a regular passport in all
Council of Europe countries, and to obtain electronic services from the government by citizens over the
Internet.
The CA product being used is iD2 from the Swedish company iD2 Technologies. The product does not
cross-certify with other CA products at present but is expected to be enabled to do so in a future
version. The user needs a card reader and a plug-in to her browser (plug-ins from iD2, Cellakom,
Baltimore, Siemens and Utimaco are available).
The subject name is unique and includes the Finnish Unique ID (FINUID) number together with the
common name. The certificate used for signature has the non-repudiation bit set but not the signature
bit. This is viewed as being in conformance with the EU directive on e-signatures, and it differs from
the US/Canadian model of setting both the non-repudiation and digital signature bits for a "digital
signature certificate." Moreover, the encryption certificate has both the signature and the encryption
bits set, the former so the certificate can be used for authentication, the latter for encryption.
Directory services are both X.500 and LDAP based. For X.500, the PRC is using PeerLogic i500.
Directories of citizen certificates are publicly available. CRLs are published hourly. A total of 5,000
cards have been issued, with a deployment rate of about 1,000 per month (Finland has a population of
5M citizens.). This rate is expected to increase as more electronic services (both government and
private sector) become available on-line.
13
Current government services include registration of change of address at the PRC, library access,
employment services, and registration for receipt of information. The card is voluntary – citizens are
not required to have one – but are encouraged to do so.
There are three levels of assurance for the certificates that will be issued in Finland. One level is the
enterprise CA "basic" level, the second is the "baseline" level for certificates for B2B and B2C
transactions. The third level is the "enhanced" level, matching the one for EID-cards. These levels are
mapped onto the EU directive’s notion of "qualified certificates" as follows: the "basic" level will
support both QC and non-QC, the "baseline" level corresponds with QC, while the "enhanced" level
will represent higher assurance than QC (as allowed for in the EU directive’s article 3.7).
Certificates on the national card can be accepted by private parties for non-governmental transactions
(e.g., business to business or individual to business), but certificates issued in the private sector
currently are not accepted for use with the government. This may change when the legislation
implementing EU directive is enacted.
The government also intends to support "role-based" certificates (i.e., attribute certificates) but those
efforts are in the early stages.
Examples of PKI-enabled services in Finland:
The very first service to utilize the FINEID-card: electronic registration of change of address by
Population Register Centre and Finnish Post
Services by municipalities and regions (Tornio, Rovaniemi, Oulu, Kuusamo/ Koillismaa, Pori, Raisio,
Turku, Etelä-Karjala IT-region, Espoo, Vantaa, Helsinki ja Joensuu. Common factors to all of these are
different application forms, electronic forms, library services etc.
Application and financial services by the Finnish patent organization
Electronic tax filing service for companies and organizations
Employment services by the Ministry of Labour
Electronic application form by the Office of Education and social and welfare services / makropilot.
2.8 Sweden
The Swedish government has a long tradition in usig electronic ID-cards (EID). Some 50.000 cards are
being used in several agencies, for sign on to systems, signature and disk encryption. Standards for
certificates and smartcards are defined by SEIS (Secure Electronic Information in Society), an
association that is now part of a larger e-business alliance.
The interdepartmental agency Statskontoret manages framework contracts for standardised electronic
ID-cards for internal use within the public sector. There has been little sale under the contracts, mainly
due to few applications that need PKI-support and a relatively high cost of cards (ca 600-650 SEK pr
card, approx. USD 70).
There are PKIs in use within corporations, some government agencies and banks. There’s no open
interoperability of these PKIs.
The government of Sweden has determined that PKI is the appropriate mechanism for
identification/authentication and confidentiality for use by citizens. It is, however, expected that such
use will grow substantially first within government and with businesses before it sees widespread use
with citizens. Nonetheless, there are plans for electronic service delivery by government to businesses
and the citizens covering such areas as tax declarations and filings, medical benefits, employment
(helping those seeking jobs), student loans, and the legal aspects of real estate transactions. The
government is reviewing their authority under laws in each area, and does not plan to have an
overarching "electronic signatures are acceptable everywhere" type of law, but rather will adjust laws
on a case by case basis where necessary. The EU directive on e-signatures, however, will be
implemented in a separate law on electronic signatures. The law is being drafted by the Ministry of
Industry.
In February 2000, the government issued a report on planned use of PKI within the government and to
support e-services to citizens. The report proposes the establishment of a government CA for
certificates issued to the public, but also the acceptance of certificates issued by private sector
companies as well as companies under contract to the government (especially banks). This matter is
14
being further investigated by the National Tax Administration, that was proposed to house the CA. The
main issue is how to finance a government-run CA.
The report also proposes three classes (assurance levels) of certificates:
Class 3: "Qualified Certificate" under EU directive; for electronic signatures when signing is required,
for information that requires a high degree of privacy; smart cards for private key protection, issued by
personal attendance
Class 2 : for sign on, digitial signatures for identification; private keys stored in software, issued by
personal attendance
Class 1: other certificates.
One important debate in Sweden related to PKI-supported e-services for citizens is whether to place the
national unique identification number ("personal number") in the certificate to ensure distinguished
naming. This may lead to compromitation of the owner’s privacy. The debate is not yet resolved.
The government is also considering other authentication technologies for public access to government
e-services. Secure identification tokens are expected to be used by some agencies (tax administration
and social security administration).
Planned electronic services from the government include:
business monthly tax declaration (tax administration)
starting a business (tax administration and company file)
sickness and parent benefits (social security administration)
employer and job seeker communication webb sites (employment administration)
student loan system (central education grant agency)
real estate board’s applications.
The challenge for secure e-services to citizens is to attain the goals of low cost and ease of use,
acceptable security and flexibility, all at once. PKI is one of the solutions, but not the only one.
2.9 Norway
The government of Norway has adopted an Action plan for electronic government in early 1999. The
plan which includes measures to develop an infrastructure for internal and external electronic
communication with the government. The infrastructure shall also support the delivery of e-services to
businesses and citizens.
The Norwegian government initiated the Public Administration Network Project in 1996 with a view to
establishing a secure, trustworthy and effective communications infrastructure for the Norwegian
public sector - comprising both local and central government. The project's main achievement was the
institution of a series of framework agreements, based on common requirements specifications,
covering data communications, network products and services, data products, Internet-services, etc. , as
well as TTP-services and digital signature/encryption. A framework agreement with 3 CSPs, and 4
software/smartcard suppliers were signed in May 1999. The CSPs are: Norwegian Post (iD2) and
Norwegian Telecom (Entrust) and a third company (Strålfors) that actually also uses Norwegian Post to
run their CA.
Under the framework agreement, CSPs were required to cross-certify their CA-services in order to
enable customers from the public sector to choose freely between the CA-services offered. The crosscertification requirement included the interconnection of certificate directories of the 3 CSPs, with the
possibility of transparent search for certificates across the directories. The cross-certification agreement
was signed by the three CSPs in September 1999. The agreement is still in its implementation phase,
expected to be completed by August, 2000.
The certificates are only for internal government use. Registration is done locally by the agencies using
VPNs over the Internet. The Public Administration Network Cooperation (that manages the framework
contracts) has developed a certificate policy with one level of assurance. It requires three separate key
pairs, SHA-1 hash and RSA 1024 algorithm for signing, 3DES, RC5 for encryption, private key
protection on hardware token, personal attendance at registration. This trust level covers encryption,
15
digital signature and authentication certificates. It is considered to be compliant with the "qualified
certificate" in the EU directive, as far as this compliance is possible to establish. Hardware tokens are
smartcards compliant with PKCS#15. The smartcards are not necessarily considered to be ID cards.
Agencies may place picture IDs on the cards but are not required to do so.
There are four types of certificates:
organizational certificate,
personal certificate (civil servant),
role certificate (units, functions), and
profession certificate (e.g. barristers, health professionals).
Organizations are uniquely identified but not natural persons.
Pilot efforts include signed e-mail between government departments, electronic tax return submissions
from companies, medical records exchange among government-supplied health care providers,
electronic submission of patent grant requests (National Patent Agency) (which may include patent
applicants and their agents – which does include the public in a limited way), and telecommuting by
government workers using PKI for authentication and confidentiality.
The Ministry of Industry and Trade is drafting a law to implement the EU directive. It is expected that
the law will go to Parliament by later 2000 with adoption and implementation by 2001. A survey of
Norwegian laws is also underway to find impediments to e-commerce. The survey is expected to be
completed by July 2000. The effort includes developing proposed remedies which may include a
general law that eliminates the impediments (e.g., general statement that electronic signatures shall
have the same force/effect as written signatures unless otherwise specifically restricted).
For PKI use with citizens, there are many complications which remain to be resolved before such use
can be implemented. The government needs to first review and change (where necessary) the laws (as
discussed above), then adopt regulations, and then proceed to implementation which will have to
address a variety of matters including how many levels of assurance are needed, how should they be
designed, should certificates be accepted from non-governmental (private) CAs, how is naming to be
done, how is interoperability effected, and so on. At present, the Ministry of Defence sets
cryptographic standards that apply even to encryption of sensitive unclassified documents, but that will
be changed when the new codification of the Law on Security will be adopted, probably by the end of
2000.
The Government PKI Task Force had been named by the government in February 2000 and charged
with the tas of outlining a PKI-policy for the government. The task force includes the centrall and local
government levels.
The Government PKI Task Force shall publish a report by December 2000 containing the results of its
efforts and recommendations on how PKI shall be deployed across agencies and with the public and
trading partners, considering the issues discussed above and the results of the pilot efforts.
3 Discussion – key points
3.1 Internally vs externally manged PKI
Three distinct approaches to providing PKI for government and for citizens’ access to e-services might
be distinguished from the presentations:
Each government agency builds their own PKI, cross-certification for interoperability, or central root
authority
There’s a central government agency providing certificates for citizens (and government employees)
The certificate services are procured under contract from external parties. These parties must crosscertify.
There may also exist some combinations of the above models.
The discussion showed that e.g. US government will never use external CSP (like Verisign, e.g.) for
provision of government certificates, mainly due to security reasons. From this follows that publicly
rooted certificates will not be accepted. That leads to the (potentially big) problem of getting
16
government certificates into citizens’ browsers. External certificates may be accepted provided the
supplier is cross-certified with the government bridge authority. It is believed that CA keys should
somehow be under government control – and this is not the case with publicly rooted certificates. This
issue might, however, be resolved by terms and conditions of a contract (this is being proposed by the
UK).
In the US, the agencies might refuse any certificate if they deem it not being of proper quality.
Other countries believed that the government may employ COTS-services if the procurement is done
under the proper terms and conditions. There are instruments for controlling terms and conditions in
CSPs, like independent audit of CP and CPS done by accredited auditors.
The decision to procure PKI externally depends on the security level required and some departments,
such as police and the defense sector, will probably choose not to outsource their PKI.
Some countries felt that having internal PKI allowed for better control of whether the agencies employ
the PKI in a proper way – "we issue the card and you have to use it".
3.2 Trust levels
Some countries questioned the need for many levels of assurance. Given that 80% of all transactions
are focused on one level - why define many levels? This makes PKI unnecessarily complex. It was also
pointed out that a level lower than "qualified certificate" (QC) of the EU directive is practically useless
and the need for such level was questioned.
Many stipulated that, with wide adoption of PKI, some "medium" level will emerge as prevalent and
everybody will then adjust to it in their applications.
On the other hand, certificates might be enhanced with other techniques – like "shared secrets", so one
might have one type of certificate for the citizen, and the agencies will then build additional security
upon this.
It was pointed out that it might not be necessary to set national goals concerning levels of assurance, as
the EU directive’s QC should (in theory) support 80% of all transaction needs. Many countries felt,
however, that they wanted to be able to have their security needs determined themselves. This is, in
some respect, a national self-governance issue.
Comparing to e.g. banks, that supply services based on the concept of "managed risk", the
government’s service supply is based on trust. Sometimes, however, government may work on the
basis of "managed risk" , too (e.g. money management). Getting e-services easily to the public is also a
kind of managed risk exercise.
One probable outcome (in Europe) of the assurance level discussion might be one assurance level for
the citizens and two internally in the government: secure and very secure. The mapping on the directive
requirements might be QC, QC, QC+more, respectively.
Having many assurance levels might lead to questions like: Which certificate to use when signing a
letter? The answer might be that if in doubt, choose the highest level you have available. Anyway, the
selection of appropriate certificates is usually hardcoded in the applications.
When every agency issues certifictes to citizens, the citizens may get confused as to which certificate to
use for which purpose. This calls for a common level for citizens, but not necessarily for government
employees. Agencies will have to cooperate by employing cross-certification or a bridge.
It was pointed out, that it would be difficult to standardise the rules of enrolment – various agencies
will have different rules for this and this opens for varying trust levels.
17
Some questioned - why not use the QC for all transactions, perhaps have something in addition for very
sensitive data - while others pointed out that trust must be based on risk analysis. Multiple levels of
trust are also a result of varying requirements across the government. It emerged that main elements by
which the various trust levels will be distingushed may be:
the enrolment process,
the strength of cryptoalgorithms
the protection of private key and
the number of key pairs1 .
The discussion also underlined the need for market place acceptance of PKI. There were concerns that
credit card companies or banks blazing the trail might force the government into acceptance of their
level of trust, even if it is not deemed "good enough". Such situation might also collide with some
government policies on authentication and identification.
The "qualified certificate" shall assert, in an extension field, whether it is "qualified" under the EU
directive, or not. The assertion will be made by the CA issuing the certificate. The supervisory
framework is expected to provide for correcting any assertions that are made, which are judged to be
incorrect. This does mean that certificates containing the assertion may not be legitimate at the time of
issuance and at the time the relying party seeks to use them. This is a problem that is especially evident
in cross-border communications.
The issue of acceptance of certificates from other countries operating under the EU directive was
briefly discussed and concerns expressed as to whether a user in one country can trust a certificate from
a foreign CA, and furthermore, how is she supposed to get hold of this CA’s key.
The fact that a certificate is "qualified" is self-asserted, which means that it is important that CA
providers be audited to show compliance with the EU directive if they claim to be issuing "qualified
certificates."
One country noted that they intend to deal with this by having a government CA issue certificates to
those CAs whom it trusts to issue certificates under the directive, so if browsers are configured to
check that fact before relying upon a certificate, trust is preserved. Other countries questioned,
however, whether that approach complies with what the EU directive requires and allows.
There was further discussion on how this would be implemented technically within browsers. The
suggestion was that a user who, using his or her browser, receives a certificate from a commercial CA
located in a different country, where the CA claims to be issuing qualified certificates, will get the popup window which says "This CA is not in the Browser Trust List, do you wish to trust it?" At that
point, the user will have to refer to a list of CAs which European governments have reviewed or
otherwise determined to be acceptable issuers of "qualified certificates" before deciding whether to
accept the certificate. This is, in effect, an administrative solution, and it requires the maintenance of up
to date lists of which commercial CAs have been reviewed or audited to demonstrate compliance with
the EU directive.
The Directive also allows governments to declare that certain uses involved "closed user groups". This
allows a government to restrict which certificates are suitable for applications within that "closed user
group." This is one way in which certificates from outside the country may be excluded from use.
Otherwise, any "qualified certificate" whether issued within one country or some other country must be
accepted for applications where a "qualified certificate" is considered acceptable.
18
3.3 EESSI and global PKI interoperability
There was a brief discussion of the European Electronic Signature Standardization Initiative (EESSI)
and how it is intended to support technical interoperability among certificates issued under the EU
Directive, and the use of those certificates. There was general agreement among the European countries
that the certificates issued to the citizens will have to be "qualified" to be useful. Government employee
certificates will likely either be "qualified" or "specially qualified" where the latter entails imposing
additional case by case requirements beyond "qualified". That could create interoperability concerns
since the special requirements can differ by government and/or by agency within a government.
However, the directive does not deal with cross-certification as a principle for interoperability, while
e.g. USA and Canada rely on it. The need for reconciliation of these approaches was discussed.
OECD work in the Working Party for Information Security and Privacy was mentioned. This work
may result in global guidelines for digital signatures and certificates. Some countries were skeptical to
such guidelines, but the approach is changing to a more market driven approach, where the need for
developing a framework for interoperability with other countries – like Australia, Singapore etc. is
emerging.
Under the directive, government managed PKI is a closed system – it may cross-certify with any
American or Canadian CA on the basis of agreed requirements. This led to the question whether CAs
providing certificates to government employees do fall under the directive or not.
It was pointed out that the directive’s article 7 uses a mixture of legal techniques to ensure
interoperability with other countries.
There seems to be a match between the medium and higher levels in USA and Canada and the QCrequirements. Canadian policy is approved, while the USA’s is still in the approval process. It was
suggested that EESSI group developing CP to support the directive could include the Canadian and the
American CP for discussions on the ETSI Baseline Policy for Qualified Certificates. Some participants
mentioned that the Canadian policy already is being discussed.
3.4 Interoperability issues
The biggest issue that had been discussed was the discordant ways in which the non-repudiation and
digital signature bits in certificates are set, and how that really does affect client software
interoperability. In the US and Canada, they typically set the non-repudiation and digital signatures bits
for "digital signature certificates" and then allow those certificates to be used for authentication and
digital signatures. For data encryption certificates, only the data encryption bit is set (unless the
certificates are for SSL, in which case the key encipherment bit is set). In Europe, where three
certificates are used, each sets one bit: data encryption (for encryption), signature (for authentication),
or nonrepudiation (for signature). If two certificates are used, the signature certificate sets the
nonrepudiation bit, but the encryption certificate sets the encryption and the signature bits. This means
that applications which are enabled to accept certificates with both nonrepudiation and signature bits
set for digital signatures will fail to accept digital signature certificates issued in Europe which set just
the former bit. There’s various rationale s for this approach – e.g. that sometimes one wants to sign for
integrity and not non-repudiation. There were also some fears that signing a challenge in real
authentication might have some (unwanted) legal consequences if the non-repudiation bit is set.
Some European countries do, however, use the US / Canadian approach with two certificates.
This discussion illuminated the need to get consonance on how these bits are to be set or else
certificates will not be interoperable. Other solution might be to force the vendors who enable
applications to accept certificates into allowing users to decide which bits are acceptable for which
applications. This might prove difficult because of the vendors’ installed base of software.
19
One arena for a dialogue with the vendors on this might be the PKI-forum2 that focuses on technical
interoperability. It is a vendors’ association, but governments may join at no fee. They will, however,
have no vote. Some countries urged the group to join the forum and thus be able to push the vendors to
demonstrate interoperability, others were more skeptical of a possible "hostage" role versus the
vendors.
4 Summary and conclusions
The meeting conluded with the following statements:
The PKI is a viable solution for government to support secure electronic communication and e-service
delivery; it is, however, a complex and costly solution that needs maturing of the market place and
stringent government policies.
There’s a need to discuss more in depth the issues of assurance levels, provision of certificates for eservice delivery, interoperability and reliability.
The issue of interoperability between the government and the private sector needs greater attention,
especially in connection with the deployment of certificates for e-service delivery.
The governments should join up in exerting pressure on the PKI-vendors to demonstrate and
implement interoperability in their products – this requires some common understanding and
prioritization of issues among the governments.
There’s a need for further exchange of experience on PKI implementation in government. Therefore, a
new meeting was tentatively scheduled for spring 2001, in Canada.
Annex I
International meeting on PKI in government, Oslo, 25th-26th of May, 2000.
List of participants
Richard Guida, Chair, Federal PKI Steering Committee , USA
Federal Chief Information Officers Council
633 3rd Street N.W., Room 143
Washington, D.C. 20220
+1 202-622-1552 (work)
+1 202-435-8047 (cellular)
+1 202-622-2733 (fax)
richard.guida@cio.treas.gov
www: http://gits-sec.treas.gov
Sue Bryant, Deputy Director, Operations, Interdepartmental PKI Task Force, Canada
Standard Life Building, 6th Floor
275 Slater Street, Ottawa
K1A 0R5
Tel: +1 613 957-0527
Fax: +1 613 946 9893
Email: bryant.sue@tbs.sct.gc.ca
www: http://www.cio-dpi.gc.ca
Jan Timmermans, Public Sector Information Policy Department,
Ministry of the Interior and Kingdom Relations, The Netherlands
Schedeldoekshaven 200
Postbus 20011
2500 EA den Haag
Tel: + 31 70 426 6631/6763
Fax: + 31 70 426 7623
20
Email: jan.timmermans@minbzk.nl
Lonneke Stempels, PKI overheid, The Netherlands
Herengracht 17-19
Postbus 20011
2500 EA Den Haag
Tel: +31 70 31 23 299
Fax: +31 70 31 23 612
Email: lstempels@PKIoverheid.nl
www: http://www.pkioverheid.nl
Ray Kavanagh, Centre for Management & Organisation Development,
Department of Finance,Ireland
Lansdowne House
Lansdowne Road
Dublin 4
Tel: +353 1 8251910
Fax: +353 1 6682182
Email: ray.kavanagh@cmod.finance.irlgov.ie
Andrew Smith, Assistant Director, Technology Policy,
Central IT Unit, Cabinet Office, United Kingdom
53 Parliament St,
LONDON SW1A 2NG.
Tel: +44 (0)20 7238 2030
Fax: +44 (0)20 7238 2068
Email: asmith@citu.gsi.gov.uk
Tapio Aaltonen, Deputy Director, Electronic Identification,
Population Register Centre, Finland
P.O. Box 7, (Kellosilta 4)
FIN-00521 Helsinki
Tel: +358 9 2291 6625
Fax: +358 9 2291 6718
GSM: +358 50 563 5706
Email: tapio.aaltonen@vrk.intermin.fi
Vesa Vatka, Development Manager, FINEID-technology,
Population Register Centre Finland
P.O. Box 7, (Kellosilta 4)
FIN-00521 Helsinki
Tel: +358 9 2291 6717
Fax: +358 9 2291 6718
GSM: +358 50 344 3103
Email: vesa.vatka@vrk.intermin.fi
Britta Johannsson, Information Technology Department,
The Swedish Agency for Administrative Development (Statskontoret) Sweden
Box 2280 (N. Riddarholmshamnen 1)
SE-103 17 Stockholm
Tel: +46 8 454 47 12
Fax: +46 8 454 46 93
GSM: +46 708 63 47 12
21
Email: britta.johansson@statskontoret.se
www: http://www.statskontoret.se
Toshikazu Sawada, Assistant Director, Government Information Systems Planning Division,
Administrative Management Bureau, Management and Coordination Agency,
Prime Minister’s Office, Japan
3-1-1, Kasumigaseki
Chiyoda-Ku
Tokyo 100-8905
Tel: +3 3581 Ex. 4194; +3 3581 2076
Fax: +3 3580 0760
Email: tsawadaa@somucho.go.jp
Hirokichi Yuzawa, Deputy Director, Information Economy Office, Machinery and Information
Industries Bureau, Ministry of International trade and Industry (MITI), Japan
3-1-1, Kasumigaseki
Chiyoda-Ku
Tokyo 100-8901
Tel: +3 3501 0397
Fax: +3 3580 6403
Email: yuzawa-hirokichi@miti.go.jp
Keiko Moriguchi, Interpreter
Katarina de Brisis, senior adviser, Government IT Coordination Unit,
Department of Government Services, Ministry of Labour and Government Administration, Norway
P.O. Box 8004 Dep. (Akersgaten 59)
0300 Oslo
Tel: +47 22 24 46 46
Fax: +47 22 24 95 17
Email: katarina.de-brisis@aad.dep.no
www: http://odin.dep.no/aad/
Amund Eriksen, senior adviser, Directorate for Public Management (Statskonsult), Norway
P.O. Box 8115 Dep. (Falbesgate 5)
0032 Oslo
Tel: +47 22 45 12 59
Fax: +47 22 46 94 70
Email: amund.eriksen@statskonsult.dep.no
www: http://www.statskonsult.no
Annikken Seip, senior adviser, Directorate for Public Management (Statskonsult), Norway
P.O. Box 8115 Dep. (Falbesgate 5)
0032 Oslo
Tel: +47 22 45 12 19
Fax: +47 22 46 94 70
Email: annikken.seip@statskonsult.dep.no
www: : http://www.statskonsult.no
22
Jens Nørve, project manager, e-commerce,
Ministry of Industry and Trade, Norway
P.O. Box 8014 Dep. (Einar Gerhardsenspl. 1)
0030 Oslo
Tel: +47 22 24 03 23
Fax: +47 22 24 01 30
Email: jens.norve@nhd.dep.no
www: http://odin.dep.no
Hilde Kristine Nysten Thorkildsen, political adviser,
Ministry of Labour and Government Administration, Norway
Annex II
FINAl agenda
25th of May, 2000
Welcome, information from the host
9.35 Opening of the meeting – keynote speech by Political Adviser Ms Hilde Kristine Nysten
Thorkildsen, Ministry of Labour and Government Administration
9.45 Short introduction to the topic of the meeting and the agenda – by senior adviser K. de Brisis,
Ministry of Labour and Government Administration
9.55 Round table (short) presentation of the participants
Start of the round table presentations of status in the participating countries. We expect each
presentation to address PKI-policy issues, e.g. like those mentioned in the introduction, and/or some of
the following:
- approved trust levels and matching certificate types
- approved certificate policies – contents
- naming and identification of subjects
- use of PKI for confidentiality purposes - rules?
- interoperability of PKIs, certificates, certificate directories
- technical specifications for government PKI – which standards?
- market policies (government use of the PKI-market)
- practical experiences from running PKI-implementations - critical issues.
The presentation should, if possible, include a short overview of relevant national legislation that may
affect government PKI-use.
Moderator: K. de Brisis, MLGA
10.10 – 13.00 Round table
Canada
23
Japan
13.00 – 14.00 Lunch
14.00 – 18.00 Round table continued
Ireland
Netherlands
United Kingdom
U.S.A.
18.00 Close of the 1st day
20.00 Dinner for all participants at the restaurant Lofoten, Aker Brygge
26th of May 2000
9.00 – 12.30 Round table continued:
Finland
Sweden
Norway
12.30 - 13.30 Lunch
13.30 – 15.00 Discussion
Moderator: senior adviser A. Eriksen, Directorate of Public Management
Internally managed PKI vs use of COTS-services available on the market – rationale for both
approaches
How many trust levels are needed – for which applications, why different levels?
Can the interoperability problem be solved – best practice?
The role of standardisation – IETF’s PKIX, EU’s EESSI, ISO, NIST, BSI…etc. – who will set the
agenda?
15.00 Summing up by K. de Brisis, MLGA
15.30 Close of the meeting
1 ANNEX III
Opening remarks from Political Adviser Ms Hilde Kristine Nysten Thorkildsen, Royal Ministry of
Labour and Government Administration.
Ladies and Gentlemen,
I am very pleased to welcome you to Oslo, to the Ministry of Labour and Government Administration.
It is very satisfying to see that so many of you took time off your busy schedules in order to be able to
attend this meeting, which we hope will contribute to further development of this important area within
public administration.
24
Let me introduce you to the role and tasks of our Ministry, with special emphasis on our efforts within
information technology application within central government and the development of an electronic
government that will be able to offer services on a "24/7" basis, in an efficient way, to all citizens in
our geographically challenging country.
Our Ministry, among its several responsibilities, has the role of policy co-ordinator in the field of
public sector management, development of strategies for government organisation and government
services and IT-development across sectors and agencies.
The measures to attain these goals will be coordinated within the umbrella of up-coming "Renewal
Program" for public sector in Norway.
The main goals of this program are:
A public administration suited to society’s needs
A public administration fulfilling citizens’ expectations and needs
An efficient public administration
A co-ordinated public administration
Less administration, better service delivery
Less central micro-management, greater freedom for local decision making.
The main measures the program may encompass are as follows:
Increased de-centralisation and deregulation
Greater freedom for municipalities, less centrally managed budgeting
Re-allocation of resources from administrative tasks to service delivery
Outsourcing of non-governmental functions
New management methods, education and training of managers.
Now let me say a few words about our strategies for cross-sectoral IT-development and their relation to
the overall goal of renewal of public sector.
In early 1999, a 3-year action plan on electronic government had been adopted and thus a fundament
was laid for current activities and policy development in this field.
The action plan comprises eight priority areas which can be looked upon as building blocks of
electronic government. I will not go into detail, but give you a quick overview picture where I think
you will recognise many of the elements.
The priority areas are as follows:
1.Year 2000 security
2.Infrastructure
3.IT security
4.Information services on the Internet
5.Electronic administrative procedures
6.Electronic data interchange
7.Electronic commerce for public procurement
8. IT management and organisation.
Let me highlight a few of the areas, those in particular that relate to theme of this meeting.
Infrastructure development shall result in an interoperable networking environment and generic
services of common interest spanning all levels of public administration throughout the country in a
cost effective manner.
IT-security in government involves establishing necessary policies and remedies to maintain
confidence and trust in public administration and its robustness.
25
Information services on the Internet and Elecronic administrative procedures are both prerequisites for
development of interactive electronic service delivery to the citizens, based on the Internet.
In order to realise a "24/7" government services, some basic infrastructural elements must be in place.
To put you into the picture, let me show you some crude, but relevant indicators on how Norwegian
central government administration stands in relation to the development of information society.
The slide shows that many of the basic prerequisites for electronic government in the form of basic
infrastructure and applications are largely in place in central government administration, with local
government, the private sector and the wider public following rapidly behind.
There still are, of course, some major strategic issues to be handled on the infrastructure side - like
exploring new technologies, introducing value added services like common catalogue services,
improving interoperability, and increasing security levels so that the networks can be used for more
purposes than today.
As indicated initally, most central government entities have established their own website. How they
use the net varies a lot, however.
We may categorise the level of service delivery via the Internet into three main levels. The basic level
is to publish static information only. At the next level, two-way electronic communication, like e-mail
or ordering of forms and/or further information, is provided. At the most advanced level the Internet is
also used for service delivery and formal transactions.
We estimate that about 40% of agencies have reached the second level, with 10% at the first level only.
A few agencies have introduced services on the third level. 300.000 Norwegians submitted their tax
returns via the Internet this year, to give one example.
The challenge now is to stimulate all agencies to reach the third level as quickly and in an as efficient
manner as possible, in order to provide reliable electronic services to the public and thus fulfill the
goals of electronic government.
At the horizontal level, an issue of major and increasing concern is to ensure that electronic services are
delivered in an integrated and coherent way across agency and sector boundaries. Furthermore, it is
important to co-ordinate this development with other measures taken in order to provide better public
services, like the "single window to citizens" initiative, where we had a number of joined-up offices
operating across the country on a pilot basis. This initiative will now be followed up with the view to
establishing permanent solutions. Electronic services will be an integrated part of such new offer to the
citizens.
Finally, reliable and secure solutions for digital signatures and protection of electronic documents and
messages against fraud, are an important prerequisite for introduction of electronic government and
electronic service delivery. I hope that you will arrive at some relevant conclusions in that respect
during your deliberations here in Oslo.
On behalf of our government I wish you success in your important work in this area.
Thank you.
ANNEX IV
26
Pictures from the meeting are available in the printed report.
ANNEX V
Glossary
PKI – Public Key Infrastructure, a system of CAs, RAs, directories, client applications and servers that
model trust. It can be inter- or intraorganisational.
CSP – Certification Service Provider, an entity issuing digital certificates to the users on a commercial
basis.
TSP – Trust Service Provider, an entity supplying various kinds of trusted services on a commercial
basis.
CP – Certificate Policy, a document describing the rules, responsibilities and procedures associated
with issuance and maintenance of digital certificates by a CA.
CPS – Certification Practice Statement, a document describing actual set of measures implemented by
a CA in order to follow the rules etc. prescribed by a CP.
CA – Certificate Authority, secure server(s) that signs end-user certificates and publishes revocation
data.
RA – Registration Authority, a secure server that interacts with end-users. The RA registers user
requests and submits corresponding certificate requests to the CA.
QC – Qualified Certificate, a certificate defined by the European Directive 1999/93/EC on a framework
for electronic signatures. A QC shall meet requirements laid down in Annex I of the Directive and its
provider (issuer) must meet requirements laid down in Annex II.
Bridge – a system that provides interconnection of trust domains within a PKI.
Enrollment – a process for a large-scale registration of certificate end-users.
1 This issue caused a separate discussion, referred in a later section.
2 www.pkiforum.org