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 25-26 ^th> 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

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 e-government 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.

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 cross-certification. 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 cross-certification arrangement formally describing the terms and conditions of the cross-certification. Cross-certifications 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)
• 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.

Electronic service delivery from the government to the people is to be supported by a PKI-infrastructure (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 CA-products).

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, 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 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).

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 e-government 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).

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

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)
• 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.

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.

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 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 cross-certification 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, 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 cross-certify.

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 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.

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 pairs 1This issue caused a separate discussion, referred in a later section.

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 pop-up 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.

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 QC-requirements. 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.

One arena for a dialogue with the vendors on this might be the PKI-forum 2www.pkiforum.org

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 e-service 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.