**ELECTRONIC AUTHENTICATION**

**ISSUES RELATING TO ITS SELECTION AND USE**

##### eSecurity Task Group

**Business Facilitation Steering Group**

**APEC Telecommunications and Information Working Group**

# EXECUTIVE SUMMARY

1.  In their 1998 Blueprint for Action[^1], APEC Ministers recognised
    the enormous potential of electronic commerce to expand business
    opportunities, reduce costs, increase efficiency, improve the
    quality of life, and facilitate the greater participation of small
    business in global commerce. A cornerstone in achieving that
    potential is providing the tools that will allow parties to
    transactions to know with certainty the degree of reliance they can
    place on that transaction. Electronic authentication provides such
    tools through technologies that can ensure the authenticity of
    transactions. Some of the technologies also provide integrity,
    non-repudiation and confidentiality functions.

2.  Electronic authentication is a developing field. As it evolves new
    technologies and new issues emerge. Addressing these issues is a
    problem for both users and government policy makers. This report
    identifies the major issues to provide APEC member economies with
    guidance when developing policies for electronic authentication. The
    Report addresses the issues in general examines five different
    groups of technologies and how these relate to the issues raised. It
    also addresses some of the legal issues involved with the use of
    electronic authentication.

## Definitions

3.  There is a great degree of variation in definitions associated with
    both electronic commerce in general and electronic authentication in
    particular. There is a role for member economies to contribute to
    and stimulate international organisations' work in attempting to
    achieve the maximum degree of consistency.

## Electronic Business Models

4.  The Report examines a number of models of the environment in which
    electronic business might be conducted. These are provided to
    indicate the variety of different relationships that might exist
    between parties to an electronic transaction.

5.  It also notes a trend towards requiring authentication in electronic
    transaction where signatures are not required in equivalent paper
    processes. It notes the potentially greater demands on and or costs
    to businesses and users that can arise from this trend.

## User Requirements

6.  User requirements cover technical, business process and legal
    requirements. It is recognised that these requirements need to be
    met in a consistent manner and a manner that is simple to operate
    and easy to understand. There is a role for both governments and
    business representative groups to ensure the requirements are met.

## Electronic Authentication Technology

7.  The Report discusses in broad terms the advantages and disadvantages
    of a number of technologies including implementations that involve
    the use of several technologies in a single transaction.

8.  It is recognised that different technologies can meet different
    requirements. The choice is one for the parties to a transaction
    based on a risk assessment. There is, therefore, a need for
    governments to develop legal and policy frameworks to support all
    appropriate technologies.

## Certification Models

9.  The report examines the different ways through which a recipient of
    a transaction can establish whether the claimed sender is the actual
    sender of an electronic transaction. As with business models, this
    information is provided to indicate the different relationships that
    might exist when trying to establish the authenticity of a
    transaction.

## Trust

10. Trust can be achieved through the development of appropriate
    technology, development of appropriate legal and policy frameworks
    and development of appropriate business practices. Accreditation
    processes are designed to enable users to trust the technologies
    while legal frameworks are designed to enable users to trust that
    they can rely on the legal validity of a transaction. Awareness
    raising programs are designed to build the level of required trust
    once the appropriate frameworks are in place.

## Liability

11. Liability has been raised as one of the major issues facing users
    and authentication service providers. This issue is under active
    consideration in a number of international fora. Central to the
    discussion is whether governments should legislate in respect of
    liability or adopt a contractual approach. The issue is complicated
    by the fact that a number of economies are federations and
    jurisdiction for liability may rest with state or provincial
    governments.

12. It is likely that different jurisdictions will, at least initially,
    adopt different approaches. It will be important to ensure that
    adopting one approach does not prevent transactions with
    jurisdictions that adopt the alternative approach.

## Roles of Participants

13. As an essential part of electronic commerce, electronic
    authentication cuts across both the public and private sectors and
    extends down to individual users. For the electronic authentication
    schemes to function effectively, each of these groups needs to
    undertake defined roles. Examples of these are spelt out in the
    Report.

## Interoperability

14. The issue of interoperability means different things to different
    people. It has been argued in some quarters that we should be aiming
    for a single globally interoperable scheme. Others support the
    concept of a number of globally interoperable schemes. Different
    technologies will meet different requirements based on risk, cost
    and integration with other technologies. It is unlikely that the
    differing requirements can be met by a single scheme without
    compromising risk at one end or cost at the other. However too many
    schemes will confuse users, possibly increase costs as users need to
    implement an excessive number of schemes and leave users with a
    bewildering array of technologies attached to their systems. The
    objective should be to minimise the burden on users in order to
    encourage them to adopt electronic authentication and electronic
    commerce. Government and industry need to pursue an appropriate
    balance in consultation.

15. Technical standards and legal and policy frameworks will all impact
    on interoperability and cross border recognition of electronic
    transactions.

## Accreditation

16. One of the main issues to be addressed is whether government should
    license or regulate authentication technology or authentication
    service providers. Approaches could include government licensing,
    government endorsed accreditation schemes, standards based
    accreditation schemes and industry endorsed accreditation/audit
    schemes. Implementation of these schemes can be mandatory or
    voluntary. The type of approach adopted will vary from jurisdiction
    to jurisdiction determined largely by domestic policy on issues such
    as industry regulation and consumer protection. Problems will emerge
    if jurisdictions insist that authentication technologies or service
    providers satisfy their licensing or accreditation processes and
    requirements even where the service provider or user of the
    technology is located outside their immediate jurisdiction.

## Cultural Differences

17. The Task Group discovered several examples of cultural differences
    that have the potential to impact on electronic authentication.
    These highlight the need for governments to be sensitive to the
    existence of cultural differences between economies. Cultural
    differences have the potential to impact on technical, legal and
    policy aspects of electronic authentication. Often cultural
    differences are not addressed in these aspects through ignorance
    rather than intent. There is a need to raise awareness of both
    cultural differences and their possible impact.

## Awareness

18. Electronic commerce and electronic authentication are still emerging
    disciplines. The level of awareness of both the technologies and
    their use is patchy and in many cases fraught with misconceptions.
    This is particularly the case in respect of the security and
    reliability of the technologies and their implementation. There is a
    need to raise awareness among government policy makers, business
    managers and individual users. In many cases it will be difficult to
    focus attention on just electronic authentication as a large
    proportion of the target audience will have wider ranging
    responsibilities or interests. Strategies for raising awareness of
    electronic authentication technologies and associated issues will
    often need to be integrated with broader electronic commerce
    awareness raising strategies. Specific electronic authentication
    awareness raising programs can be developed and targeted at selected
    audiences.

## Leadership

19. Governments, international organisations, business, academics, users
    and user groups and the IT industry all have to assume leadership
    roles if electronic commerce in general and electronic
    authentication in particular are to flourish. Adoption of clear
    legal and policy frameworks, standards and business practices as
    well as use of the technologies themselves will provide the
    leadership required to ensure the widespread uptake of electronic
    commerce.

## Legal Issues

20. There are a number of legal issues associated with the use of
    electronic authentication. These include legal effect of electronic
    transactions and electronic signatures, liability and privacy.

## Conclusion

21. It was not the objective of the Task Group to make specific
    recommendations in this report. Rather the Report has been prepared
    to identify relevant issues for APEC member economies and the
    various working groups of APEC that will need to consider the issues
    and develop options in consultation with the wider international
    community.

EXECUTIVE SUMMARY [i](#executive-summary)

Definitions [i](#definitions)

Electronic Business Models [i](#electronic-business-models)

User Requirements [i](#user-requirements)

Electronic Authentication Technology
[i](#electronic-authentication-technology)

Certification Models [ii](#certification-models)

Trust [ii](#trust)

Liability [ii](#liability)

Roles of Participants [ii](#roles-of-participants)

Interoperability [ii](#interoperability)

Accreditation [iii](#accreditation)

Cultural Differences [iii](#cultural-differences)

Awareness [iii](#awareness)

Leadership [iv](#leadership)

Legal Issues [iv](#legal-issues)

Conclusion [iv](#conclusion)

1\. GENERAL ISSUES RELATING TO THE USE OF ELECTRONIC AUTHENTICATION
[1](#general-issues-relating-to-the-use-of-electronic-authentication)

INTRODUCTION [1](#introduction)

BACKGROUND [2](#background)

DEFINITIONS [4](#definitions-1)

ELECTRONIC BUSINESS MODELS [5](#electronic-business-models-1)

Open Model [5](#open-model)

Closed Model [6](#closed-model)

Open-But-Bounded Model [7](#open-but-bounded-model)

USER REQUIREMENTS [9](#user-requirements-1)

Technical Requirements [11](#technical-requirements)

Business Process Requirements [11](#business-process-requirements)

Legal Requirements [11](#legal-requirements)

Government Endorsement [11](#government-endorsement)

ELECTRONIC AUTHENTICATION TECHNOLOGIES
[11](#electronic-authentication-technologies)

Asymmetric Cryptography [12](#asymmetric-cryptography)

Shared Secrets [12](#shared-secrets)

Biometrics [13](#biometrics)

Other [14](#other)

Hybrid [14](#hybrid)

Selection [15](#selection)

CERTIFICATION MODELS [15](#certification-models-1)

Formal Certification [15](#formal-certification)

Informal Certification [16](#informal-certification)

No Certification [17](#no-certification)

TRUST [17](#trust-1)

LIABILITY [18](#liability-1)

ROLES OF PARTICIPANTS [18](#roles-of-participants-1)

Governments [19](#governments)

High Level Authentication Authorities
[19](#high-level-authentication-authorities)

Authentication Service Providers [19](#authentication-service-providers)

Users [20](#users)

INTEROPERABILITY [20](#interoperability-1)

Technical Standards [20](#technical-standards)

Cross Border recognition of Legal and Policy Frameworks
[21](#cross-border-recognition-of-legal-and-policy-frameworks)

Cross-Certification [23](#cross-certification)

ACCREDITATION [24](#accreditation-1)

Authentication Service Providers Accreditation Process
[24](#authentication-service-providers-accreditation-process)

Authentication Technology Accreditation Process
[26](#authentication-technology-accreditation-process)

Audit of Policies and Practices [26](#audit-of-policies-and-practices)

CULTURAL DIFFERENCES [26](#cultural-differences-1)

AWARENESS [27](#awareness-1)

Government Awareness [27](#government-awareness)

Business Awareness [28](#business-awareness)

Individual User Awareness [29](#individual-user-awareness)

LEADERSHIP [30](#leadership-1)

Governments [30](#governments-1)

International Organisations [31](#international-organisations)

Business Corporations [31](#business-corporations)

Users and User Groups [32](#users-and-user-groups)

IT Industry [32](#it-industry)

CONCLUSION [32](#conclusion-1)

2\. Asymmetric (Public Key) CryptographY
[33](#asymmetric-public-key-cryptography)

DEFINITION [34](#definition)

TECHNOLOGY [36](#technology)

Major algorithms [36](#major-algorithms)

Key Generation [39](#key-generation)

Central Key Generation [39](#central-key-generation)

User Key Generation [40](#user-key-generation)

Token Key Generation [41](#token-key-generation)

Summary of Key Generation Issues [42](#summary-of-key-generation-issues)

Private Key Storage Media [42](#private-key-storage-media)

Hybridisation [43](#hybridisation)

INFRASTRUCTURE [43](#infrastructure)

Public Key Certificates [43](#public-key-certificates)

Basic Players [43](#basic-players)

Public Key Infrastructure [44](#public-key-infrastructure)

Typical CA Architecture [46](#typical-ca-architecture)

Relationship Between PKI Elements
[51](#relationship-between-pki-elements)

Identity and Role [52](#identity-and-role)

Hybrid Approaches to Role/Entitlement Authentication
[53](#hybrid-approaches-to-roleentitlement-authentication)

USE IN ELECTRONIC BUSINESS MODELS
[53](#use-in-electronic-business-models)

Hierarchical Public Key Infrastructure
[53](#hierarchical-public-key-infrastructure)

Bureau User CA [53](#bureau-user-ca)

Bureau Certificate Service [54](#bureau-certificate-service)

Private Label CA [54](#private-label-ca)

Organisational CA [54](#organisational-ca)

Certified Organisational CA [55](#certified-organisational-ca)

Web of Trust [55](#web-of-trust)

Geopolitical Considerations [56](#geopolitical-considerations)

Open Model [56](#open-model-1)

Closed Model [56](#closed-model-1)

Open-But-Bounded Model [56](#open-but-bounded-model-1)

USER REQUIREMENTS [57](#user-requirements-2)

CERTIFICATION MODELS [58](#certification-models-2)

Formal Certification [58](#formal-certification-1)

Informal Certification [58](#informal-certification-1)

No Certification [58](#no-certification-1)

TRUST [58](#trust-2)

Algorithms [58](#algorithms)

Key Length [58](#key-length)

The Root CA [59](#the-root-ca)

Recovery From Root CA Compromise [59](#recovery-from-root-ca-compromise)

Technical Security Issues [60](#technical-security-issues)

User Private Key Hygiene [60](#user-private-key-hygiene)

Private Key Transport [61](#private-key-transport)

Root Public Key Hygiene [61](#root-public-key-hygiene)

Root Private Key Security [62](#root-private-key-security)

LIABILITY [62](#liability-2)

Types of Liability [63](#types-of-liability)

Validation Authorities [63](#validation-authorities)

ROLES OF PARTICIPANTS [64](#roles-of-participants-2)

Competent Authority [64](#competent-authority)

Certification Authorities [64](#certification-authorities)

Registration Authorities [65](#registration-authorities)

Certificate Manufacturing Authorities
[66](#certificate-manufacturing-authorities)

Directory Service Providers [66](#directory-service-providers)

Validation Authorities [67](#validation-authorities-1)

Subjects [67](#subjects)

Relying Parties [67](#relying-parties)

ACCREDITATION [67](#accreditation-2)

Accreditation Criteria [67](#accreditation-criteria)

Standards [68](#standards)

Quality Management and Quality Assurance Certification
[70](#quality-management-and-quality-assurance-certification)

INTEROPERABILITY [70](#interoperability-2)

Technological issues [71](#technological-issues)

Infrastructure Issues [71](#infrastructure-issues)

CULTURAL DIFFERENCES [71](#cultural-differences-2)

AWARENESS [72](#awareness-2)

Government Awareness [72](#government-awareness-1)

Business Awareness [73](#business-awareness-1)

Individual User Awareness [74](#individual-user-awareness-1)

LEADERSHIP [74](#leadership-2)

Governments [74](#governments-2)

International Organisations [75](#international-organisations-1)

Business Corporations [76](#business-corporations-1)

Users and User Groups [76](#users-and-user-groups-1)

IT Industry [76](#it-industry-1)

Academic Institutes [77](#academic-institutes)

COMBINATION WITH OTHER TECHNOLOGIES (HYBRIDS)
[77](#combination-with-other-technologies-hybrids)

Appendix 1 [79](#appendix-1)

Electronic Authentication in a Multi-Format/Multi-Protocol Environment
[79](#electronic-authentication-in-a-multi-formatmulti-protocol-environment)

TERMINOLOGY [79](#terminology)

METHODS OF ACHIEVING AUTHENTICATION
[80](#methods-of-achieving-authentication)

Message Security [80](#message-security)

Envelope Security [80](#envelope-security)

Transport Security [80](#transport-security)

Network Security [80](#network-security)

Access Control [81](#access-control)

TYPES OF AUTHENTICATION [81](#types-of-authentication)

End-to-End Authentication [81](#end-to-end-authentication)

Delegated Authentication [81](#delegated-authentication)

BASIC ISSUES [81](#basic-issues)

Invalidation of a Digital Signature
[81](#invalidation-of-a-digital-signature)

Preservation of End-to-End Authentication
[82](#preservation-of-end-to-end-authentication)

POSSIBLE SOLUTIONS [83](#possible-solutions)

Proxy Agent [83](#proxy-agent)

Bypass Technique [83](#bypass-technique)

Selective Translation [84](#selective-translation)

Secured Community [84](#secured-community)

Secure Gateway [84](#secure-gateway)

3\. PUBLIC KEY INFRASTRUCTURE INTEROPERABILITY
[87](#public-key-infrastructure-interoperability)

Achieving PKI Interoperability [88](#achieving-pki-interoperability)

Terminology [90](#terminology-1)

Analysing PKI Interoperability Schemes
[91](#analysing-pki-interoperability-schemes)

Cross-Certification [91](#cross-certification-1)

Bridge Certification Authorities [95](#bridge-certification-authorities)

Unilateral Cross-Certification [95](#unilateral-cross-certification)

Cross-Recognition [95](#cross-recognition)

Liability Implications of Cross-Certification and Cross-Recognition
[99](#liability-implications-of-cross-certification-and-cross-recognition)

Legal Implications of Cross-Certification and Cross-Recognition
[99](#legal-implications-of-cross-certification-and-cross-recognition)

Certificate Trust Lists [100](#certificate-trust-lists)

Possible Areas of Work [100](#possible-areas-of-work)

Mapping of Certification Authorities Accreditation Schemes
[101](#mapping-of-certification-authorities-accreditation-schemes)

Terminology [102](#terminology-2)

Implementation Policies and Practices
[103](#implementation-policies-and-practices)

Accreditation Approach [103](#accreditation-approach)

Accreditation Roles and Interaction
[103](#accreditation-roles-and-interaction)

Accreditation Framework [106](#accreditation-framework)

INITIAL Mapping of Certification Authorities Accreditation Schemes
[108](#initial-mapping-of-certification-authorities-accreditation-schemes)

Process [108](#process)

General Comments [111](#general-comments)

Legal/Legislative Framework [111](#legallegislative-framework)

E-Government Initiatives [112](#e-government-initiatives)

Current Private Sector Environment
[112](#current-private-sector-environment)

Roles and Responsibilities [113](#roles-and-responsibilities)

Interoperability/International Dimensions
[113](#interoperabilityinternational-dimensions)

Conclusions and Areas for Future Work:
[113](#conclusions-and-areas-for-future-work)

Second Mapping of Certification Authorities Accreditation Schemes
[114](#second-mapping-of-certification-authorities-accreditation-schemes)

Process [115](#process-1)

DETAILED MAPPING OF SELECTED PKI SCHEMES
[118](#detailed-mapping-of-selected-pki-schemes)

APPENDIX 1 [119](#appendix-1-1)

Terminology Mapping [119](#terminology-mapping)

APPENDIX 2 [121](#appendix-2)

Selected Definitions of Cross-Certification
[121](#selected-definitions-of-cross-certification)

Internet X.509 PKI -- PKIX Roadmap
[121](#internet-x.509-pki-pkix-roadmap)

Electronic Commerce Promotion Council of Japan (ECOM) Certification
Authority Working Group, Cross-Certification Guidelines
[121](#electronic-commerce-promotion-council-of-japan-ecom-certification-authority-working-group-cross-certification-guidelines)

VeriSign CPS (Version 1.2) [121](#verisign-cps-version-1.2)

A Matter Of Trust \-- Deploying A Public-Key Encryption System Extends
Trust Across Boundaries, by Amy K. Larsen
[122](#a-matter-of-trust----deploying-a-public-key-encryption-system-extends-trust-across-boundaries-by-amy-k.-larsen)

Issues Relating to the Use of Electronic Authentication, APEC Electronic
Authentication Task Group
[122](#issues-relating-to-the-use-of-electronic-authentication-apec-electronic-authentication-task-group)

Entrust Technologies White Paper -- The Concept of Trust in Network
Security
[122](#entrust-technologies-white-paper-the-concept-of-trust-in-network-security)

The Burton Group Network Strategy Report - Public Key Infrastructure
Architecture
[122](#the-burton-group-network-strategy-report---public-key-infrastructure-architecture)

4\. SHARED SECRET TECHNOLOGIES [123](#shared-secret-technologies)

DEFINITIONS [123](#definitions-2)

TECHNOLOGY [125](#technology-1)

Symmetric Cryptography [125](#symmetric-cryptography)

Password/Passphrases/PINs [126](#passwordpassphrasespins)

Challenge/Response: [126](#challengeresponse)

USE IN ELECTRONIC BUSINESS MODELS
[127](#use-in-electronic-business-models-1)

Open Model [128](#open-model-2)

Closed Model [128](#closed-model-2)

Open-But-Bounded Model [128](#open-but-bounded-model-2)

USER REQUIREMENTS [129](#user-requirements-3)

CERTIFICATION MODELS [129](#certification-models-3)

TRUST [130](#trust-3)

Strength of the Secret [130](#strength-of-the-secret)

Secret Security [130](#secret-security)

LIABILITY [132](#liability-3)

ROLES OF PARTICIPANTS [133](#roles-of-participants-3)

INTEROPERABILITY [133](#interoperability-3)

ACCREDITATION [133](#accreditation-3)

CULTURAL DIFFERENCES [134](#cultural-differences-3)

AWARENESS [134](#awareness-3)

Government Awareness [134](#government-awareness-2)

Business Awareness [135](#business-awareness-2)

Individual User Awareness [135](#individual-user-awareness-2)

LEADERSHIP [135](#leadership-3)

Governments [136](#governments-3)

International Organisations [136](#international-organisations-2)

Business Corporations [136](#business-corporations-2)

Users and User Groups [136](#users-and-user-groups-2)

IT Industry [137](#it-industry-2)

COMBINATION WITH OTHER TECHNOLOGIES (HYBRIDS)
[137](#combination-with-other-technologies-hybrids-1)

APPENDIX 1 [139](#appendix-1-2)

SECRET SHARING [139](#secret-sharing)

TERMINOLOGY [141](#terminology-3)

Models for secret sharing [142](#models-for-secret-sharing)

Some known schemes [143](#some-known-schemes)

A Simplified Version of Blakley\'s Scheme
[143](#a-simplified-version-of-blakleys-scheme)

Shamir\'s Scheme [144](#shamirs-scheme)

A (t,t) Threshold Scheme [144](#a-tt-threshold-scheme)

Threshold Schemes and Discrete Logarithms
[145](#threshold-schemes-and-discrete-logarithms)

Combinatorial Structures and Secret Sharing
[146](#combinatorial-structures-and-secret-sharing)

The problem of cheaters [146](#the-problem-of-cheaters)

Realising Schemes Efficiently [146](#realising-schemes-efficiently)

Non perfect schemes [147](#non-perfect-schemes)

5\. BIOMETRIC TECHNOLOGIES [149](#section-6)

DEFINITIONS [149](#definitions-3)

TECHNOLOGY [150](#technology-2)

USE IN ELECTRONIC BUSINESS MODELS
[151](#use-in-electronic-business-models-2)

Open Model [152](#open-model-3)

Closed Model [152](#closed-model-3)

Open-But-Bounded Model [153](#open-but-bounded-model-3)

USER REQUIREMENTS [153](#user-requirements-4)

CERTIFICATION MODELS [154](#certification-models-4)

Formal Certification [154](#formal-certification-2)

Informal Certification [154](#informal-certification-2)

No Certification [154](#no-certification-2)

TRUST [154](#trust-4)

LIABILITY [155](#liability-4)

ROLES OF PARTICIPANTS [156](#roles-of-participants-4)

INTEROPERABILITY [156](#interoperability-4)

ACCREDITATION [156](#accreditation-4)

CULTURAL DIFFERENCES [157](#cultural-differences-4)

AWARENESS [157](#awareness-4)

Government Awareness [158](#government-awareness-3)

Business Awareness [158](#business-awareness-3)

Individual User Awareness [158](#individual-user-awareness-3)

LEADERSHIP [159](#leadership-4)

Governments [159](#governments-4)

International Organisations [159](#international-organisations-3)

Business Corporations [159](#business-corporations-3)

Users and User Groups [159](#users-and-user-groups-3)

IT Industry [160](#it-industry-3)

COMBINATION WITH OTHER TECHNOLOGIES (HYBRIDS)
[160](#combination-with-other-technologies-hybrids-2)

6\. OTHER TECHNOLOGIES [161](#other-technologies)

CHARACTERISTICS [161](#characteristics)

eMail Address [162](#email-address)

IP Address [162](#ip-address)

Domain Name [162](#domain-name)

Message Properties [162](#message-properties)

Signature Block [163](#signature-block)

Terminal Identifier [163](#terminal-identifier)

Trace Route Information [163](#trace-route-information)

Audit Logs [163](#audit-logs)

USE IN ELECTRONIC BUSINESS MODELS
[163](#use-in-electronic-business-models-3)

USER REQUIREMENTS [163](#user-requirements-5)

CERTIFICATION MODELS [164](#certification-models-5)

TRUST [164](#trust-5)

LIABILITY [165](#liability-5)

ROLES OF PARTICIPANTS [165](#roles-of-participants-5)

INTEROPERABILITY [165](#interoperability-5)

ACCREDITATION [165](#accreditation-5)

CULTURAL DIFFERENCES [165](#cultural-differences-5)

AWARENESS [166](#awareness-5)

Government Awareness [166](#government-awareness-4)

Business Awareness [166](#business-awareness-4)

Individual User Awareness [166](#individual-user-awareness-4)

LEADERSHIP [167](#leadership-5)

COMBINATION WITH OTHER TECHNOLOGIES (HYBRIDS)
[167](#combination-with-other-technologies-hybrids-3)

7\. HYBRID TECHNOLOGIES [168](#hybrid-technologies)

TECHNOLOGY [168](#technology-3)

Chained Technologies [168](#chained-technologies)

Secured Technologies [169](#secured-technologies)

Combined Technologies [171](#combined-technologies)

USE IN ELECTRONIC BUSINESS MODELS
[171](#use-in-electronic-business-models-4)

Open Model [171](#open-model-4)

Closed Model [172](#closed-model-4)

Open-But-Bounded Model [172](#open-but-bounded-model-4)

USER REQUIREMENTS [172](#user-requirements-6)

CERTIFICATION MODELS [173](#certification-models-6)

Formal Certification [174](#formal-certification-3)

Informal Certification [174](#informal-certification-3)

No Certification [174](#no-certification-3)

TRUST [174](#trust-6)

LIABILITY [175](#liability-6)

ROLES OF PARTICIPANTS [175](#roles-of-participants-6)

INTEROPERABILITY [177](#interoperability-6)

ACCREDITATION [177](#accreditation-6)

CULTURAL DIFFERENCES [178](#cultural-differences-6)

AWARENESS [178](#awareness-6)

Government Awareness [178](#government-awareness-5)

Academic Awareness [179](#academic-awareness)

Business Awareness [179](#business-awareness-5)

Individual User Awareness [179](#individual-user-awareness-5)

LEADERSHIP [179](#leadership-6)

Governments [179](#governments-5)

International Organisations [180](#international-organisations-4)

Business Corporations [180](#business-corporations-4)

Users and User Groups [180](#users-and-user-groups-4)

IT Industry [180](#it-industry-4)

Academic Institutes [180](#academic-institutes-1)

7\. A Brief Tutorial on Cryptography for the Novice [183](#section-7)

The Electronic World [184](#the-electronic-world)

Security Services [184](#security-services)

Pervasive Security Services [185](#pervasive-security-services)

Cryptography Fundamentals [186](#cryptography-fundamentals)

Symmetric Cryptographic Technique
[187](#symmetric-cryptographic-technique)

Symmetric Key Management [188](#symmetric-key-management)

Asymmetric Cryptographic Technique
[190](#asymmetric-cryptographic-technique)

Asymmetric Cryptography Key Management
[192](#asymmetric-cryptography-key-management)

Digital Signature [193](#digital-signature)

Certificates [196](#certificates)

8\. LEGAL ISSUES [199](#legal-issues-1)

INTERNATIONAL LEGAL FRAMEWORK [199](#international-legal-framework)

UNCITRAL Model Law on Electronic Commerce
[199](#uncitral-model-law-on-electronic-commerce)

Hague Conference on Private International Law
[202](#hague-conference-on-private-international-law)

European Commission Directive on Electronic Signatures
[202](#european-commission-directive-on-electronic-signatures)

ASSURANCE AND EVIDENCE OF LEGAL EFFECT IN CROSS BORDER TRANSACTIONS
[203](#assurance-and-evidence-of-legal-effect-in-cross-border-transactions)

Cross Certification [206](#cross-certification-2)

Bridge CA [207](#bridge-ca)

Cross Recognition [208](#cross-recognition-1)

Certificate Trust Lists [208](#certificate-trust-lists-1)

Accreditation Certificate [209](#accreditation-certificate)

Strict Hierarchy [210](#strict-hierarchy)

Delegated Path Discovery and Validation
[211](#delegated-path-discovery-and-validation)

Harmonised Trust Service Provider Status Information
[212](#harmonised-trust-service-provider-status-information)

LIABILITY [214](#liability-7)

PRIVACY [216](#privacy)

Public Key Infrastructures [217](#public-key-infrastructures)

Biometrics [220](#biometrics-1)

#  

#  {#section-1 .unnumbered}

# 1. GENERAL ISSUES RELATING TO THE USE OF ELECTRONIC AUTHENTICATION

***What is a Digital Signature ?***

It is the means by which the recipient of a transaction or message can
make an assessment as to whether to accept or reject that
transaction.[^2]

## INTRODUCTION

1.  The opening quotation was part of a Task Group report specifically
    addressing issues relating to digital signatures. However, as the
    role of the Task Group has widened to address all types of
    electronic authentication, so can the question be expanded. The
    quotation is equally relevant to all types of electronic
    authentication.

```{=html}
<!-- -->
```
22. For the purposes of both the eSecurity Task Group and this report,
    the term 'electronic authentication' covers the authentication of
    individual and organisational identity, roles and attributes.
    Electronic authentication schemes and technologies may also cover
    message integrity and non repudiation in addition to authentication.
    As part of the technology neutral approach, the following terms are
    used throughout the paper, with or without the prefix 'electronic':

  ----------------------------- -----------------------------------------
  Authenticator                 a parameter for the authentication of
                                individual or organisational identity,
                                roles or attributes that can be applied
                                by a natural person or machine;

  Authentication Technology     the technology used to generate, issue or
                                interpret an authenticator;

  Authentication Service        a body that generates, issues, receives
  Provider                      or stores all or part of an authenticator
                                and might add some further service (for
                                example a certification authority in
                                public key cryptography terms or the
                                holder of a biometric template);

  Authentication Scheme         a scheme that involves authenticators and
                                authentication service providers;

  Certificate                   an electronic document generally issued
                                by a third party that binds an
                                authenticator to a specified user

  Cross Certification           the practice of cross recognition of
                                another authentication service provider's
                                authenticator to an agreed level of
                                confidence and is normally evidenced in a
                                contract or agreement. (An extension of
                                the concept used in public key
                                infrastructures); and

  High Level Authentication     a body with responsibilities relating to
  Authority                     the activities of a number of subordinate
                                authentication service providers (For
                                example a root authority in a public key
                                infrastructure or a government licensing
                                body).
  ----------------------------- -----------------------------------------

23. It was also recognised that a number of economies are federations
    with a number of state or provincial governments that, in some cases
    may have legal jurisdiction over all or part of commerce. For that
    reason the term jurisdiction has been used rather than economy.

24. A number of alternative approaches are identified, and in some cases
    detailed, throughout this report. These are only put forward as
    possible solutions and the eSecurity Task Force does not recommend
    that member economies adopt these particular approaches. In some
    cases they will form the basis for further discussion within APEC.

## BACKGROUND

25. Electronic commerce transactions including financial, human
    resources, registrations, on-line shopping and document exchanges,
    are invoked through a number of on-line applications such as e-mail,
    web browsers and Electronic Data Interchange (EDI). As the
    transition from a paper-based legal framework to electronic means
    continues there is an increased urgency to ensure that these
    transactions are secure and, where appropriate, legally binding and
    auditable.

26. Authentication schemes provide the authenticity and, in some cases,
    integrity of transactions. As governments and private institutions
    continue to expand their electronic networks to serve the public
    directly and conduct business with organisations external to their
    own, the requirement to certify and establish a level of trust
    between the organisations becomes more important.

27. At the 15th meeting of the then Asia Pacific Economic Cooperation
    (APEC) Telecommunications Working Group (TEL) in March 1997, it was
    agreed to establish a task group to review and assemble information
    about international trends in public administration with respect to
    public key authentication. The then Public Key Authentication Task
    Group presented its preliminary report to TEL 16 in September 1997.

28. In September 1998, a workshop on public key authentication and a
    meeting of the APEC Public Key Authentication Task Group were held
    in conjunction with APEC TEL 18 in Port Moresby, Papua New Guinea.
    As a result it was agreed that the Task Group (renamed the
    Electronic Authentication Task Group) develop an awareness raising
    paper expanding on a number of issues identified as being critical
    to the implementation of electronic authentication. The paper would
    also need to identify any unique needs, either in business models or
    electronic authentication requirements, in APEC member economies and
    focus on ensuring cross border recognition of electronic
    authentication techniques within the APEC region.

29. The Task Group and Workshop identified the following issues to be
    addressed in this report:

-   definitions;

-   business models;

-   user requirements;

-   technology;

-   trust;

-   liability;

-   roles of participants;

-   interoperability;

-   accreditation;

-   cultural differences;

-   awareness; and

-   leadership.

30. The Task Group agreed to the preparation of a technology neutral
    report addressing the main issues relating to the use of electronic
    authentication. It also agreed to the production of four technology
    specific chapters addressing the following groupings of
    technologies:

-   asymmetric cryptography;

-   shared secrets;

-   biometrics; and

-   other.

31. A further two chapters were subsequently requested:

-   hybrid technologies

-   an explanation of cryptography

32. The chapters cover how the specific technologies address the issues
    raised in the main body of the report.

33. Given the complexity of issues relating to Public Key Infrastructure
    (PKI) interoperability and the legal issues relating to electronic
    authentication, these are the subject of separate chapters.

34. The chapters were presented as a series of papers from TEL 19 to TEL
    26..

## DEFINITIONS

35. The first problem encountered in examining this subject was the
    question of definitions and terminology. As electronic commerce has
    evolved certain terms have become synonymous with specific
    technologies. For example the term digital signatures is generally
    related to the use of public key cryptography and the term
    electronic signature is now used to cover other electronic signing
    processes. Similar problems emerge where a term has different
    meanings depending on where it is used. The problem became apparent
    in the preparation of this report as the term 'certification' had
    one meaning in respect of public key infrastructures and another in
    respect of standards accreditation processes.

36. In addition as noted in an Organisation for Economic Co-operation
    and Development (OECD) paper[^3] prepared for the 1998 OECD
    Ministerial Conference in Ottawa, certain terms have come to be used
    in very specific ways in technical communities but are often used
    inconsistently in policy discussions.

37. The International Organization for Standardization and the
    International Electro-technical Commission Joint Technical Committee
    on Information Technology, Sub Committee 1, Vocabulary (ISO/IEC JTC1
    SC1) has the formal task of standardising the vocabulary for
    information technology and has produced the ISO/IEC 2382 series of
    standards..

38. In many cases a term can have a different meaning depending on its
    context. It is therefore unlikely that complete consistency can be
    achieved. There is a role for member economies to contribute to and
    stimulate work in attempting to achieve the maximum degree of
    consistency. However, member economies also have a role in
    encouraging the inclusion of definitions in particular documents.
    Governments can play a leadership role by adopting this practice for
    their documents..

## ELECTRONIC BUSINESS MODELS

39. Electronic business can be categorised on the basis of the
    environment in which it operates. There are several definitions
    under discussion in various communities to categorise certification
    authorities by business model and this work can be extended to
    describe business models in general. Some of these definitions are
    discussed below:

### Open Model

40. An open model involves the use of electronic authenticators between
    users who do not have a pre-arranged or organisational relationship
    covering reliance on the particular authenticator. It assumes there
    are many parties who may rely on an authenticator but who may not
    have been known to each other at the time of issuance of the
    authenticator.

41. Typical of open models would be where a user enters into a business
    contract with a third party based on the exchange of electronic
    authenticators validated where necessary by reference to a service
    offered by an Authentication Service Provider (ASP). In this case
    the parties are independent legal entities although there may be a
    legal relationship between one of the parties and the authentication
    service provider.

42. The classic example of an open model is Internet business where two
    parties may enter into a transaction without any prior contact or
    formal arrangement.

43. The main advantage of this model is that it allows a business an
    almost unlimited field of potential clients. However in many cases
    establishment of a business relationship goes beyond simply
    authentication of identity and other aspects such as financial
    viability, ability to deliver goods etc are often established and
    taken into consideration. These could reduce the 'openness' in many
    cases.

44. ![](media/image1.wmf){width="4.833333333333333in"
    height="2.5972222222222223in"}

Figure 1 - Open Model

### Closed Model

45. A closed model is one in which authenticators are exchanged between
    users who have a pre-arranged contractual or organisational
    relationship that extends to the issue and use of authenticators.

46. Typical of closed models would be authenticators exchanged
    internally between employees of a corporation or government
    (organisational relationship) or authenticators exchanged between
    users and a hub organisation such as between a business and its
    customers or suppliers where an agreement on the use of
    authenticators exists (contractual relationship).

47. Examples of closed models would be value added networks such as EDI
    where formal agreements exist; or online merchants who request that
    a client establish an account. A number of banks have also
    established closed systems for dealing with their customers.

48. The main advantages of this model are that the business can retain
    its relationship with its client and the greater certainty in
    dealing within established relationships.

    ![](media/image2.wmf){width="4.763194444444444in"
    height="3.178472222222222in"}

Figure 2(a) - Closed Model Example 1

49. Within a closed model the absence of a central hub can lead to a
    complex web of relationships.

    ![](media/image3.wmf){width="5.011111111111111in"
    height="3.348611111111111in"}

Figure 2(b) - Closed Model Example 2

### Open-But-Bounded Model

50. There is a third model sometimes referred to as open-but-bounded. In
    this model multiple parties could rely upon an authenticator but
    limits would be placed on the possible number of relying parties and
    trust would be gained through advance agreement by known parties.

51. Typical of open but bounded models would be where a number of
    relying parties agree to accept an authenticator issued by one or
    more specified authentication service providers.

52. An example of an open-but-bounded model would be one where a
    government decides that its clients can use a single authenticator
    issued by any one of a number of authentication service providers.
    The authenticator be recognised by a number of agencies without
    there being formal agreements in place. This is the model adopted by
    the Australian Government in its Project Gatekeeper.[^4]

53. A draft paper by Michael Baum of Verisign observes[^5]:

A closer look at "open" PKIs in actual commercial practice demonstrates
a very different reality. Open PKIs often become constrained, or
bounded, just prior to use by relying parties.

54. The example quoted is somewhat different to that outlined above.
    However, there is growing recognition that open models may be
    bounded in some way.

![](media/image4.wmf){width="4.941666666666666in"
height="2.915277777777778in"}

Figure 3(a) - Open-But-Bounded Model Example 1

![](media/image5.wmf){width="4.930555555555555in"
height="2.901388888888889in"}

Figure 3(b) - Open-But-Bounded Model Example 2

55. One problem that is becoming apparent, irrespective of the business
    model, is that in the move to electronic transactions, a number of
    implementors are assuming that some form of electronic
    authentication is required. In some cases electronic authentication
    is being used in transactions where signatures are not used in the
    equivalent paper process. This can place electronic transactions at
    a disadvantage, in terms of cost and bandwidth associated with the
    authenticator and in public acceptance of electronic transactions.
    While business process re-engineering is an important element in the
    development of electronic commerce, it is important to ensure that
    some of these processes do not, inadvertently place greater demands
    on and or costs to businesses and users.

## USER REQUIREMENTS

56. Most users of electronic commerce do not and will not understand the
    complexities of the security and authentication services that they
    require in order to conduct business safely over telecommunications
    infrastructures.

57. The one thing that they do realise is that they need confidence in
    the system that they are using and confidence in the surrounding
    infrastructure. Further users also need relatively simple and
    foolproof methods of engaging the security and authentication
    services that they require.

58. The following is a list of user requirements that has been
    formulated by the World Electronic Messaging Association (WEMA[^6]).
    This is a grouping of the individual messaging associations from
    around the world.

\(a\) Encryption - it shall be possible to send encrypted messages and
attachments though any/multiple service providers

\(b\) Encryption algorithms - the messaging system shall be capable of
en(de)crypting messages using different algorithms and the algorithm
shall be transparent to the user

\(c\) En-route encryption options - there shall be different options for
en-route encryption: end to end (User Agent to User Agent) , Link
(Message Transfer Agent to Message Transfer Agent) and, Network (local
user Message Transfer Agent to remote user Message Transfer Agent)

\(d\) Authentication - there shall be bi-directional recognition of
authentication. The sender shall be able to authenticate the recipient
and the recipient the sender

\(e\) Repudiation - proof of delivery shall be such that a receiver
cannot deny having received a message. Likewise the same sort of proof
shall be available such that the sender cannot deny having sent the
message

\(f\) Encryption key lengths - there shall be no restriction on
encryption key lengths

\(g\) Confidentiality - users shall be able to specify that a message is
confidential and the service provider shall ensure that the message is
encrypted in such a fashion that no access to the message can be made
while it is in transport

\(h\) Traffic patterns - service providers shall not observe user
traffic patterns and therefore shall not be able to deduce abnormal
activity levels (eg. increased traffic prior to a merger or
acquisition).

\(i\) Virus detection - mechanisms shall be provided to protect against
and detect viruses contained in message attachments. If a virus is
detected the originator and recipient shall be warned.

\(j\) Mandatory routing - there may be times when it is desirable that a
message does not transit through certain countries, or transit through
certain service providers. There shall be a mechanism for a user to
specify a mandatory route.

59. The WEMA group is also working towards making the above requirements
    a reality.

60. The Internet Law and Policy Forum developed the following consensus
    principles[^7]:

Governments should identify and remove legal barriers that hinder the
recognition of electronic authentication.

An electronic authentication should not be denied legal effect solely
because of its electronic form.

To the fullest extent possible, national laws and jurisdictions should
recognize and give full legal effect to contractual agreements
concerning the use and recognition of electronic authentication
techniques.

Legal rules relating to electronic authentication should be made to
operate collaboratively and provide consistent results across
jurisdictions to promote the growth of electronic transactions and
establish a predictable legal environment for the use and recognition of
electronic authentication methods.

Governments should recognize that their actions with respect to
electronic authentication can create barriers to trade. Governments
should not unreasonably discriminate against electronic authentication
methods or providers from other jurisdictions or erect improper
non-tariff barriers to trade.

Governments should not require or unduly promote the use of particular
electronic authentication means or technologies.

Standards for use of electronic authentication methods or technologies
should be market-driven to meet user needs.

61. Other Business groups are working on defining their own
    requirements. This gives rise to two potential conflicts. The first
    is that inconsistencies will develop between perceived needs of the
    various business groups. The second is that governments will
    introduce policies and legislation that do not adequately meet the
    user needs. The need for continued dialogue between the different
    interests is obvious.

### Technical Requirements

62. More specifically than those items mentioned above, security
    procedures and authentication should be as transparent as possible
    for users. A user should be able to readily verify an authenticator
    incorporated in a message or transaction. Unless this procedure is
    simple or transparent, most users will not bother

### Business Process Requirements

63. Users will need to be educated in the procedures required to verify
    information in the electronic world. There needs to be discussion on
    why and when security procedures are required.

64. It is incumbent upon business entities such as the Chambers of
    Commerce and the accounting bodies to ensure consistency in the
    procedures for the electronic environment just as we have built up
    paper based procedures

### Legal Requirements

65. Users need to feel confident that any transactions or messages acted
    upon which have used correct security procedures will be backed up
    within the legal environment.

### Government Endorsement

66. Governments need to back the establishment of a global electronic
    community in which the citizens of each economy can feel as if they
    have all of the rights and responsibilities that they are accustomed
    to in the normal paper based environment.

## ELECTRONIC AUTHENTICATION TECHNOLOGIES

67. In examining authentication technologies, the Task Group identified
    four grouping as follows:

-   asymmetric cryptography;

-   shared secrets;

-   biometrics; and

-   other.

    In addition the Task Group noted there was a trend towards using a
    combination of several authentication technologies for several
    transactions. The name 'hybrid' was attached to this group.

### Asymmetric Cryptography

68. This group covers public key cryptography that many people see as
    synonymous with electronic authentication. It is also known as
    digital signature technology. Technologies in this group provide
    functions of authentication, integrity, non repudiation and
    confidentiality. Asymmetric cryptography can be used to authenticate
    identities and attributes and can be used in open, closed or open
    but bounded environments. It can also be used as a tool to ensure
    the integrity documents without using the authentication capability.
    Again this can occur in open, closed or open but bounded
    environments. An important element is the existence of public and
    secret components (known as keys) and for access to the secret
    component to be controlled by the owner. One of the policy issues is
    the question of control over secret, or private keys, particularly
    in respect of key generation which is discussed in Chapter 2. This
    technology is the only one that provides an message integrity
    capability.

69. While the concept and some technical implementations are very
    mature, it is only in recent years that the infrastructures required
    to support widescale deployment of this technology have started to
    emerge.

70. Chapter 8 contains a tutorial on cryptography while Chapter 2
    contains more detailed discussion on this group of technologies.

![](media/image6.wmf){width="5.9944444444444445in"
height="0.9298611111111111in"}

Figure 4 - Asymmetric Cryptography

### Shared Secrets

71. This group covers implementations such as symmetric cryptography;
    passwords/PINS; and challenge/response. Technologies in this group
    provide for authentication. However, only symmetric cryptography can
    provide confidentiality and integrity capabilities in some
    implementations. Depending on whether the secret is unique to each
    pair of parties, non repudiation is possible. This group mainly
    supports closed business models as the secret has to be shared
    between both parties and there is likely to be some form of
    associated arrangement. It can, however, support open but bounded
    models through a chaining arrangement where an authenticator in one
    closed system could generate authenticator for another closed
    system. For example Kerberos could be used in this way.

72. A number of the technologies in this group have been in use for many
    years. Some businesses have indicated a preference for operating on
    shared secret technologies at this stage as they are more familiar
    with the associated business risks.

73. Chapter 4 contains more detailed discussion on this group of
    technologies

![](media/image7.wmf){width="5.513888888888889in"
height="2.3472222222222223in"}

Figure 5 - Shared Secret

### Biometrics

74. This group covers a range of technologies that use personal
    characteristics as an authentication technique. It includes
    fingerprints, hand geometry, retina/iris patterns,
    signature/keyboard dynamics and voice verification. Other
    characteristics may be used in the future. Technologies in this
    group provide for authentication and non repudiation. Biometrics
    rely on the recipient being able to compare a biometric with some
    form of template or the original of the characteristic. However, it
    is possible for templates to be certified and stored for comparison
    in the same way as public keys are in asymmetric cryptography. This
    group could, therefore, support open, closed and open-but-bounded
    models.

75. Biometrics have been used for physical access control for many
    years. However these implementations were closed systems. Problems
    emerge in the protection of templates in the more open electronic
    environments. A number of implementations are using cryptographic
    techniques to protect templates and communication of biometric
    characteristics. For this reason many implementations of the
    technologies will fall under the hybrid heading.

76. Chapter 5 contains more detailed discussion on this group of
    technologies.

![](media/image8.wmf){width="5.194444444444445in"
height="2.3333333333333335in"}

Figure 6 - Biometrics

### Other

77. This group covers a number of characteristics of a message or
    transaction rather than specific technologies. These include email
    address, domain name, IP address, and the signature block on a
    message. This group only covers authentication but the technologies
    can be used in open, closed and open-but-bounded models.

78. Use of authenticators from this group is actually very wide spread.
    It is one of the most common means of authentication currently used,
    particularly in respect of email. Generally it is used in
    association with other collateral evidence such as expectation of
    the communication, shared knowledge of events or introduction by a
    third party. This results in an aggregation of trust. Its use for
    high risk/value transactions can be expected to diminish as the
    technologies discussed above become more widely available. It will,
    however, continue to play a part in both low value transactions and
    in closed systems such as organisational email for the foreseeable
    future.

79. Chapter 6 contains more detailed discussion on this group of
    technologies.

![](media/image9.wmf){width="5.152777777777778in"
height="1.3472222222222223in"}

Figure 7 - Other Email Address Example

### Hybrid

80. It is becoming apparent that in a number of instances several
    technologies are being utilised in a single transaction. PenOp uses
    signature dynamics for authentication combined with cryptography for
    message integrity. Passwords are passed over the Internet using
    cryptography (eg SSL in browsers) to protect them. Biometrics are
    being used to trigger a digital signature (asymmetric cryptography)
    which on receipt generates a Kerberos ticket (symmetric
    cryptography) to access a particular file. The question is at what
    point do you separate the authentication process from the associated
    security process. Ultimately that will be a matter for courts to
    decide and will probably vary from case to case. However the legal
    and policy frameworks for electronic authentication need to be
    flexible enough to cover these hybrid technology approaches.

81. Chapter 7 contains more detailed discussion of these approaches.

![](media/image10.wmf)

Figure 8 - Hybrid Using Three Technologies

### Selection

82. The selection of the appropriate electronic authentication
    technology is one of risk management and will vary over time as
    technologies in the different groups emerge and are superseded.
    Users will need to examine the assets they are trying to protect and
    the risk to those assets before selecting the most appropriate
    technical solution. Other issues would include cost/benefit and
    integration with other technologies. The decision is one for users
    and not for government. Legal and policy frameworks need to be
    flexible enough to allow users to make the choice of the most
    appropriate technology for their purpose. Governments may, however,
    have a role in ensuring that technologies and their implementations
    meet their stated objectives and that users are able to make
    informed choices. These issues are discussed elsewhere in this
    report.

## CERTIFICATION MODELS

83. Several of the technologies outlined in the previous section require
    a third party to certify the identity of the holder of a particular
    electronic authenticator. As early as 1996[^8] distinctions were
    being made between formal and informal certification approaches. For
    the purposes of this paper three basic certification approaches are
    considered.

### Formal Certification

84. This approach generally involves an authentication service provider
    formally taking on the role of binding a party to a particular
    electronic authenticator. A number of approaches involve
    hierarchical structures with each level being certified by a higher
    element until a peak is reached. For this reason it is also referred
    to as a chain of trust. These bodies may be established within an
    organisation or may be provided on a commercial basis. The Public
    Key Infrastructure (PKI) approach is an example of a formal
    certification approach. PKI approaches can range from small
    implementations within an organisation to elaborate hierarchical
    models that can cover millions of key holders. PKI approaches are
    addressed in more detail in Chapter 2. An series of IETF standards,
    Public-Key Infrastructure (X.509) (pkix)[^9], exists for this
    approach.

85. It is also possible for biometric templates to be bound to an
    individual party. This approach is not yet in common use and no
    standards are available.

![](media/image11.wmf){width="4.888888888888889in"
height="2.4305555555555554in"}

Figure 9 - Formal Certification

### Informal Certification

86. This approach generally involves a third party or a number of third
    parties certifying that an electronic authenticator belongs to a
    particular party. A relying party checks to see if it trusts one of
    the certifiers. This technique is used for public keys in approaches
    such as Simple Distributed Security Infrastructure (SDSI), Simple
    Public Key Infrastructure \[SPKI\] and in the PGP suite of products.
    It does not rely on the formal hierarchical structure that is common
    to formal certification and is often referred to as a web of trust.
    A number of IETF standards, Simple Public Key Infrastructure
    (spki)[^10] and PGP[^11], exists for this approach. These approaches
    are addressed in more detail in Chapter 2.

87. In theory it may be possible to informally certify biometric
    templates but no examples of such approaches could be found.

![](media/image12.wmf){width="5.458333333333333in"
height="1.6111111111111112in"}

Figure 10 - Informal Certification

### No Certification

88. A number of electronic authentication technologies do not require,
    or can exist without, any form of certification. Shared secret
    implementations require the parties to know each other before the
    secret is shared. Therefore there is no need for certification where
    this technology is used.

89. The 'other' group of technologies does not lend itself to the use of
    either formal or informal certification although it may be argued
    that some of the 'introductory' aspects such as a party advising a
    third party's email address does add some element of increased trust
    when dealing with the third party. As no 'certificate' is created or
    utilised, this approach has been included in the 'no certification'
    model.

90. Both asymmetric cryptography and biometrics can be used without
    certification.

![](media/image13.wmf){width="4.652777777777778in"
height="0.5416666666666666in"}

Figure 11 - No Certification

## TRUST

91. Much has been written about the need to develop user trust or
    confidence in the new technologies including electronic
    authentication[^12]. This includes trust that the technology can
    deliver the benefits (economic, productivity) and trust that the
    user will not be disadvantaged by using it (fraud, privacy, consumer
    issues).

92. Trust can be achieved through the development of appropriate
    technology, development of appropriate legal and policy frameworks
    and development of appropriate business practices. In all cases not
    only do these elements need to be developed but users need to be
    aware of the developments and the issues involved.

93. Many of the sections of this report are ultimately directed at
    developing frameworks that will generate user trust. For example,
    accreditation processes are designed to enable users to trust the
    technologies while legal frameworks are designed to enable users to
    trust that they can rely on the legal validity of a transaction.
    Awareness raising programs are designed to build the level of
    required trust once the appropriate frameworks are in place.

94. As these elements are discussed in more detail in this report the
    discussion will not be duplicated here.

## LIABILITY

95. Liability has been raised as one of the major issues facing users
    and authentication service providers. This issue is under active
    consideration in a number of international fora. Central to the
    discussion is whether governments should legislate in respect of
    liability or adopt a contractual approach. The issue is complicated
    by the fact that a number of economies are federations and
    jurisdiction for liability may rest with state or provincial
    governments.

96. It is likely that different jurisdictions will, at least initially,
    adopt different approaches. It will be important to ensure that
    adopting one approach does not prevent transactions with
    jurisdictions that adopt the alternative approach.

97. Liability is discussed in more detail in the Legal Issues Chapter
    (Chapter9).

## ROLES OF PARTICIPANTS

98. The Community of Interest applicable to electronic authentication
    includes:

-   Governments;

-   high level authentication authorities (optional);

-   authentication service providers; and

-   users.

99. The term 'users' includes end-entities/users/subscribers depending
    on the terminology used in a particular architecture. They may be
    independent or associated with a sponsor recognised by a
    authentication service provider. A sponsor is an organisation with
    which an end-entity/subscriber/user is affiliated (eg. employee of a
    firm).

100. The term 'Relying Party' is used in some system documentation to
     define the recipient of an authenticator who acts in reliance on
     that authenticator. By that definition authentication service
     providers and users are all relying parties during specific
     processes and exchanges in a PKI supported system.

101. All elements of the community of interest have roles particularly
     in respect of ensuring the integrity of the authentication scheme
     or schemes.

### Governments

102. It is the role of government to provide the legal, regulatory and
     policy frameworks to support electronic authentication. The balance
     of legal and self-regulatory approaches will vary from jurisdiction
     to jurisdiction. In some implementations, the activities listed
     below may be performed by government in which case it would need to
     take on the additional roles.

### High Level Authentication Authorities

103. In some cases or for some authentication technologies it may be
     decided to establish one or more high level authentication
     authorities. These may be established by government, industry
     groups or even individual organisations managing one of more
     authentication service provider. In some cases high level
     authentication authorities may be involved in the accreditation or
     licensing of their subsidiary authentication service providers.

104. Roles of high level authentication authorities could include:

-   providing or approving policy and practice statements for subsidiary
    authentication service providers;

-   ensuring compliance with applicable legal provisions, policy and
    practice statements, technical standards; and

-   facilitating cross-certification as discussed in the next section.

### Authentication Service Providers

105. It is the role of authentication service providers to:

-   advise users of the authentication service provider's policy and
    practice statements;

-   make copies of documented cross-certification agreements including
    relevant policy and practice statements available to subscribers of
    all certified and cross-certified authentication service providers;

-   revoke authenticators and publish revocation lists as required under
    the relevant policy statement;

-   perform the identification and authentication procedures stipulated
    in the applicable policy statement;

-   provide authentication and repository services consistent with the
    policy statement;

-   provide the operational, security and technical controls stipulated
    in the policy and practice statements;

-   comply with all applicable policy and legal provisions; and

-   accept liability for elements of damage and financial loss arising
    from or in connection with its services as warranted in the relevant
    policy statement or in accordance with relevant laws and
    regulations.

### Users

106. Users have roles in ensuring that:

-   no unauthorised party has had access to any secret component of an
    authenticator; and

-   all representations made to an authentication service provider in
    the course of obtaining an authenticator were true.

## INTEROPERABILITY

107. The issue of interoperability means different things to different
     people. It has been argued in some quarters that we should be
     aiming for a single globally interoperable scheme. Others support
     the concept of a number of globally interoperable schemes. As
     mentioned earlier different technologies will meet different
     requirements based on risk, cost and integration with other
     technologies. It is unlikely that the differing requirements can be
     met by a single scheme without compromising risk at one end or cost
     at the other. However too many schemes will confuse users, possibly
     increase costs as users need to implement an excessive number of
     schemes and leave users with a bewildering array of technologies
     attached to their systems. The objective should be to minimise the
     burden on users in order to encourage them to adopt electronic
     authentication and electronic commerce. Government and industry
     need to pursue an appropriate balance in consultation.

108. Interoperability covers technical interoperability, cross border
     recognition of legal and policy frameworks and, more specifically,
     cross-certification within authentication schemes.

109. A number of these issues were canvassed in the Task Group's
     Preliminary Report and are included here in an updated form.

### Technical Standards

110. International technical standards will be essential for ensuring
     interoperability of electronic authentication. A number of national
     and international standards bodies are addressing these issues.
     There is the potential for the development of inconsistent
     standards in these different arenas. In addition, a number of
     industry sectors are also developing their own systems or products
     based on proprietary or industry group standards. Clearly there is
     the potential for short term problems of interoperability with the
     various approaches. To be too dogmatic about particular standards,
     however, has the potential to stifle developments in both the
     authentication technology and the interoperability processes.

111. The standards exercise needs to be examined at two levels; detailed
     standards for particular technologies and their use, and standards
     for interoperability between the different technologies. The former
     can, to a certain extent be developed in isolation although it is
     important that interoperability be considered even at that level.
     The latter must be developed at a full international level. Even
     regional approaches have the potential for inconsistencies that can
     cause problems for inter-region interoperability. If this emerges
     as a significant problem, APEC member economies may need to take a
     pro-active role in international standards making bodies to ensure
     full interoperability is achieved.

112. A number of APEC economies are active in the international
     standards arena and can assist in progressing these issues in those
     forums.

### Cross Border recognition of Legal and Policy Frameworks

113. Some see the ideal situation as having consistent legislation
     across all jurisdictions. However, inconsistencies are already
     starting to emerge in legislative approaches in different
     jurisdictions. This problem may be exacerbated in some federal
     structures where state or provincial governments may adopt
     legislative approaches inconsistent both between each other and
     with that of the federal government. In some cases these
     inconsistencies can be quite significant for example mandatory use
     of particular authentication technologies or government licensing
     of authentication service providers versus a completely free market
     approach. Other problems arise from legislation containing detailed
     specifications of the technology and procedures that need to be
     adopted.

114. Another difficulty which arises is that, whilst particular
     legislation might be seen to be highly desirable and may be
     strongly advocated by the technical or business sectors, such
     proposed legislation might in practice be unlawful or unenforceable
     when reviewed against the legal rights provisions of the
     constitutions of, or the common laws in, other member economies. It
     is likely that some fundamental legal rights provisions are in fact
     included in all civil and common law jurisdictions and any
     proposals to introduce procedures which are not consistent with
     such fundamental legal rights, however desirable they may be from
     the technical or business viewpoint, are doomed to failure.

115. The United Nations Commission on International Trade Law (UNCITRAL)
     has developed the *Model Law on Electronic Commerce* and the *Model
     Law on Electronic Signatures*[^13]and is undertaking work on
     electronic contracts. Any significant APEC work in this area would
     be an unnecessary duplication of the work being carried out by
     UNCITRAL.

116. A number of APEC economies are active in the UNCITRAL arena and can
     assist in progressing these issues in that forum.

117. As highlighted in a number of areas throughout this report, the
     biggest danger to the interoperability of electronic authentication
     schemes is overly specific legislation or regulation. Schemes that
     mandate particular approaches to the exclusion of all others, be
     they technical, legal or procedural, will not be able to accept
     authenticators from schemes that do not adopt the same approach.
     However, schemes that adopt more flexible approaches will be able
     to accept authenticators from schemes that mandate approaches. This
     will disadvantage schemes that adopt the mandatory approach in
     terms of electronic commerce. From the broader perspective, it will
     establish barriers to international interoperability.

118. In some cases it may be possible to introduce schemes of a
     particular model for internal use within an economy. The problems
     emerge when the scheme mandates that particular type of scheme for
     all transactions regardless of where they originate. This can be
     overcome by technology neutral legislation which does not specify
     that a particular approaches must be used for transactions to be
     acceptable.

119. While this somewhat oversimplifies the problem, There will be a
     need for governments to consider how to achieve national objectives
     in some of these areas without formulating legislation which would
     have the effect of preclude schemes which operate on a different
     basis.

120. In its Preliminary Report, the Task Group recommended further work
     be carried out with other international organisations. In general,
     these are cases where positive guidance has to be given in
     addressing a problem, rather than avoiding specifying particular
     approaches. In most cases, this further work needs to be carried
     out in conjunction with other international bodies. This can be
     approached in a number of ways:

-   the establishment of a formal liaison mechanism between the
    Secretariats of the various organisations;

-   exchange of official observers for relevant meetings;

-   exchange of draft documents between members of various groups;

-   nominating representatives already members of the other bodies to
    act as liaison points; and

-   conduct of joint meetings, seminars etc.

121. In fact a combination of these approaches may be the most
     appropriate. The important thing is to establish a dialogue with
     these other bodies to ensure that work is not duplicated, or worse,
     develops in different directions.

### Cross-Certification

122. There is a requirement to establish a consistent and auditable
     level of trust between authentication schemes. A formal method of
     certification known as "cross-certification" is being
     developed[^14]. The scheme is being developed for public key
     infrastructures but the same principles can be used for other
     authentication service providers that use the same basic
     authentication technology (eg biometrics). Alternative approaches
     such as "cross recognition" are being considered and are discussed
     in Chapter 3.

123. The process of cross-certification includes legal, technical and
     policy review of each other's authentication scheme policies and
     authentication scheme practice statements, their implementation and
     operational management. This is to ensure that the authentication
     service provider of each respective domain agrees and meets the
     standards as set out in its authentication scheme policy and
     authentication scheme practice statement and that these are of
     essentially equivalent functionality. If there is agreement on
     their equivalence, a formal process leading to a mutual agreement
     in the form of a contract allows the authentication service
     providers to cross certify with each other. The process must allow
     for changes and coordinate these in a timely fashion to prevent
     interference with organisational programs and business
     transactions. Cross-certification agreements should have a fixed
     term and allow for renewal, termination and amendments.

124. Cross-certification can take place at a single or multiple levels
     of assurance. Programmed site inspection of the cross certified
     authentication service provider facilities must occur in order to
     ensure the integrity of the agreements.

125. A further issue that is starting to emerge is interoperability
     between authentication technologies and other technologies used in
     the process of generating, transmitting or receiving a transaction.
     We are already starting to see instances where authentication
     technologies can be rendered ineffective by other technologies. For
     example firewalls and gateways can reject digital signatures or
     encrypted measures as they could possibly be maleficent code or
     contain viruses. There is a need to encourage co-operation between
     product developers and implementors to ensure that unnecessary
     barriers are not erected.

## ACCREDITATION

126. One of the main issues to be addressed is whether government should
     license or regulate authentication technology or authentication
     service providers. A number of possible scenarios emerge:

-   government licensing;

-   government endorsed accreditation scheme;

-   standards based accreditation scheme; and

-   industry endorsed accreditation scheme.

127. Implementation of these schemes can be mandatory or voluntary. The
     type of approach adopted will vary from jurisdiction to
     jurisdiction determined largely by domestic policy on issues such
     as industry regulation and consumer protection. Problems will
     emerge if jurisdictions insist that authentication technologies or
     service providers satisfy their licensing or accreditation
     processes and requirements even where the service provider or user
     of the technology is located outside their immediate jurisdiction.

128. As mentioned at the outset, the key requirement of authentication
     schemes is to allow the recipient of a message or transaction to
     make an assessment as to whether to accept that transaction. To be
     able to make that judgement, the recipient needs to be aware of the
     type of accreditation the authentication scheme or technology has
     received as well as any relevant cross certification information.
     The means by which accreditation and cross-certification
     information is conveyed to a recipient needs to be standardised.

### Authentication Service Providers Accreditation Process

129. In both mandatory and voluntary schemes, the chain of confidence in
     authentication services can be established on a sound footing by
     developing an effective accreditation and certification system.
     This system relies on independent judgement being made at each
     level of the system. In the first instance, the certification
     bodies make a judgement as to whether the service provider's
     operations (ie. authentication services) complies with a relevant
     standard. The certification body is judged to be competent to carry
     out the relevant certification by an accredited body. The
     certification and accreditation processes are both carried out by
     independent bodies. With such a process in place in two countries,
     the chain of confidence can then be completed by the accreditation
     bodies making judgement in the competence of each other's programs.

130. The criteria against which the service of an applicant is assessed
     are those outlined in an international/national Standard or a
     normative document nominated by a regulatory body.

131. Depending on the development of standards and other normative
     documents internationally (or nationally) a service provider could
     apply for certification in one of the following methods:

-   If there is an international/national standard available, the
    applicant can approach a national/international certification body
    to obtain certification in its authentication operations. The
    evaluation (and the certification) work is carried out by the
    certification body (or a subcontracted body on behalf of the
    certification body). Following satisfactory compliance of the
    relevant criteria/standard the service provider receives
    certification to operate within a defined infrastructure as a
    certified authentication service provider.

-   If there are other normative documents available, the applicant can
    approach the relevant regulatory body for guidance on achieving
    certification in its authentication operations. The evaluation (and
    the certification) work is carried out by nominated evaluators on
    behalf of the regulatory body. Following satisfactory compliance of
    the relevant criteria/standard the service provider receives
    certification to operate within a defined infrastructure as a
    certified authentication service provider.

132. The following is a step by step guide to the accreditation process
     used in the standards environment:

-   **Identify what goals are required to be achieved** The typical
    objectives/goals in applying for certification will be to be more
    efficient and profitable, produce better services, achieve customer
    confidence and satisfaction, increase market share, improve
    communication within the service provider's organisation and to
    reduce costs and liabilities. Identification of what the customers
    and end users, suppliers, shareholders, community and employees
    expect of the services will also be beneficial in assessing the need
    to apply for certification.

-   **Service provider registers with the appropriate certification
    body** The service provider should contact several certification
    bodies to find out what is offered, what the likely costs are, the
    period for which the certification will apply and how frequently
    they will want to audit the system. Some certification bodies may
    include an initial pre-assessment in their offer. This can be of
    major benefit in finding out the current status and what needs to be
    done. When the service provider registers with the certification
    body, a project coordinator may be appointed by the certification
    body for liaisons, and the relevant documentation detailing
    certification requirements will also be forwarded.

-   **Service provider prepares required documentation for
    certification** The service provider should obtain information about
    the certification criteria and prepare all required documentation
    and apply the certification criteria to the authentication
    operations to ensure/demonstrate conformance.

-   **Service provider forwards relevant documentation to the
    certification body for evaluation** The certification body may carry
    out the certification work themselves or subcontract this work to a
    recognised evaluator. It may be necessary for certification bodies
    (or evaluators) to make a number of site visits or reviews of
    documentation, dependent on the need for further evaluation. For
    example, a physical security review may recommend changes to locks,
    doors etc. The service provider will need to carry out any work
    recommended and be re-evaluated to ensure compliance.

-   **The service provider obtains certification from the certification
    body** When all criteria has been reviewed to the satisfaction of
    the certification body, a certificate of certification will be
    presented to the service provider confirming that it may now
    advertise, market and operate as a certified service provider within
    a defined infrastructure. A list of certified service providers may
    also be published either by the accreditation or the certification
    body.

-   **Certification maintenance** The service provider will be required
    to maintain the certification by notifying the certification body of
    any changes in its services and carrying out a periodic audit as
    required by the certification body.

### Authentication Technology Accreditation Process

133. While accreditation of specific authentication technologies is part
     of the process of accrediting an authentication service provider,
     it can also be applied to the technology alone. This would assist
     in generating user confidence in the products that they, rather
     than the service provider would be using.

134. The steps involved are similar to those set out in the section
     above but would be limited to the product itself.

### Audit of Policies and Practices

135. An alternative to formal accreditation against standardised
     criteria is an independent audit of the assertions made in a
     service provider's policies and practices. Such audits and
     compliance statements can assist users in assessing the reliability
     of the service being provided.

## CULTURAL DIFFERENCES

136. During the course of its workshop in Port Moresby, and subsequent
     discussions, the Task Group has become aware of a number of
     cultural differences within the APEC region that can affect the way
     electronic authentication is implemented. The first difference
     noted involves various concepts of community property rather than
     identifiable individual or joint ownership of property. The
     community property concept can cover extended families or clan,
     village or tribal groupings. In many cases no single individual is
     given authority to act on behalf of the community. Many electronic
     authentication techniques have as central themes the concepts of
     binding an electronic authenticator to an individual and for the
     authenticator to be under the control of that individual. It is
     difficult to translate electronic authentication techniques that
     rely on the concept of individuals to cultures whose basic concepts
     are communal. These community property concepts are present in a
     number of APEC member economies.

137. The second difference involved the signing process and the means by
     which agents sign on behalf of the principal. In a number of Asian
     member economies, chops or seals are used rather than written
     signatures. A principal can assign an agent signing privileges by
     providing the chop or seal. In economies where written signatures
     are used, agents are provided with a written power of attorney by
     the principal and the agent applies his or her own written
     signature on behalf of the principal. Similar processes apply in
     respect of delegated authorities. Again the electronic
     authentication concept of individual control over an authenticator
     does not translate to an environment where the cultural approach is
     the transfer of the signing instrument.

138. In both the above examples, legal frameworks may be based on the
     cultural concepts.

139. These are only examples of cultural differences and have been
     presented to highlight the need for governments to be sensitive to
     the existence of cultural differences between economies. These
     cultural differences have the potential to impact on technical,
     legal and policy aspects of electronic authentication. Often
     cultural differences are not addressed in these aspects through
     ignorance rather than intent. There is a need to raise awareness of
     both cultural differences and their possible impact.

## AWARENESS

140. Electronic commerce and electronic authentication are still
     emerging disciplines. The level of awareness of both the
     technologies and their use is patchy and in many cases fraught with
     misconceptions. This is particularly the case in respect of the
     security and reliability of the technologies and their
     implementation. There is a need to raise awareness among government
     policy makers, business managers and individual users. In many
     cases it will be difficult to focus attention on just electronic
     authentication as a large proportion of the target audience will
     have wider ranging responsibilities or interests. Strategies for
     raising awareness of electronic authentication technologies and
     associated issues will often need to be integrated with broader
     electronic commerce awareness raising strategies. Specific
     electronic authentication awareness raising programs can be
     developed and targeted at selected audiences.

### Government Awareness

141. Government policy makers shape the framework within which
     electronic authentication will operate. In doing so they need to be
     aware of the international as well as national environment in which
     the technologies will be used. In most governments there are a
     large number of policy makers, very few of whom participate in
     international discussion of electronic authentication issues. This
     is particularly true in federal structures where the state or
     provincial governments are rarely directly involved in the
     international policy development process. There is a need to give
     all relevant government policy makers access to information on both
     national and international issues relating to electronic
     authentication. An awareness raising strategy could include
     newsletters, seminars and workshops and information resources.

142. Seminars and workshops need to be conducted at both the national
     and international level with the aim of meeting national objectives
     while ensuring cross border recognition of laws and policies. As
     mentioned earlier some of these activities need to address
     electronic commerce in general with electronic authentication as a
     component, while others need to be specifically designed to address
     electronic authentication issues in some detail. Part of the
     strategy would be to identify a high level champion to encourage
     attendance at these seminars and workshops.

143. In keeping with the electronic nature of the subject, electronic
     media can be used for awareness raising. There are already numerous
     electronic resources, newsletters and list servers dealing with
     electronic commerce and electronic authentication. The main problem
     is finding them. One project this Task Group has been asked to
     carry out is to establish a website that provides links to
     resources on electronic authentication. This website could be
     developed in cooperation with other international bodies.

144. Governments will not be able to carry out the leadership role nor
     develop user confidence unless able to convince their constituents
     that they have the necessary awareness of the issues and have
     developed appropriate responses.

### Business Awareness

145. Governments have an interest in encouraging the uptake of
     electronic commerce to obtain the associated economic advantages
     for the economy. Industry bodies have an interest through their
     role of maximising the efficiency and profitability of their
     members. These outcomes can only be achieved if business recognises
     the advantages of the new technologies and has the confidence to us
     them.

146. To achieve these outcomes, there are a number of areas where
     business awareness needs to be raised. These include awareness of
     the role of electronic authentication in supporting the business
     advantages of electronic commerce, awareness of the available
     electronic authentication technologies and their implementation,
     and awareness of the government and industry group frameworks to
     support electronic authentication.

147. As mentioned earlier both governments and industry have an interest
     in promoting the new technologies. It would be appropriate for
     awareness raising strategies to be developed as a cooperative
     activity between the two The identification of champions within
     industry sectors to carry the message to their colleagues is
     another important element.

148. One example of the broad role that governments can play is the
     Australian National Electronic Authentication Council (NEAC) which
     involves government, industry and users. Its role is described
     as[^15]:

In particular, NEAC will provide a national focal point on
authentication matters, encourage interoperability between different
systems and the development of relevant technical standards and provide
information and advice to industry, government and consumers.

149. The small business seminars on electronic commerce conducted by
     Australia Oceania Electronic Marketplace Association (AOEMA) in a
     number of economies under the auspices of APEC TEL are a good
     example of the type of business awareness raising programs that can
     be implemented.

150. In addition to the information resources and seminars and workshop
     approaches discussed in the previous section, another awareness
     raising activity is pilot projects. Business may be more prepared
     to participate in a pilot activity than to commit to something in
     isolation. Experiences from a pilot would increase their awareness
     and also that of their peers and clients and can contribute
     significantly to awareness raising on a sectoral or industry group
     basis. A number of pilots are being conducted in and between APEC
     economies and some are reported to APEC TEL. These reports can
     provide a valuable awareness raising resource.

151. As with government, awareness raising is part of the leadership
     role of business.

### Individual User Awareness

152. There is still considerable apprehension and misconception among
     individual users on the subject of both electronic commerce and
     electronic authentication. Much of this relates to the security of
     their transactions and payments. Unless this is overcome they will
     not utilise the new technologies.

153. While there are a number of focal points for government and
     business through which awareness raising campaigns can be directed,
     this is not the case for individuals. Any strategy for this group
     needs to have two elements. First there is a need to raise the
     awareness of and obtain support from key representative
     associations such as user groups, consumer groups etc. Second there
     is a need for broadcast campaigns through various media channels
     building, where appropriate, on any support from representative
     groups. Representative groups should be included in any awareness
     raising strategy group.

154. Word of mouth is still an important to in awareness raising; both
     in a positive and negative sense. An individual's experience in use
     of electronic authentication can influence the decisions of a
     number of associates. A negative impression will spread faster than
     a positive. It is important for business to recognise that
     failures, even in pilot projects, have an awareness raising impact.

155. The importance of information on the level of security offered in
     respect of payment systems, which would include the authentication
     technique, is raised by the OECD in its Guidelines for Consumer
     Protection in the Context of Electronic Commerce[^16] which include
     the following guideline:

Consumers should be provided with easy-to-use, secure payment mechanisms
and information on the level of security such mechanisms provide

Inclusion of such information can raise awareness of the technologies
and confidence in their use.

156. For a comprehensive comparison of the relative strengths and
     weaknesses of several forms of PKI alongside other forms of
     electronic authentication, see the article "Comparison of
     authentication technologies in e-business" in the Asia Business Law
     Review, No. 22 July 2001.

## LEADERSHIP

157. The leadership required to encourage the practical usage of
     electronic authentication clearly will vary according to the
     circumstance within each economy. The following suggests some of
     the initiatives that may be appropriate. Broadly, leadership is
     required from:

-   governments;

-   international organisations;

-   business corporations;

-   users and user groups; and

-   IT industry.

### Governments

158. The first critical requirement is that governments should publish
     as early as possible their overall policies with regard to the
     establishment of authentication schemes. Such policies need not
     initially be too detailed, but their complete absence will
     seriously impede many related developments. The private sector, and
     indeed government departments, cannot make their own plans with any
     certainty and surely will be reluctant to invest scarce capital
     resources without the reasonable probability that their own
     authentication scheme will integrate smoothly into whatever it is
     that the government proposes.

159. Possible government policy models can be very different.

-   Government may decide to leave the authentication arena wide open.
    Government may or may not establish one or more authentication
    schemes within its own departments and related organisations, the
    private sector being free to set up authentication schemes,
    commercial or otherwise, as it sees fit. There would be no high
    level authentication authority and authentication service providers
    would be responsible for ensuring interoperability with other
    service providers, domestically and internationally depending upon
    the objectives in establishing that authentication scheme. No
    licensing or technology approvals of authentication service
    providers would be required, save for the usual consumer protection
    regulations.

-   Government may decide to establish either a voluntary or mandatory
    high level authentication authority. In this case other
    authentication service providers may find the necessity to
    interoperate with the high level authentication authority if they
    wish to have their authenticator accepted outside their own systems.
    In this case, the technical and management specifications of the
    authentication service providers must be published as quickly as
    possible so that both government departments and the private sector
    may plan accordingly. Licensing and technology approvals for each
    authentication service provider could be required.

-   Government may decide to establish one central and national
    authentication service provider to the exclusion of any others
    within the economy, except perhaps for some special purpose
    authentication service providers established with government
    approval.

### International Organisations

160. Appropriate international organisations try to monitor developments
     in various economies and should regularly issue policy advice
     papers to all governments setting out the advantages and
     disadvantages of adopting particular policies, based on actual
     experience of successes and failures.

161. Such international organisations need to play a coordinating role
     to assist economies to establish authentication schemes under their
     control to interoperate with authentication schemes that are not
     under their control.

162. Some international bodies are standards bodies, and where required
     they should reach an early consensus on authentication standards
     and publish them as soon as possible.

### Business Corporations

163. Business corporations, being major users of authentication schemes,
     have a particular responsibility to adopt schemes that are
     compatible, where appropriate, with the authentication schemes
     being adopted internationally.

164. In particular, such business corporations should seek not to impose
     their authentication schemes on their trading partners, unless such
     schemes are compatible with the internationally accepted schemes.

### Users and User Groups

165. Individual users and their representative groups have a role to
     play in encouraging the uptake of electronic commerce and
     electronic authentication. Personal recommendations by individual
     users carry significant weight. These views can be built on by user
     groups who can make appropriate recommendations. On the other hand
     any adverse experiences and associated publicity can have a
     devastating effect on development.

166. Governments and industry need to work with users and user groups to
     ensure that proposals meet user requirements and users will take an
     appropriate leadership role in encouraging user uptake.

### IT Industry

167. The IT industry, especially the developers of authentication
     scheme, must strive towards, and take active steps to try to
     achieve, international interoperability.

168. It should be a guiding development principle that if a developer
     introduces an authentication technology that is, of itself, not
     interoperable with internationally accepted schemes, then that
     developer should ensure that his product is equipped with effective
     gateways to ensure international interoperability. It should not be
     necessary for the user of an internationally accepted
     authentication scheme to have to modify his international scheme in
     order to accommodate the non-international scheme.

## CONCLUSION

169. It was not the objective of the Task Group to make specific
     recommendations in this paper. Rather the paper has been prepared
     to identify relevant issues for APEC member economies and the
     various working groups of APEC that will need to consider the
     issues and develop options in consultation with the wider
     international community.

# 2. Asymmetric (Public Key) CryptographY

1.  Asymmetric cryptography is one of the most widespread and mature
    types of electronic authentication used in electronic commerce
    today. This paper deals with three concepts:

-   Public Key Technology (PKT) which is the technical implementation of
    asymmetric cryptography;

-   Digital signatures which are a specific implementation of PKT
    providing authentication, integrity and non-repudiation; and

-   Public Key Infrastructure (PKI) which is the framework established
    to support some implementations of PKT.

170. Two separate approaches are possible with a PKI:

-   Certification of public keys to allow users to authenticate
    themselves sometimes through the use of digital signatures

-   Certification of public keys to facilitate secure symmetric key
    exchange to protect the confidentiality of information

171. The OECD in its Cryptography Policy Guidelines[^17] recognised

that the use of cryptography to ensure integrity of data, including
authentication and non-repudiation mechanisms, is distinct from its use
to ensure confidentiality of data, and that each of these uses presents
different issues;

172. This paper only addresses the first approach. The second approach
     can be used to protect the confidentiality of another
     authenticator. This use is discussed in the Hybrid Technology
     Chapter (Chapter 7).

173. PKT forms the basis of most standard Internet security techniques,
     including:

-   Secure Sockets Layer (SSL) for securing transactions between
    browsers and web sites

-   S/MIME for securing e-mail

-   PGP also for securing e-mail

-   Virtual Private Networks (VPNs)

-   Wireless Application Protocol (WAP) for web-like services to mobile
    phones

-   Secure Electronic Transactions (SET), an out-dated protocol for
    credit cards on-line, and

-   Visa 3D, a new replacement for SET.

174. This paper canvasses the major issues in the use of PKT for
     authentication, in the interests of helping economies make informed
     decisions about the potential application of PKT in their
     electronic commerce applications. These issues include
     Certification Authority models, the responsibilities of all
     players, types of asymmetric key pair generation, security of
     private and public keys, and liability of Certification Authorities
     (CAs).

175. While PKT is mature and widespread in commercial Internet
     applications, PKI schemes around the world are still in their
     infancy. One reason for this is that PKT implementations have
     tended to be application or market specific, which limits the scope
     and extent of the associated PKI. For example, different relatively
     small scale PKIs might be dedicated to securing B2B banking
     applications, or healthcare transactions, or B2G tax reporting.

176. Another reason is that a number of major debates are still taking
     place, especially concerning liability of CAs, cross domain
     recognition of certificates, and methods for establishing the
     reliability of CAs. Many users including business people find these
     debates confusing, and some have decided not to commit to PKT until
     the debates have been resolved. For anyone evaluating large scale
     deployment of PKT, it is important to understand these debates.

177. This Chapter is for the most part non-technical, although a working
     knowledge of the principles and operation of asymmetric
     cryptography is assumed. For technical background on cryptography,
     please refer to the cryptography tutorial in Chapter 8

178. Given the complexity of the issues involved with, and the extensive
     work that has been done on, PKI interoperability this is discussed
     in a separate chapter (Chapter 3). Interoperability issues relating
     to PKT are discussed in this chapter.

## DEFINITION

179. The following plain language definitions have been derived from
     practical business experience, and are intended to give economies a
     better understanding of how the concepts apply in business. In some
     cases, technical definitions from international standards are also
     provided, where noted.

+--------------------+-------------------------------------------------+
| Certificate        | A mechanism for publicising public keys in such |
|                    | as way that vouchsafes their owners' identities |
|                    | and/or credentials; an electronic document      |
|                    | issued by a Certification Authority (CA), that  |
|                    | includes the owner's name, their public key, an |
|                    | indication of the Certificate Policy (CP) under |
|                    | which it was issued, and the name of the CA.    |
|                    | The certificate is digitally signed by the CA,  |
|                    | making it tamper resistant and providing        |
|                    | non-repudiation of its issuance. In most open   |
|                    | PKI systems, certificate format is governed by  |
|                    | the X.509 standard. Proprietary vendor          |
|                    | standards for digital ids may also apply.       |
+--------------------+-------------------------------------------------+
| Certificate Policy | A named set of rules that indicates the         |
| (CP)               | applicability of a certificate to a particular  |
|                    | community and/or class of application with      |
|                    | common security requirements (X.509); a         |
|                    | document which specifies the rules and          |
|                    | conditions under which a certificate is issued  |
|                    | and intended to be used.                        |
|                    |                                                 |
|                    | The CP forms the basis of any legal             |
|                    | relationship between the CA and its subjects    |
|                    | and relying parties. It broadly states what a   |
|                    | CA does and is typically published by the CA.   |
|                    | The CP should include the intended purpose of   |
|                    | the certificates, the conditions for their use, |
|                    | and the identification requirements for         |
|                    | recipients.                                     |
+--------------------+-------------------------------------------------+
| Certification      | An entity responsible for the overall process   |
| Authority (CA)     | of vouchsafing the identity and/or credentials  |
|                    | of users and issuing them with digital          |
|                    | certificates that bind their public key to      |
|                    | their identity.                                 |
|                    |                                                 |
|                    | *A party trusted to vouch for the binding       |
|                    | between names or identities and public keys.*   |
|                    | \[The Object Management Group, "CORBA           |
|                    | services", OMG Publications, 1997, Chapter      |
|                    | 15.\]                                           |
+--------------------+-------------------------------------------------+
| Certification      | A document that defines the procedures under    |
| Practice Statement | which a given CA will operate.                  |
| (CPS)              |                                                 |
|                    | The CPS broadly states how a CA performs its    |
|                    | duties (whereas the certificate policy states   |
|                    | what it does). The CPS may remain confidential  |
|                    | to the CA. It should include the technical      |
|                    | specifications of the CA systems, and all       |
|                    | personnel and physical security measures        |
|                    | undertaken at the CA.                           |
|                    |                                                 |
|                    | *A statement of the practices which a           |
|                    | certification authority employs in issuing      |
|                    | certificates.* \[American Bar Association;      |
|                    | Internet Engineering Task Force RFC2527\]       |
+--------------------+-------------------------------------------------+
| Intermediate       | A higher level certification authority which in |
| Certification      | some PKIs is responsible for certifying the     |
| Authority (ICA)    | compliance of lower CAs with their respective   |
|                    | policies and practices, and other standards. An |
|                    | ICA does not necessarily create policies; c.f.  |
|                    | PCA).                                           |
+--------------------+-------------------------------------------------+
| Policy Creating    | A "higher level" certification authority which  |
| Authority (PCA)    | in some PKIs is responsible for writing         |
|                    | certificate policies for the benefit for        |
|                    | "lower" CAs.                                    |
+--------------------+-------------------------------------------------+
| Public Key         | A system of processes, trained personnel,       |
| Infrastructure     | cryptographic technologies and controls, for    |
|                    | managing the large scale deployment of digital  |
|                    | certificates.                                   |
+--------------------+-------------------------------------------------+
| Public key         | The part of an asymmetric key pair that is      |
|                    | revealed by the owner.                          |
+--------------------+-------------------------------------------------+
| Private key        | The part of an asymmetric key pair that is not  |
|                    | revealed by the owner. Note that strictly       |
|                    | speaking the term secret key is different, in   |
|                    | that it refers to a symmetric key.              |
+--------------------+-------------------------------------------------+
| Trust anchor       | Any given CA in a certificate chain which a     |
|                    | relying party elects to trust, such that        |
|                    | certificates issued by any CA below the trust   |
|                    | anchor are trusted. Thus, a certificate chain   |
|                    | need not be parsed beyond the trust anchor.     |
|                    |                                                 |
|                    | Trust anchor is a more accurate term than root  |
|                    | CA in many cases, since technically there       |
|                    | should only ever be one root, yet many web      |
|                    | applications support a database of multiple     |
|                    | roots.                                          |
+--------------------+-------------------------------------------------+

## TECHNOLOGY

180. There are a number of proprietary implementations of public key
     technology. For that reason this section address the functionality
     the technology is designed to achieve rather than the individual
     approaches.

### Major algorithms

181. The various implementations use asymmetric cryptography and hash
     functions as described in Chapter 8. Two major asymmetric
     cryptography algorithms are in use today.

-   **RSA** (named for its three inventors, the cryptographers Rivest,
    Shamir and Adelman) is by far the dominant algorithm, used in all
    commercial SSL, S/MIME and PGP-related applications (that is, all
    WWW web site authentication and secure e-mail products). The
    algorithm is based upon the mathematics of large prime numbers and
    uses relatively long keys. The most common commercial key lengths
    are 512 and 768 bits, but 1,024 and 2,048 bit keys are increasingly
    becoming available.

-   **DSA** (Digital Signature Algorithm)[^18] is a newer technique
    specially designed for digital signatures, as opposed to general
    asymmetric cryptography. DSA is based on the mathematics of discrete
    logarithms. It is preferred for technical reasons by many
    governments, because it is said that DSA cannot be used for
    practical message encryption. DSA is not yet widely supported
    commercially.

182. The newest public key technique of any significance is so-called
     elliptic curve cryptography (ECC). Little or no commercial use has
     yet been made of ECC but it has the promise of much reduced
     signature key lengths and therefore faster performance and better
     token storage capacity.

183. There are two major hash functions or algorithms.

-   **MD5** (Message Digest) produces a 128 bit message digest or hash
    of the message.

-   **SHA** (Secure Hash Algorithm) produces a 160 bit hash of the
    message. It is designed to be used with DSA.

184. securely.

     ![](media/image14.wmf){width="0.35in"
     height="0.19566929133858268in"}

Figure 12: Registration and Certificate Issue

185. In web of trust implementations discussed below, the certification
     process may be carried out by an "introducer" instead of a CA. In
     that case there may not be a formal certificate or certificate data
     base.

186. If Alice has reason to believe her private key has been compromised
     she can ask the CA to revoke the certificate associated with the
     public key. The CA notifies revocation by including it in a
     directory known as a certificate revocation list. In some cases
     Alice may need to provide identification to prevent spurious
     revocation. In some implementations an interim step which suspends
     the certificate may also be involved.

![](media/image15.wmf){width="5.761805555555555in"
height="4.668055555555555in"}Figure 13: Certificate Revocation

187. When a relying party, Bob, receives a transaction from Alice, Bob
     validates the certificate by checking the directory and certificate
     revocation list in addition to checking the integrity of the
     message by comparing the message hash with the decrypted version of
     the encrypted message hash signed by Alice.

![](media/image16.wmf){width="5.759027777777778in"
height="3.4243055555555557in"}Figure 14: Certificate Validation

188. The elements of this process are key generation, identification
     (registration), certificate manufacture, certificate revocation,
     directory services and message validation.

### Key Generation

189. The style of key pair generation is a fundamental issue in PKT
     schemes, for the strength of non-repudiation depends upon assurance
     that nobody other than its owner has access to a private key. There
     are two basic modes of key generation: Central Generation (where
     the CA or similar entity generates a key pair on behalf of the
     subject) and User Generation (where the subject generates their key
     pair for themselves). A third mode has recently become available in
     the form of crypto tokens. This mode shares many of the properties
     of User Generation but will be treated separately below.

### Central Key Generation

190. For the purposes of discussion, in the Centralised Generation
     model, we shall speak of the CA generating the user's key pair.
     However, it is possible for the CA to have a further entity
     actually create the key pair and forward it securely to the CA
     and/or the user (an RA could generate and issue at the time of
     registration). The principles of Central key generation are the
     same whether the CA generates the keys or whether a specialised
     entity does it.

191. Historically CAs have performed key generation because it has been
     regarded as a specialist function, beyond the capabilities of the
     users themselves. The advent of SSL-capable browsers has made key
     generation software widely available at the desk top. There is an
     argument that commercial key generation software is generally of
     uncertain quality and that it is still better for the CA to
     generate the user's keys. However, this argument in practice is
     flawed as discussed in the Trust Section below.

192. When the CA generates the user's key pair, the CA must transport
     the private key using a secure method of transmission, separate
     from the public key certificate. Transport may be by encrypted
     e-mail or other electronic transmission, a PIN- or password-secured
     diskette, or may involve the use of a token. Thereafter, the user
     is responsible for the safe keeping of their private key.

193. The advantages of central key generation are as follows:

-   Assurance that the key pairs, being generated in the sophisticated
    environment of a central trusted authority, have been properly
    generated and are of a certain quality.

-   Simple from the user's point of view.

-   Better administrative control over the generation and distribution
    of the keys, and over revocation and replacement when necessary.

194. The main disadvantage of central key generation is that because
     their private keys originated in an environment outside their own
     control, the users may be able to repudiate digital signatures. The
     argument could be:

I do not dispute that the digital signature in question was created
using my private key, since it validates using my public key. But I
myself did not use my private key to create that signature - somebody
else using my private key must have created the signature. From the
moment it came into my possession, I have carefully safeguarded my
private key, so whoever used my private key to create the signature must
have copied it before I received it. Since I have no control over the
systems and staff used by the CA to create the key pair and to transmit
the private key to me, my contention is that sometime during the
generation or distribution procedures my private key was illicitly
copied and was subsequently used to create the signature in dispute.

### User Key Generation

195. In the User Generation model, the user generates the key pair for
     themselves, using software and/or hardware tools under their
     control. The user subsequently stores their private key securely,
     so that it never leaves their possession or control. The user has
     to provide the matching public key to an RA or CA, along with the
     required proof of identity and/or credentials.

196. The main advantage of user key generation is that since the key
     pair has been generated under their own control, the user can be
     held entirely responsible for the process and for the subsequent
     security of the private key. The user is therefore less able to
     repudiate their digital signature on the basis that someone else
     may be presumed to have a copy of the private key.

197. The disadvantages of user key generation are as follows:

-   Historically the key generation procedure and the subsequent
    transmission of the public key to the RA or CA may be excessively
    complex for the average user.

-   There is the possibility that key generation software becomes
    corrupted or that non-standard or inferior software is used, and
    thus the key pair may not be properly generated and may not be
    secure. Note however that trusted key generation packages are
    available which sign the keys they create, thus providing assurance
    of quality.

### Token Key Generation

198. The main advantage of user key generation is that, in principle, it
     ensures that nobody other than the user ever has access to their
     private key. This property can also be achieved by the use of newly
     available cryptographic tokens. Cryptographic devices with the same
     functionality as smartcards (that is, private key storage and
     ideally private/public key pair generation) are now available in
     different "form factors" which allow them to be used in existing
     I/O ports rather than requiring specialist readers. Most common is
     the USB token or "dongle" which can be used with the standard
     Universal Serial Bus connection. These tokens may not be as robust
     as smartcards over the long term at present but are far more
     portable, and offer the same information security features. Some
     tokens have the ability to securely generate a public-private key
     pair within the token chip and to subsequently perform all private
     key operations also within the chip. This means that the private
     key never leaves the secure environment of the token. A CA's
     operations can be designed so that personalisation of the token,
     including key generation, can be linked to user registration and
     token delivery, so that only the user ever has control over the
     private key held within.

199. Key generation has only recently become practical in tokens because
     it requires substantial processing power and memory capacity. Even
     now, few tokens feature secure key generation performed entirely
     within the chip. Scheme operators and users need to take care
     evaluating device specifications if they intend to use
     cryptographic tokens.

200. The advantages of token key generation are as follows:

-   Key generation is, in effect, entirely under the control of the user
    and so strong non-repudiation of the user's digital signature is
    achieved.

-   If the private key never leaves the token, then unapprehended theft
    of the key is much less likely than in the case of disk storage (see
    Private Key Hygiene in the Trust Section below).

201. The disadvantages of token key generation are as follows:

-   Tokens with secure key generation are still relatively expensive,
    though prices will fall.

-   Smartcard readers have yet to become widely available and in most
    cases scheme operators and/or users must pay for readers over and
    above their normal computer hardware. This is not an issue with USB
    tokens.

-   Despite their theoretical advantages, tokens are still vulnerable to
    several types of attack, ranging from sophisticated hacking of token
    reader firmware, to mundane theft of tokens and PINs. At face value,
    tokens are a compelling solution to the key generation and key
    hygiene problems but users and scheme operators must take care not
    to take the advantages for granted. As with any security system,
    care must be taken to achieve the full benefits tokens have to
    offer.

### Summary of Key Generation Issues

202. In evaluating key generation options, it is suggested that parties:

-   Pay careful attention to the issues surrounding central and user
    generation of key pairs.

-   Give preference to schemes that give users a choice of generation
    modes.

-   Encourage CAs to include information in their certificates, CP or
    CPS on how the related key pair was generated and the software,
    hardware and security environment of such generation. \[CP may be
    better unless it becomes a standardised extension\]

-   Encourage the development of user generation systems that are easy
    and friendly to use, and that will generate acceptable quality key
    pairs.

### Private Key Storage Media

203. Private keys are basically data and may theoretically be held on
     any storage media. In practice, end user keys are held on either
     diskette or hard disk drive, or on hardware tokens. Many electronic
     commerce systems also use embedded keys, installed within dedicated
     hardware such as automatic teller machines.

204. The latest model tokens have the ability to generate a public key
     pair entirely within the token, such that the private key never
     leaves the token. Thus the token may be more than merely a key
     storage medium; ideally it should also perform all of the user's
     important cryptographic processing, especially signature
     generation. Non-repudiation is greatly enhanced by this type of
     token. Users and PKT scheme operators are advised to carefully
     study token performance specifications and claims with respect to
     key generation and signature generation on the token.

205. Smartcard standards for mechanical and electrical performance have
     been stable for many years (see for example ISO 7816) but smartcard
     cryptographic processing standards are undergoing rapid development
     at present. Some guidance may be found in *ISO 10202* *Security
     Architecture of Financial Transactions Using Integrated Circuit
     Cards*. Some aspects of these standards may also be applicable to
     other forms of tokens.

### Hybridisation 

206. The area of key storage media is beginning to show some examples of
     combining PKT with biometric authentication. The commonest case is
     where access to a token is controlled by a biometric instead of
     just a PIN or passphrase. Smartcard readers are available now where
     a fingerprint must be presented before using the card and the
     private key contained within. Ideally, the biometric template
     should be stored within the card as well as the private key. This
     approach is discussed in more detail in the Hybrid Technologies
     Chapter (Chapter 7).

## INFRASTRUCTURE

207. This section describes the main functions in Public Key
     Infrastructures.

### Public Key Certificates 

208. In public key authentication, a digital signature or similar piece
     of unique identifying data is generated using one's private key,
     and is verified using the corresponding public key as discussed in
     the cryptography tutorial in Chapter 8. Evidence of the true
     identity of the private key holder is usually provided via a public
     key certificate (or "digital certificate"), a formalised data
     structure which binds the name of the holder to a copy of their
     public key. The public key certificate is itself digitally signed
     by the entity which issues it. This can be another PKT user (as is
     the case in the informal "web of trust" used in PGP) or else a more
     elaborate entity serving the needs of large numbers of users; that
     is, a "certification authority".

209. The web of trust and the CA models are discussed in more detail
     below.

### Basic Players

210. Not including regulators, the major players in any public key
     authentication scheme are as follows:

211. **Certificate Subjects** (also known as certificate "subscribers")
     possess at least one asymmetric key pair with which they create
     digital signatures to authenticate their actions in an electronic
     transaction. Their identities and/or credentials - especially their
     capacity to act - are carried in the form of a digital certificate
     and are thereby bound to their key pair. The digital certificate
     carries the public key and is used by relying parties and others to
     securely obtain the subject's public key for signature
     verification.

212. **Certificate Holders** can hold and use a certificate containing
     the public key of the issuing authority but not containing a
     certificate subject or a certificate subject public key. An
     emerging field is the use of such certificates to evidence
     entitlements or attributes.

213. Note "certificate user" is not a good term for certificate subjects
     or holders, because in an important sense, relying parties (see
     below) "use" certificates without being subjects or holders.

214. **Certificate issuers** vouch for the identities and credentials of
     subjects, and create and sign their public key certificates. They
     can also issue and sign entitlement certificates. Certificate
     issuers may be individual users or formal entities known as
     certification authorities . Depending on the model, CAs may be
     third parties, independent from the subject and their subsequent
     transactions, or else they may be related to the subject, as an
     employer for example. In some cases entitlement certificates are
     issued by another body known as an attribute authority or by an
     automated process, sometimes known as an attribute server, which
     uses an identity or credential certificate to issue the entitlement
     certificate that can be used by the certificate holder anonymously.

215. Certificate issuers also typically undertake the certification
     revocation process by issuing certificate revocation lists.

216. There has been a general shift in the last few years from the
     independent third party CA model towards more use of internal CAs
     serving the special needs of communities of interest. Both the
     independent model and the internal model are valid, as well as
     hybrids of the two

217. Architecturally, the operation of most CAs is broken down into
     front-end registration functions and backend certificate
     manufacturing and directory service functions, as discussed in more
     detail below.

218. **Relying Parties** are the counter parties to transactions
     authenticated by a subject's certificate. They receive transactions
     signed by certificate subjects and will rely upon undertakings,
     commitments, representations etc. contained within those messages
     and authenticated via the digital certificate. They may also
     receive entitlement certificates and action those entitlements.

219. The principle issue for relying parties is how to gain sufficient
     information to help them decide whether or not to accept the
     certificate and therefore accept the transaction or action the
     entitlement. In electronic commerce, the relying party may have
     never met the subject before and therefore has no basis to directly
     trust the subject. Thus the question for the relying party is how
     do they trust the CA?

### Public Key Infrastructure

220. It has been stated elsewhere that a PKI is not involved in all
     implementations of PKT. Perhaps most notable is the secure e-mail
     product "PGP" which does not require a PKI, but instead involves
     its users managing the distribution of digital certificates.
     Nevertheless, PKI is prominent in most important PKT systems, and
     so will be covered in detail in this paper.

221. The term PKI is used in many different ways, often for commercial
     marketing reasons. Some companies choose to use the term to
     encompass application software and hardware, as well as certificate
     issuance and management functions. Such a broad definition can be
     problematic however when it comes to deciding how to manage and
     regulate PKI.

222. All meaningful definitions of PKI however acknowledge the
     importance of processes as well as technology. Because a PKI is
     supposed to deliver assurances about identities and other
     information, there are significant risks, liabilities and
     compliance issues associated with it. The processes for operating
     all elements of the PKI must be rigorously understood and
     documented.

223. PKI is probably most effectively used to refer to systems -- both
     technologies and documented processes -- of inter-working
     certification authorities.

224. The fundamental purpose of a PKI is to provide the means for
     relying parties to establish trust in CAs, rather than having to be
     familiar with each CA directly before they can be trusted. PKIs
     generally involve CAs being certified by other "higher level"
     authorities, assuring the fitness for purpose of the certificates
     issued by the CAs. In an orthodox PKI, a chain of certificates is
     created that extends from an end user back to the most central CA
     in the infrastructure.

225. A **Root Certification Authority** (RCA) is the most central CA in
     a PKI. The term root CA can be confusing because it would seem to
     imply that there is only one such entity. But multiple PKIs are
     emerging around the world, on commercial bases or for local
     jurisdictional reasons, and thus we are faced with multiple root
     CAs. If this seems paradoxical, then perhaps a better term for root
     CA is **Trust Anchor**.

![](media/image17.wmf){width="5.0159722222222225in"
height="3.2736111111111112in"}Figure 15: Root Certification Authority

226. Relying parties can keep lists of all trust anchors they choose to
     recognise within their software system, signifying that all CAs
     chained back to each trust anchor will by extension also be
     trusted. The list of trusted root CAs or trust anchors is termed a
     **Trust List**. Trust lists have been subject to extensive study by
     the APEC E-Security Task Group and are reported on in Chapter 3.

### Typical CA Architecture

227. The operation of a Certification Authority can be divided into two
     or more parts, for the more effective management of the functions.
     The typical roles are for registration authorities and certificate
     manufacturing authorities. There roles are widely understood and
     are not discussed in detail. Two emerging components are directory
     service providers and validation authorities. Consequently these
     are discussed in more detail.

228. **Registration Authority** (RA) is the front-end function where
     subjects are vetted against the CA's identification rules. The RA
     is typically also responsible for revocation. The RA may be located
     at a convenient location such as customer service desk or personnel
     department.

229. If the CA's identification rules are standardised (for example, a
     nationally recognised photo identification check) then the CA may
     outsource the RA function to a bureau. In some cases, Post Offices
     have established RA functions, based on their recognised ability to
     check the identification of individual people and their extensive
     network of physical locations.

230. **Certificate Manufacturing Authority** (CMA) is the back-of-house
     function responsible for creating digital certificates in standard
     format and signing them before distribution. The CMA is usually
     located in a physically secure facility where proper care can be
     taken of the CA signing key. However if the RA is remote from the
     CMA, special security will be needed for the RA-to-CMA link,
     especially with respect to authenticating certificate requests. It
     is relatively common for a CA to outsource its CMA function to a
     specialty bureau.

231. The backend function of certificate manufacture is sometimes called
     the "CA". This can be confusing, as it blurs the distinction
     between the overall business of issuing certificates, and the
     specific backend role of manufacturing them. As discussed below,
     one legal entity usually has to take responsibility for the
     end-to-end process of registering certificate holders and
     distributing the certificates. Even if these functions are operated
     separately by different entities, there is usually one overall
     "certification authority" or CA. Therefore care must be taken when
     using the term CA to refer solely to the backend.

232. **Directory Service Providers (DSPs)** may host directories and
     CRLs on behalf of CAs. In some cases a CA may provide directory
     services for subordinate CAs. The function may be outsourced by a
     CA for reasons of availability or accessibility. The role of
     directories has been relatively neglected compared with
     registration and certificate manufacture.

233. Directories/repositories are typically used by CAs to publish the
     certificates and CRLs. These directories may or may not be publicly
     available depending on the model adopted. Relying parties who need
     to verify a digital signature can retrieve a copy of the signer's
     certificate from such a directory. If the relying party has the
     certificate but wishes to know more about the signer, they can
     usually also retrieve information about them and the CA, including
     copies of the CP etc.

234. A directory is a flexible, database-like store of information
     "objects", which may include certificates, documents, hypertext,
     software and so on. The X.500 series of standards govern
     directories, the ways to name objects, and protocols for accessing
     them. Note that X.500 describes the "Directory Access Protocol"
     (DAP) whereas the more common method for interfacing directories is
     the alternative "Lightweight Directory Access Protocol" (LDAP).
     LDAP originated as free-of-charge shareware from the University of
     Michigan in the US and has now been integrated with many commercial
     e-commerce applications.

235. Directories are not restricted to PKI and are becoming an important
     part of many e-commerce applications, including catalogues. Note
     also that directories are not in fact essential to the operation of
     a CA. Certificates are commonly distributed together with signed
     messages, so relying parties do not necessarily need to retrieve
     them from directories. And CRLs may be hosted as ordinary hypertext
     or on conventional databases. When designing a PKI scheme, it is
     therefore important to consider the costs and benefits of the
     directory function, separate from the CA function.

236. All PKIs require one or more repositories in that to store public
     key certificates and CRLs.

237. Such repositories must usually be easily and quickly accessible
     on-line by a large number of individual Digital Signature
     Verification Processors (DSVP).

238. There may be some small or closed PKIs where on-line access to the
     repository is not required, where public key certificates are
     distributed individually on disc or tokens for example and where
     CRLs are not required on-line by individual users, but such PKIs
     can be classified as special purpose applications.

239. Other special purpose applications are those PKIs where there may
     be only a single DSVP, such as in applications where a central
     facility verifies digital signatures on behalf one or more users,
     as is sometimes the case in public or private sector e-business
     gateways.

240. More usually there will be a need for the repository to be accessed
     by DSVPs as in the typical situation where, in a public or a
     private PKI, users themselves verify digital signatures on their
     own individual computer systems. In this case, depending upon the
     nature of the particular PKI application, the number of users
     needing to access the repository simultaneously may be very large.

241. A repository is, in the simplest terms, a database. However, there
     are many different types of database and in respect of PKIs the two
     most relevant types are the Relational DBMS and the Directory and
     it is important to recognise the difference between these two
     special purpose databases.

242. The primary purpose of a relational DBMS is to allow items of data
     to be related to each other. The primary purpose of a directory is
     to be able to quickly find a particular item of data, known as an
     Object in directory terms, by use of a hierarchical tree-like
     structure.

243. A relational DBMS may be employed as a PKI repository but, due to
     its relatively slow speed (as compared with a directory) to find
     and export a particular item of data, its use may be limited to
     those PKIs in which there are only a small number of separate DSVPs
     and/or where speed is not of paramount importance.

244. In PKIs where there are multiple DSVPs, for example where there are
     many individual users making a large number of simultaneous access
     attempts, and where speed is essential, then a directory is a much
     better choice for the repository.

245. Until recently, consideration of a PKI usually concentrated on two
     primary components: the RA and the CA. The repository was often
     given scant attention and was viewed as a sort of off-the-shelf
     bolt-on component with no great attention being paid to its
     specification.

246. Practical experience has now shown the importance of the
     Repository, and this can best be illustrated by comparing the
     results of a failure of each of the primary components of a PKI:

-   Failure of an RA is largely a temporary inconvenience. New users
    cannot be registered, or may have to go to another RA.

-   Failure of the CA is much more serious. New public key certificates
    cannot be issued and, far more critically, updated CRLs cannot be
    issued putting many transactions at risk.

-   Failure of the repository is very serious, verging on catastrophic.
    All those DSVPs relying on the repository (and in a big PKI there
    may be many thousands of them) will be unable to verify digital
    signatures. In a PKI serving the business community, the resultant
    disruption of commerce might cost the community untold millions of
    dollars.

247. Given its importance to the PKI as illustrated above, it is clear
     that the repository must be run in a High Availability (HA)
     environment, the primary criteria being Reliability, Availability
     and Scalability (RAS). Fortunately servers and operating systems
     are ever growing more reliable and prices are steadily falling.
     Today it is not unrealistic to attain very high levels of RAS at
     affordable cost. Moreover, directory replication technology
     provides another means of maintaining repository high availability.

248. The aim should be to run a PKI repository at an availability level
     at which a failover will be unnoticeable and transparent to the
     user, with no interruption of service and no degradation in
     performance.

249. **Validation Authorities** (or "VAs") are a new type of third party
     service, typically independent from any CA, which provides relying
     parties with information about the validity of certificates they
     receive. In some cases a CA may outsource its directory services to
     a VA.

250. Historically, the primary source of information about the validity
     of certificates has been CRLs posted in a publicly accessible
     directory by the associated CA. Traditionally, the CA that issues a
     certificate is also responsible for providing the means for the
     user to revoke it, and for maintaining and publishing the CRL.

251. The VA concept was originally based on the experience of many
     relying parties that CRLs could be hard to find. Either it was not
     obvious where to locate the directory that held the relevant CRL,
     or else that directory might not be available when it was needed.

252. CRLs suffer from a more fundamental problem, concerning the
     "latency" of update. CRLs are only updated periodically and
     consequentially there is a risk of relying unwittingly upon a
     certificate that has very recently been revoked without yet making
     it onto the CRL. In practice, the CRL update period can not be made
     too small, because of storage and communications cost tradeoffs. In
     practice, 24 hours is a typical update period. Traditionally, if
     the relying party estimates that the risk is too high to accept the
     CRL on face value, then they have to wait and re-check the CRL a
     day later, or they can try to check the sender out-of-band, perhaps
     via a phone call.

253. Yet transactions are becoming more and more automated and the
     processing cycle is shrinking. It is plainly unacceptable to wait
     24 hours before accepting a stock market transaction, and rapid
     automated processing precludes out-of-band verification. Thus it
     doesn't matter how quickly a CRL is updated; there will always be a
     window within which a certificate is potentially of unknown
     validity.

254. Downloading a CRL can be time-consuming, resource-hungry, and
     inconvenient in the event that revocation information might needed
     for just one specific certificate. A more convenient service is
     nowadays available from some CAs in the form of the Online
     Certificate Status Protocol (OCSP). This service returns a signed,
     time stamped message asserting a given certificate's validity at
     the time an inquiry is made. CAs typically charge relying parties a
     fee per OCSP inquiry.

255. The value proposition of the VA model is to offer a "one-stop shop"
     where for any given certificate, relying arties can find:

-   the applicable CRL

-   potentially, additional information about the validity or
    credentials of the certificate holder, and

-   potentially, additional access to third party data about the
    certificate holder.

256. The value of the VA model is sometimes premised on the claim that
     relying parties can increasingly expect to receive certificates
     from unknown parties, which are issued by unknown CAs. In this
     scenario, relying parties would have little or no knowledge of the
     CAs and might therefore lack access to the revocation data
     published by those CAs, or else they might lack confidence in the
     data. VAs claim that relying parties can instead retrieve
     aggregated revocation data from a single trusted source.

257. The classic VA operates by aggregating CRLs from a large number of
     CAs. A VA must encourage as many CAs as possible to send them their
     CRLs.

258. VA models are still new, but at this stage, it appears that VAs do
     not charge CAs for this service. Instead, a VA will claim to add
     value to each of the CAs by making their CRLs easier to use,
     increasing the attractiveness and accessibility of each CA's
     overall service. VAs make their money instead from charging access
     fees to relying parties.

259. With e-business spreading, especially B2B commerce, we are finding
     that parties transacting with one another are seeking more and more
     information with which to verify one another's trustworthiness or
     dependability. For example, to help decide whether or not to accept
     a high value financial transaction on-line, a relying party might
     like access to real time up-to-date information about the sender's
     credit history. It is possible that VAs might bundle such
     additional information with the basic certificate status data, to
     enhance the value of their services. This merging of data has
     privacy implications. These aspects are discussed in the Legal
     Issues Chapter (Chapter 9).

260. A related scenario is where a certificate subscriber might seek to
     use their certificate in transactions that somehow go beyond the
     original scope of their certification.

261. VAs are faced with alternative means for relying parties to gain
     access to revocation information. Chief amongst these is the "CRL
     Distribution Point", a URI (Universal Resource Indicator) where the
     CRL can be found on line. The X.509 V3 standard specifies the CRL
     distribution point as a standard extension. Many CAs now routinely
     populate this extension in the certificates they issue. Further,
     client side software such as web browsers and development toolkits
     increasingly feature automatic checking of the CRL distribution
     point as part of their certificate processing functions.

262. The CRL distribution point means that the CRL for a given
     certificate's issuer is physically accessible by relying parties
     even if they have no prior knowledge about the CA.

263. CRLs are typically considered part of the intellectual and
     commercial property of a CA and many CAs claim copyright
     protection. While a CRL is usually publicly available, a CA might
     assert its rights and so prevent VAs from collating and
     republishing the CRLs.

264. As discussed, one of the reasons for using VAs is the expectation
     that relying parties will receive certificates from unknown
     parties, which are issued by unknown CAs. On the other hand, at
     least in B2B transactions, it may be rare to receive certificates
     from a totally unexpected CA. A B2B messaging system is typically a
     sophisticated set-up involving closely allied solutions providers,
     service operators, commercial or government sponsors, and
     certification authorities. There is usually tight control over the
     certificate policy and the accreditation or approval of certificate
     issuers. Even in an open B2B system, there will be a limited number
     of CAs actually involved, and it will be rare for a previously
     unknown CA to unexpectedly start offering certificates into the
     system. Therefore it may not be the case that revocation data is
     difficult to access or trust in e-commerce.

265. The future role of VAs will depend on the business models they
     develop and the value they add for CAs and relying parties. The
     establishment of VAs is not expected to significantly impact on
     cross border recognition of certificates. Assessment processes
     relate to the publication, liability, security and privacy of
     directories and CRLs regardless of whether a CA, a VA or both carry
     out the functions.

266. VAs are in a good position going forward to enhance the ability of
     relying parties to validate transactions on a case-by-case basis.
     Without modifying the scope of the intended use of a certificate, a
     VA can make additional instantaneous business information available
     -- such as credit risk ratings, warranty protection, and business
     status -- which may help users make better use of digital
     certificates. A digital certificate only provides information about
     the holder at the time the certificate was issued, but a VA may be
     able to provide current information over and above the revocation
     status.

### Relationship Between PKI Elements

267. In some implementations, it is possible for the various elements to
     be carried out by different entities. Care needs to be taken in
     these cases. The overall effectiveness of a CA operation depends
     critically on all elements. The CA's compliance with standards and
     regulations will be determined by the elements operating in
     concert. The CA has to take overall end-to-end responsibility for
     the process of issuing and supporting certificates. Certification
     of a CA by a higher authority will require tight, auditable
     controls of all the elements. Therefore, close attention must be
     given to contracts between the CA, the RA, CMA, DSP and VA where
     these are separate sub-entities.

### Identity and Role

268. Because of the close association in business between someone's
     signature and their level of authority to sign something, digital
     certificates were quickly applied to create electronic credentials.
     It is important to separate the notions of identity and role.

269. Some commercial CAs offer general purpose digital certificates that
     establish the personal identity of the subject, to some agreed
     level of assurance. Such CAs will conform to broadly accepted,
     transparent identification protocols, such as photo identification
     checks. Most economies have a standard (either official or de
     facto) for personal identification for everyday business purposes,
     such as a passport, a national identity card or drivers licence, or
     a combination of these. CAs often pragmatically utilise the same
     standard for general identification. Indeed, the earliest bureau CA
     business models were based on simply replicating such recognised
     local standards, and digital certificates to this day are commonly
     likened to digital passports.

270. In business transactions, it is often necessary to assert your
     credentials or role in addition to your identity, or indeed instead
     of your identity; in many jobs, such as the judiciary and the
     police, anonymity may be a prime objective. Hence the concept arose
     of the role based certificate, for asserting role instead of
     personal identity.

271. Conveying role and credentials in a PKT system may be accomplished
     in several ways.

272. **Certificate extensions,** supported by the X.509 V3 standard, are
     essentially pieces of customised plain text and/or data inserted
     into the public key certificate, which can provide explicit
     indications about role. Care must be taken however to maintain
     interoperability when using custom extensions. Often the very
     presence of an extension will cause commercial software systems to
     fail.

273. **Special purpose membership certificates** issued by recognised
     organisations can form implicit credentials associated with the
     certificate issuer. For example, a recognised medical registration
     board might issue certificates only to doctors, representing their
     qualifications. Such certificates would substantiate the
     qualifications by reference in the certificate policy and practice
     statements.

274. **Attribute Certificates** can be used to separately manage the
     authentication of identity and credentials. These are created and
     signed by a trusted entity, but unlike public key certificates,
     they contain no public key for the holder. Therefore, the holder
     still needs a conventional public key certificate if they are to
     generate a digital signature of any kind.

275. Attribute certificates would usually be issued independently from
     the subject's public key certificate(s) and can explicitly
     cross-reference a public key certificate. The latter may be a
     widely recognised identity certificate.

276. Attribute certificates are relatively new and as of mid 2001, few
     commercial Attribute Authority systems had been released. When used
     in conjunction with digital signatures, attribute certificate
     systems inevitably introduce even greater complexity than PKI
     alone, because public key certificates and CAs are still required.
     Attribute certificates can be used on their own however -- with no
     digital signature function -- in pure access control applications.
     At this time, access control, especially for temporary privileges,
     is probably the major application for this technology.

### Hybrid Approaches to Role/Entitlement Authentication

277. Role can be managed separately from identity in e-business by
     hybridising a PKT system used for digital signatures, with
     conventional access control lists or directories used for mapping
     users' identities to their roles. It is important from a business
     point of view to consider such hybrid approaches, rather than
     "pure" PKT solutions, because they can help to re-use existing
     security infrastructure, and so reduce the risk of introducing an
     all-new system like PKI.

## USE IN ELECTRONIC BUSINESS MODELS

278. There are a number of PKT implementation models.

### Hierarchical Public Key Infrastructure 

279. If a relying party is not familiar with the CA that issued a given
     user's certificate, then they (the relying party) are no closer to
     being able to depend on that user's transactions. In a hierarchical
     PKI, CAs may be certified by other, "higher level" CAs, to improve
     the chances that an unknown user's certificate can be traced back
     to a known and trusted CA or trust anchor.

280. Within this hierarchical category, there are several ways to run a
     CA. The subsections below summarise the main implementation models
     for certification authorities today. For each, one key issue is
     listed relating to the selection of the appropriate CA model.

### Bureau User CA

281. The earliest commercial CA model was the bureau user CA, where a
     true third party issues personal certificates on a fee-for-service
     basis. Such certificates may be used to identify parties to
     personal or retail transactions. The bureau business depends on the
     CA having accessible service outlets and a reputable, trusted
     brand.

282. Service outlets may be bricks-and-mortar sales counters or may be
     web-based. Obviously the CAs' ability to vet identity details is
     limited when application is made over the web. Bureau CAs typically
     implement a range of certificate policies at different price
     points. Relatively more stringent certificate policies are
     available via physical, in-person service outlets.

283. **Key selection issue**: is personal identity sufficient to
     authenticate the transactions? Or are special purpose certificates
     representing role and credentials necessary?

### Bureau Certificate Service 

284. Many bureau CA businesses now offer their corporate clients an
     on-site RA, with which users may be more conveniently registered.
     In the simplest model, the CA offers its standard certificate
     policies, delegating responsibility for vetting identity details to
     the corporation. The certificate issuer is formally the bureau CA.

285. **Key selection issue**: is the CA more strongly recognised than
     the corporate organisation? If the CA has better brand recognition
     than the corporation, then certificates issued by the CA may be
     more widely recognisable and therefore more useful, than
     certificates issued directly by the corporation. On the other hand,
     if the corporation has an existing trusted role, then it may dilute
     its reputation by outsourcing the certificate issuance process.

### Private Label CA

286. If a customised certificate policy is required (usually because of
     a desire to vary the identification rules) or if a corporation
     wishes to brand its own certificates, then they can buy a "private
     label" service from some CAs. Typically the CA and the corporate
     customer will together design a certificate profile (i.e.
     customised contents) and certificate policy. Certificates are
     physically generated by the CA, based on identity data provided by
     the corporation (either from on-site RAs or from batch data). The
     certificates however are issued under the name of the corporation.
     The CA may additionally certify the corporation's signing key, in
     order to improve the recognition of the private label certificates.

287. **Key selection issue**: security and protection of member
     information exported from the corporation.

### Organisational CA 

288. Some organisations prefer not to have their certificates generated
     by a third party and so choose to operate the entire CA function
     (RA and CMA) for themselves. They may be reluctant to release their
     customer or member data to an outsider, or, if the certificate
     population is large, it may be more economical to in-source the CA
     function. There are now at least a dozen commercial products with
     which organisations can build their own CAs. A range of price
     points exist, depending on scale and performance characteristics,
     and on degree of cryptographic security.

289. **Key selection issue**: does the organisation have the skills and
     resources to run their own CA?

### Certified Organisational CA 

290. If an organisation runs its CA in isolation, then it will have to
     take responsibility for distribution of its own public key and it
     will have to satisfy its users that the CA is being correctly
     operated, fit for the purpose of its certificates. Both problems
     can be solved if an external high level CA certifies the
     organisational CA. Higher level certification involves initial
     review and ongoing audit of the organisation's CA procedures,
     especially with reference to the documented certificate policy and
     certification practice statement. See also Accreditation.

291. **Key selection issue**: as with any audit, does the higher level
     CA provide good value, with respect to process improvement, total
     cost of compliance, and recognition?

### Web of Trust

292. Fundamentally, the problem addressed by CAs is the distribution of
     users' public keys, so that all parties can determine the true
     ownership of a given key. An alternative to hierarchical PKI with
     its third party CAs is for users to take responsibility for
     identifying key holders for themselves. This approach is known as
     the web of trust. Classically, two parties that know and trust each
     another personally hand over (or exchange) their respective public
     keys, without the agency of any third party.

293. In relatively small, closed communities of users, a web of trust
     approach can work well. It has the advantages of simplicity and low
     cost. And it appeals to many people involved in highly private
     communications founded on personal trust. But for larger groups, or
     in cases where parties do not know one another, the web of trust
     has limitations. These are explained in more detail below.

294. The best known problem with the web of trust is that by itself it
     does not scale efficiently. That is, the work needed to maintain
     the web increases per user as the total user population grows. In
     the worst case, if everyone wants to trust everyone else in a web
     of trust, then for *N* users, the number of key exchanges equals
     ½N(N-1). Thus the scale of the web of trust is proportional to the
     square of the population.

295. The scaling problem has long been recognised, and is often
     addressed through introducers. If for example Alice wishes to trust
     some stranger Steve, and she knows that her friend Bob already
     trusts him, then she can have Bob introduce Steve to her. Bob
     passes a copy of Steve's public key onto Alice. By allowing
     introductions, the number of first-hand key exchanges needed to
     complete a web of trust can be made much smaller than ½N(N-1)
     (depending on just who does the introductions). An emerging trend
     in webs of trust is for introducers to maintain a directory of the
     keys of the users that are trusted within a particular community of
     interest. These directories are not generally subject to the same
     controls as those applied by CAs.

296. Introductions bring significant control issues, for they depend on
     users trusting more than just each other's identity. In the
     previous example, for Alice to trust Steve, she must trust that Bob
     knows Steve as well as she thinks she knows Bob. That is, she must
     trust Bob's processes for identifying people. This is a radical
     jump from needing to trust Bob's identity alone. Without
     independent standards and controls (usually considered too costly
     in a web of trust) uniform identification of users is difficult.

297. Regardless of the PKT model, there are several general business
     considerations.

### Geopolitical Considerations

298. Increasingly, regulators are taking an interest in certification
     authorities around the world, in the interests of providing
     appropriate assurances to consumers and businesses in electronic
     commerce. Different jurisdictions are imposing different degrees of
     control over CAs, and prescription of technologies, generally in
     accordance with their local legal code and conditions. Operators of
     CAs (be they bureaus or organisations) need to be aware of emerging
     geopolitical conditions. In particular, some jurisdictions require
     local auditability of CAs in order to recognise their certificates.

299. **Key selection issue**: what local laws and/or regulations apply
     to CAs in the jurisdiction where you plan to issue certificates?

300. CAs are sometimes categorised on the basis of the community or
     electronic business model they are deployed in or support.

### Open Model

301. In this model there are many parties who may rely on a certificate
     and who may not be known to the CA at the time of certificate
     issuance. Open model CAs are generally independent legal entities
     with respect to their subscribers and to relying parties.
     Certificates issued by an open model CA are intended for use by
     other distinct legal entities. The bureau and private labels CA
     models described above are generally examples of open model CAs.

### Closed Model

302. In this model the CA, its subscribers and all relying parties are
     all part of one legal entity. The CA may be treated simply as one
     sub-component of the entity's total business operation.

### Open-But-Bounded Model

303. In this model the types of relying parties can usually be defined
     (in terms of other communities) but individual relying parties
     cannot be identified in advance. For example, certificates issued
     to a community of medical doctors are likely to be relied upon by
     many groups, such as pharmacists, hospitals, insurance companies,
     specialists and so on. There may be existing understandings between
     these parties, based on laws, regulations, charters, conventions
     and so on. The need for additional contracts to enforce or
     recognise digital certificates needs to be examined.

304. One of the main differences between the types of business models
     concerns liability or risk faced by the CA. Open model CAs assume
     risk and liability for the business applications they serve. Closed
     model CAs are part of an overall business operation where the
     liability and risk is distributed throughout the infrastructure and
     includes the applications being run/used, the computers and
     associated telecommunications systems, procedures and
     employees/users.

305. Liability in the case of Open-But-Bounded model CAs is harder to
     assess at this point because there is relatively little experience
     of this type of model. But given the basic principle of referring
     to existing laws, regulations, charters etc., liability can be
     expected to be discernible from existing frameworks.

## USER REQUIREMENTS

306. The principal user requirements in public key systems are the same
     as for any electronic authentication system.

307. Public key solutions are particularly suited to the following
     specific requirements:

-   where the relying party has no prior relationship with the
    authenticated party, and therefore cannot depend on pre-registered
    authenticators like shared secrets or pure biometrics;

-   where an auditable electronic signature must be bound to such
    long-lived electronic transactions as contracts;

-   where the credentials of the authenticated party must be
    authenticated as well as (or instead of) their personal identity;

-   where integrity of authenticated transactions is required (integrity
    is provided automatically through digital signatures; see the
    cryptography tutorial in Chapter 8);

-   where non-repudiation of authenticated transactions is required
    (because non-repudiation is also provided automatically through
    asymmetric digital signature algorithms; see the cryptography
    tutorial in Chapter 8).

308. There are a number of specific user requirements that CAs must
     support:

-   availability of directories and certificate revocation processes
    consistent with user business requirements;

-   availability of expired certificates and CA keys (archives) to
    ensure previously validated certificates can be re-validated if
    necessary;

-   transition arrangements to ensure business continuity for users in
    the event of a CA ceasing operations;

## CERTIFICATION MODELS

309. The concept of certification of authenticators has largely
     developed in respect of the use of PKT.

### Formal Certification

310. By their very nature, public key infrastructures using
     certification authorities are formal certification models. The
     approach has been discussed in some detail above.

### Informal Certification

311. The web of trust approach provides an informal certification
     process and again is discussed in some detail above.

### No Certification

312. It is possible for the holder of a key pair to provide their public
     key to a relying party direct for example in a face to face
     situation or by a reliable electronic process. In this case there
     is no certification involved.

## TRUST

313. The level of trust in PKT is directly related to the algorithms and
     key lengths being used. However basing trust simply on algorithms
     and key length can lead to a false sense of trust as poor
     implementations in PKT and PKI are the main source of
     vulnerability. For this reason a number of key implementation
     factors are discussed below. Most users do not have the technical
     expertise to assess the efficacy of implementations in both PKT and
     PKI. Accordingly formal assessment of implementations as discussed
     in the Accreditation section below is critical to generating trust
     in PKT and PKI.

### Algorithms

314. Most commonly used algorithms are in the public arena and have been
     subject to cryptanalysis to test the efficacy. This process can
     increase trust in the algorithms.

### Key Length

315. In mathematical terms the probability of determining a private key
     is 2^n^ where n is the key length. However as some implementations
     require particular characteristics for a key (eg prime numbers),
     the actual number of potential keys can be reduced. The longer the
     key the less likely it is to be determined by cryptanalysis. In PKT
     implementations key lengths are set at a length that makes it
     computationally infeasible for a private key to be determined
     knowing the corresponding public key.

316. The probability of two messages producing the same message digest
     or hash is 2^n^ where n is the size of the message digest or hash.
     Again present implementations use hash functions that make this
     probability computationally infeasible.

317. Increases in computing power periodically result in the time
     required to "break" a key being reduced to the extent of such an
     event becoming feasible. For this reason key lengths are
     periodically increased to retain an appropriate level of trust.
     This raises issues in respect of re-validation of older
     transactions signed with shorter, now vulnerable, keys. Solutions
     such as resigning archived transactions are being investigated as
     means of addressing this problem.

### The Root CA

318. One of the key issues in building trust in public key systems has
     been the custodianship of the Root CA.

319. Only a few economies have so far decided to build central Root CAs
     (whereas quite a high number of private sector Root CAs have been
     established by commercial CAs). Several governments (typically
     those in a "light touch" mode) have felt that a government owned or
     operated public sector Root CA is not critical to the success of
     electronic commerce, while others have argued the opposite, seeing
     a role for the public good. On the other hand, the expected roles
     and responsibilities of Root CAs have not been clearly described.
     It is fair to say that the role of PKI in e-commerce is still not
     totally clear, and there is therefore no right or wrong government
     policy regarding Root CAs.

320. A Root CA obviously carries great responsibility for custody of the
     root private key, for compromise of the root key can lead to the
     creation of false CAs and, in turn, great numbers of false
     certificates. Compromise of a root CA is perhaps the worst case
     failure scenario in any PKT scheme. The root CA must therefore have
     the highest standards of physical, procedural and personnel
     security. It is for this reason that most advocates of central root
     CAs have guessed that it should be the responsibility of
     government.

321. On the other hand, under an accreditation-based PKI model, the peak
     authority in the PKI may have responsibility for accrediting or
     licensing high level CAs, who in turn independently certify low
     level CAs. In this case, the root CA function might be better taken
     on by national or trans-national accreditation bodies. The
     criticality of the root private key is not reduced in this model
     but the technological functions of creating, signing and revoking
     high level certificates can probably be outsourced to a specialist.

322. Remember that high level CA certificates will be infrequently
     issued and revoked, and neither issuance nor revocation in these
     cases is needed at short notice. This means the root private key
     does not need to be on-line or accessible by very many people,
     making it easier to protect.

### Recovery From Root CA Compromise

323. Compromise of the root CA can in theory lead to large scale
     counterfeiting of CAs and certificates. In practice, a PKI can be
     made relatively robust against this scenario through the presence
     of high level CAs intermediate between the root CA and other end
     user CAs. In much of the literature, these are known as Policy CAs
     (PCAs) or, in the case of the Australian Public Key Authentication
     Framework model (PKAF) they are simply called Intermediate CAs
     (ICAs).

324. The role of a PCA or ICA is basically to oversee the operation of
     lower level CAs and to certify the public keys of those CAs.
     ICAs/PCAs typically play a major role in the creation and/or
     oversight of certificate policies and certification practice
     statements, and therefore usually perform some sort of audit of
     CAs. These responsibilities are critical and relatively onerous; it
     follows that ICAs/PCAs will tend to be large, stable, well-known
     organisations. Furthermore, the process of becoming an ICA/PCA
     tends to be meticulous and tightly managed. Therefore, ICA/PCAs are
     generally highly trusted organisations, in their own right.

325. As a consequence, in the event of root CA compromise, ICA/PCAs can
     arguably continue to operate in their own right. If they were
     well-trusted organisations before the compromise, then they surely
     remain so afterwards. Given the types of stringent physical
     protection discussed above, it is safe to assume that a root CA
     will never be covertly compromised. That is, the compromise will be
     readily detected. In that case, an alert can be issued to all users
     to look out for unexpected new ICA/PCAs appearing in the system,
     and to only trust certificates that chain back to an existing
     ICA/PCA.

### Technical Security Issues

326. An important element in establishing trust is ensuring that
     appropriate security measures have been implemented. In any PKT
     scheme, the following specific security issues must be addressed,
     either through protective measures, risk mitigation, or both.

327. Note that the term key hygiene refers to the protection of a key
     against theft (or copying -- theft implies it is gone; it could be
     either), corruption or substitution.

### User Private Key Hygiene

328. Authentication and non-repudiation in PKT are based on the
     assumption that only one person or entity has access to a
     particular private key. It is critical therefore that access is
     appropriately controlled. The proper degree of control will depend
     to the effective value of the transactions enabled by the private
     key. Guidance should be taken from related business security
     scenarios, such as PIN-protected bank cards, building access
     control, company safes and so on. Note that cultural factors may
     have an impact as well.

329. Different private key media as described above provide different
     inherent levels of protection. If private keys are held on disk,
     users and scheme operators need to pay attention to the possibility
     of keys being stolen without detection. Of special note is the
     Caligula virus which appears to be capable of exporting private
     keys for the purposes of impersonating users. It is recommended
     that all electronic commerce transactions secured using private
     keys held on disk be carefully risk limited. For example, such
     transactions can have their value capped, or they can be made
     subject to additional, out-of-band authentication, such as written
     or telephoned confirmation.

330. The principle advantage of token storage of private keys is that it
     should prevent undetected theft of a key. Token security features
     need to be carefully studied however. Some tokens allow the private
     key to be exported or otherwise detected under varying conditions.
     Some tokens can automatically detect certain attempts to extract
     the key and may destroy the keys instead. In all cases, token
     access should be controlled by a PIN or biometric, and the same
     user behaviours should be encouraged as for the use of bank cards.

### Private Key Transport 

331. In the case of central key generation discussed above, special
     attention must be paid to the transport of the private key from the
     CA to the end user, to prevent theft or substitution. The advantage
     of known good quality key generation can be lost if the key is not
     transported securely or indeed if the key, once received by the
     user, is stored insecurely, for example on disk. This scenario has
     been likened to the use of an armoured car to transport money from
     a bank to a shop, only to have the money left out on the counter.

### Root Public Key Hygiene

332. Root keys (or trust anchors) are commonly held in databases within
     end user applications such as web browsers. Commercial software
     applications are often shipped with a number of root keys
     pre-loaded; CAs can contract application vendors for their root
     keys to be so shipped. Alternatively, a root key can usually be
     imported into the end user application environment.

333. No matter how root keys are installed in the user application
     environment, if they are held in disk storage, then there are
     significant security issues to be noted.

334. Protection of root public keys in end user PKT systems generally
     receives less attention than does protection of their own private
     keys. There have been few if any reported cases of an attack on a
     root public key but as the total value of electronic commerce
     increases, the motivation to substitute a root public key will
     increase. If an attacker successfully substituted a false key for
     the trusted root public key in a large number of end user systems,
     then the attacker could in effect masquerade as any service
     provider (including a CA) certified under that root. Root public
     keys held on disk, as is the case in all browsers today, are
     vulnerable to substitution, although a large number of systems
     would have to be targeted within a short time to mount a
     significant attack.

335. In the longer term we can expect to see root public keys housed in
     tamper resistant media like tokens. The capacity of tokens to carry
     useful numbers of root keys will be a limitation. In the meantime,
     users are advised to regularly check the state of their installed
     root public keys, by comparing them with known proper values. Most
     CAs should publish their root public key value in an inherently
     trusted (probably non-electronic) medium.

### Root Private Key Security

336. Theft of the root private key is one of the worst case scenarios
     for compromise of a public key security system. In principle, if
     the root private key (or indeed the private key of any high level
     CA in a PKI) falls into enemy hands, counterfeit CAs can be created
     and consequentially, large numbers of bogus user certificates
     released. Therefore the protection of the root private key is of
     major concern.

337. It is commonplace for root private keys to be housed (and
     generated) in secure, tamper resistant crypto modules. Access to
     the key must be carefully managed, both from technological and
     procedural points of view. Root key modules should be protected by
     additional user authentication, by PIN or biometric, and auditable
     personnel controls are essential.

338. Further protection may be afforded by split key systems, where the
     root private key, when not in use, is stored in a number of
     independent components. The components are brought together only
     when the key must be used. Each can be separately secured by PINs
     known only to the custodian of the particular component. In
     so-called M out of N systems, it is not necessary to bring all
     components of a key together, just some minimum number. This
     approach protects the system against loss of a component or
     unexpected belligerence on the part of one of the custodians. This
     approach is discussed in more detail in Appendix 1 to Chapter 4.

## LIABILITY

339. In the event that a party is damaged in an electronic commerce
     transaction as a result of a fraudulent or falsely obtained
     certificate, a key question is, what is the liability of the CA
     that issued the certificate? And further, what is the liability of
     any higher level CAs in the PKI, including the root CA? Until
     recently there has been no clear framework in which to analyse the
     liability questions.

340. The liability question has been compounded by several problems:

-   widespread electronic commerce is relatively new and there is little
    experience of the types of damages that may be suffered;

-   digital certificates are even newer and few people rely upon them as
    yet, so there appears to be no legal precedents at all;

-   It is unclear whether digital certificates constitute a product or a
    service, and therefore whether they fall under existing consumer
    protection laws and regulations which apply broadly to 'products' in
    many jurisdictions; and

-   the criticality of a CA's operation increases exponentially the
    higher up the chain the CA is, because exponentially more users may
    be affected in the event that the CA is compromised; this fact has
    led many to conclude that the liability of higher level CAs,
    especially the root CA, is prohibitive.

341. A clearer view of liability may result from formal accreditation
     and standards-certification of CAs (see also Accreditation). If a
     PKI is constructed along the lines of a standards certification
     scheme, then audit standards and principles would appear to limit
     the liability of higher level CAs and the root CA in the event that
     a lower level CA falsely issues a certificate.

342. Guidance may be taken from ISO 9000 and other certification
     schemes. For instance, liability in the event of product
     malfunction is rarely transferred to an ISO 9000 auditor, because
     of the rigorous and transparent guidelines under which auditors
     operate. In practice, liability in standards certification schemes
     in fact decreases further up the certification/accreditation chain.

### Types of Liability

343. If an accreditation process is modelled on ISO 9000, different
     types of liability may be carried by different levels of a PKI. CAs
     operating at each level make characteristically different types of
     assertions about the entities they certify, as follows.

  --------- ----------------- ------------------------- -----------------------
  **PKI     **Subordinate**   **Assertion by CA of its  **Liability carried by
  level**                     subordinate**             CA**

  Root CA   ICA/PCA           That the ICA/PCA is       Failure to comply with
                              independent and competent international generic
                                                        accreditation standards
                                                        (e.g. ISO/IEC Guide 65)

  ICA/PCA   User CA           That the CA is complying  Failure to responsibly
                              with standards and agreed audit the CA against
                              policies and practices    standards, policies and
                                                        practices

  User CA   Users or other    That the user has been    Failure to carry out
            certified         identified according to   agreed identification
            entities          the requirements stated   protocols
                              in the certification      
                              policy                    
  --------- ----------------- ------------------------- -----------------------

344. In summary, economies will have to seek their own balance between
     systemic trust and liability, in accordance with their local
     regulatory and commercial frameworks. Some may choose to enshrine
     different levels or classes of trust, with corresponding reliance
     limits or other mechanisms to control liability. The availability
     of commercial insurance policies may also affect the degree of
     intervention required by regulators.

### Validation Authorities

345. It is not yet clear who would ultimately be liable in the event
     that a relying party suffers loss arising from inaccurate or
     untimely validation information: the VA, the CA, or both. However,
     where the VA model involves a payment by the relying party this
     could address the contract privity problem that exists where
     relying parties have no relationship with the issuing CA. The VA
     may be liable to the relying party, subject to any contractual
     conditions imposed at the time of verification.

346. It may be difficult to draw general conclusions at this stage, and
     we can expect that CAs and VAs will endeavour to limit their own
     liabilities by way of contract. As a result of interposing an
     additional entity between the CA and other players, liability may
     become more complex, and users will have to take care to examine
     how to best protect their interests.

347. Another liability issue relates to the possible usage of a
     certificate in transactions that go beyond the scope of the
     original transaction, where a VA may provide relying parties with
     additional information to support new types of transaction. All CAs
     carefully circumscribe the intended purpose of their certificates
     and disclaim any usage beyond the original scope. While it may be
     tempting for a subscriber to try to use their certificate for new
     purposes without having to go through the inconvenience and cost of
     obtaining a new one, the original CA cannot be expected to be
     comfortable with changes to the scope of their certificates.

## ROLES OF PARTICIPANTS

348. Indicative or typical responsibilities for various actors in a PKI
     are set out below. Consideration should be given to documenting and
     agreeing upon such responsibilities in contracts, policies and
     practice statements in any new PKI. The lists are not exhaustive or
     exclusive.

### Competent Authority

349. Where PKI schemes are accredited or otherwise assessed a competent
     authority is established to administer the scheme. The competent
     authority would undertake the following roles:

-   Establish accreditation or assessment criteria;

-   Certify evaluators or assessors;

-   Manage the accreditation or assessment scheme; and

-   Accredit CAs and components.

### Certification Authorities

350. The CA may delegate specific roles and responsibilities to RAs
     and/or CMAs, as discussed above. The CA usually retains certain
     overall responsibilities, as follows.

-   Conform to the stipulations in a given CP;

-   Publish the CP for all subscribers and potential relying parties;

-   Document a CPS that maps explicitly to the CP;

-   Review/inspect policies and operational procedures of peer or
    subordinate CAs and negotiate enhancements and assurances of the
    operational procedures and restrictions on usage of
    cross-certificates, their validity period and any liability issues
    affecting CAs and subscribers;

-   Make copies of documented cross-certification agreements including
    relevant CPs and CPSs (optional as we say elsewhere that CPS might
    not be public) available to subscribers of all certified and
    cross-certified CAs;

-   Provide certification and repository services consistent with the
    CP;

-   Provide the operational, security and technical controls stipulated
    in the CP and CPS;

-   Revoke certificates and publish CRLs as required under the relevant
    CP;

-   Provide for timely renewal of certificates on expiration;

-   Issue certificates in accordance with the relevant CP and honour
    representations to subscribers and relying parties contained in the
    published CPS;

-   Comply with all applicable policy and legal provisions;

-   Publish certificates in a repository accessible to the user
    community;

-   Support the rights of the subscribers and relying parties who use
    certificates in accordance with applicable policy, law or
    regulations;

-   Perform the identification and authentication procedures stipulated
    in the applicable CP; and

-   Accept liability for elements of damage and financial loss arising
    from or in connection with its services as warranted in the relevant
    CP.

### Registration Authorities

351. RAs may or may not be a distinct entity from the CA. Because a CP
     is realised in concert by the registration and certificate
     manufacturing processes, an RA must be intimately related to the
     CMA.

352. The following list is very general. Items in the list may not apply
     if the RA is an agent of the CA.

-   Register with a CA and obtain approval for its operational
    procedures;

-   Conform to all relevant CP and CPS definitions in force;

-   Be accountable for its procedures in accordance with the
    requirements of the relevant CP;

-   Perform the obligations of an RA and support the right of
    subscribers and relying parties who use certificates in accordance
    with the applicable laws and regulations;

-   Provide the operational, security and technical controls stipulated
    in the relevant CP and CPS;

-   Perform the identification and authentication procedures set out in
    the CP;

-   Comply with all applicable policy and laws; and

-   Accept liability for elements of damage and financial loss arising
    from or in connection with its services as warranted in the relevant
    CP.

### Certificate Manufacturing Authorities

353. Where established separately CMAs will perform the following
     functions:

-   Conform to all relevant CP and CPS definitions in force;

-   Safeguard the CA signing key, by implementing physical and security
    controls as specified in the CP, CPS and any applicable laws and
    regulations;

-   Only use the CA signing key to sign certificates issued on behalf of
    the CA, in accordance with the CP and CPS;

-   Create certificates in accordance with the CP and CPS, on request
    from valid registered RAs;

-   Revoke certificates on request from valid registered RAs;

-   Maintain a directory or database of current certificates; and

-   Maintain and distribute CRLs.

### Directory Service Providers

354. Where a CA outsources directory services to a directory service
     provider, the DSP will undertake the following functions:

-   Conform to all relevant CP and CPS definitions in force;

-   Maintain a directory or database of current certificates; and

-   Maintain and distribute CRLs.

### Validation Authorities

355. Where established a VA would undertake the following functions:

-   Maintain a directory or database of current certificates;

-   Maintain and distribute CRLs; and

-   Notify relying parties of the status of certificates.

### Subjects 

356. Subjects (also known as certificate subscribers) must ensure that
     at the time of certificate acceptance and throughout the its
     operational life:

-   no unauthorised party has had access to the end user's private key,

-   all representations made to the CA or RA regarding the information
    published in the certificate are true, and

-   the certificate is being used for authorised and legal purposes,
    consistent with the relevant CP.

    End users may have to enter into a contract with the CA and/or make
    other legally binding assertions of the above conditions.

### Relying Parties

357. A relying party has a responsibility to undertake the following
     functions:

-   Check the CP or CA accreditation to ensure the certificate is
    appropriate for the transaction; and

-   Check the validity of any certificates received.

## ACCREDITATION

358. Accreditation can apply to both public key technology and to the
     implementation of the technology or the infrastructure supporting
     the technology. In general technology is accredited against
     standards while implementations and infrastructure are assessed
     against accreditation criteria. There are however exceptions
     discussed below.

### Accreditation Criteria

359. Accreditation criteria can be developed in both the public and
     private sectors. In a number of APEC economies they are established
     by regulation or administrative order issued in accordance with
     legislation. In most cases the accreditation criteria reference
     standards for elements of the scheme. In some cases the
     accreditation criteria form the basis for recognition of
     certificates from other jurisdictions. An issue is that in some
     economies different certificates are issued against different
     criteria. In these cases it is important to understand against
     which criteria certificates have been assessed.

360. **Regulated criteria** may be mandatory or voluntary and may also
     impact on the legal status of electronic authentication. In some
     cases the process is licensing rather than accreditation. This
     approach has been adopted by Hong Kong, China; Korea and
     Singapore[^19]; as well as by the European Union.

361. **Public sector criteria** are typically developed by governments
     for their own (government) schemes. They can be formal criteria
     (Australia Gatekeeper[^20]), or documented certificate policies and
     certification practice statements that must be complied with
     (Government of Canada PKI[^21] and US Federal Bridge[^22]).

362. **Private sector criteria** are typically developed by private
     sector organisations as a basis for independent accreditation or
     audit of implementations. The American Bar Association[^23]has
     developed PKI Assessment Guidelines. These do not, in themselves,
     form part of a formal accreditation scheme but facilitate an
     assessment of reliability of certificates issued by an assessed CA.
     Similarly the American Institute of Certified Public Accountants
     and the Canadian Institute of Chartered Accountants have jointly
     developed WebTrust for Certification Authorities[^24] which
     provides a "seal" following an audit of the CA. The scheme has been
     adopted by auditors in other countries

363. The fact that accreditation criteria differ, and may reference
     different standards, has been identified as a major impediment to
     cross-border recognition in the CA mapping exercise conducted by
     the PKI Interoperability Expert Group. This is discussed in detail
     in Chapter 4. The legal implications are discussed in the Legal
     Issues Chapter\
     (Chapter 9).

### Standards

364. There are a number of standards that relate to PKT. Some of these
     are absolute while others may involve differing levels of
     compliance. As with accreditation criteria it is important that
     users are aware of the level at which compliance has been
     established. Key standards include:

365. **The International Telecommunications Union (ITU)** has published
     the X.500[^25] series of recommendations relating to the use of
     directories in Open Systems Interconnection. The most important of
     these recommendations for PKI is X.509 *Public Key and Attribute
     Certificate Frameworks*. Version 3 of this recommendation is the
     most commonly used although some implementations use earlier
     versions.

366. **The International Organization for Standardization/International
     Electro-technical Commission (ISO/IEC)** have jointly developed a
     number of standards[^26] relevant to accreditation of PKT and CAs.
     These fall into two groups; IT security and electronic
     authentication. These standards can assist in accrediting a CA's
     operations and the technology being used. Of significance is the
     ISO/IEC 15408 series *Information technology \-- Security
     techniques \-- Evaluation criteria for IT security* which is used
     for the evaluation of the technology used in a PKI and ISO/IEC
     17799 *Information technology \-- Code of practice for information
     security management* which can be used for the evaluation of PKI
     implementations.

367. **The Internet Engineering Task Force (IETF)** Public-Key
     Infrastructure (X.509) (pkix) Working Group has issued a number of
     *Request for Comments*[^27]. The most significant of these are *RFC
     2459* *Internet X.509 Public Key Infrastructure Certificate and CRL
     Profile* and *RFC 2527 Internet X.509 Public Key Infrastructure
     Certificate Policy and Certification Practice Framework*. While the
     IETF does not have the traditional authority of national and
     international standards bodies, it has proven to be the most
     important force for standardisation in Internet technologies, and
     many of the RFCs are adopted or referenced by more formal standards
     making bodies.

368. **Federal Information Processing Standards(FIPS)**[^28] are
     developed by the US National Institute of Standards and Technology
     (NIST). The most significant for PKI is *FIPS 140 Security
     requirements for Cryptographic Modules*. This standard is widely
     used for evaluation of cryptographic modules as part of the
     accreditation process.

369. **The Certificate Issuing and Management Components (CIMC)**[^29]
     is a family of protection profiles developed by NIST that defines
     requirements for components that issue, revoke, and manage public
     key certificates. A CIMC consists of the hardware, software, and
     firmware components but not the facility, staff or operational
     procedures. A CMIC in conjunction with ISO/IEC 15480 can be used to
     accredit elements of a PKI.

370. **Public Key Cryptography Standards (PKCS)**[^30] developed by RSA
     Security Incorporated working with a number of product developers,
     are a series of commercial yet widely respected interface standards
     for keys, certificates and cryptographic devices.

371. **The European Electronic Signature Standardization Initiative
     (EESSI)** was launched in 1999, in response to the EU Electronic
     Signature Directive, by industry, business and the European
     standards organisations ETSI (European Telecommunications Standards
     Institute) and CEN/ISSS (Comité Européen de Normalisation,
     Information Standardization System). The program is defined and
     co-ordinated by the EESSI Steering Group; the standards[^31] are
     developed and maintained by ETSI and CEN/ISSS. The program operates
     under mandate of the European Commission. While these standards are
     primarily directed towards Europe, they also impact on the
     accreditation process for PKI schemes that wish to be recognised in
     Europe. APEC is working with EESSI to facilitate European
     recognition of schemes accredited in APEC economies.

372. **Domestic standards bodies** are also involved in the development
     of standards for the use of PKI and operation of PKIs. Standards
     Australia has developed a series of standards *AS 4539: Information
     technology -- Public Key Authentication Framework (PKAF) related
     Standards*[^32]*.* In Australia and other economies standards have
     been developed for the use of PKT in specific industry sector,
     particularly the health and banking sectors.

### Quality Management and Quality Assurance Certification

373. Like any organisation, CAs may be certified under general standards
     like *ISO 9000: Quality Management and Quality Assurance
     Standards*. In many economies, mature accreditation schemes are in
     place for establishing the authority of independent Certification
     Bodies. Interoperability of CAs and PKIs may be enhanced by
     independent certification and accreditation. There is one proposal
     that involves certification and accreditation certificates for CAs
     being issued in X.509 format and these being used to create the
     certificate chain from user to Root CA.

374. Similarly assurance can be assessed using the Statement on Auditing
     Standards (SAS) No. 70, *Service Organizations*[^33] developed by
     American Institute of Certified Public Accountants. This approach
     has been used by a number of CAs.

## INTEROPERABILITY

375. Interoperability in public key authentication can be a confusing
     topic. Care must be taken not to confuse levels of
     interoperability.

376. At the lowest level, note that certificates themselves do not
     interoperate. If two users exchange digitally signed messages, then
     in order to validate the messages, they require one another's
     digital certificates. The validity of the certificates is assessed
     independently, perhaps with reference to the respective PKIs and
     Root CAs. At a minimum, all that is required is for each user's
     system to hold the trusted root key or trust anchor of the other
     user's PKI. The certificates remain independent at all times.

### Technological issues

377. There is a range of low level issues which affect the ability to
     distribute, install and use certificates. These issues may need
     attention from software developers and other technical staff:

-   **Algorithm support** for both cryptographic and hashing processes
    are necessary if digital signatures are to be recognised. The use of
    proprietary algorithms can prevent interoperability

-   **Application Programming Interfaces** (APIs) exist which specify
    the interchange of data including certificates between computers and
    CAs and other entities. One important set of APIs is the PKCS series
    from RSA Data Securities Incorporated in the USA.

-   **Smartcard interface standards** have been stable for some time at
    the electrical and mechanical engineering levels. Standards for the
    interchange of keys and certificates are relatively new however.

-   **Certificate syntax** is specified by standards such as X.509 V3.
    Most World Wide Web and many secure e-mail applications use X.509
    V3. Note that while X.509 V3 allows for customised extensions not
    all commercial applications fully or properly implement the
    standard. It is always possible for applications to crash when faced
    with non-standard certificate extensions.

-   **Directory access protocols** are used to validate certificates.
    While standards exist for several protocols, the relying party and
    the CA or DSP must be able to use or accept the same protocol to
    validate a certificate.

378. A recently identified interoperability problem unique to digital
     signatures is the impact of message reformatting to meet protocol
     requirements of particular message transport schemes. These
     proprietary protocols are quite common in the business world. The
     reformatting of a message will automatically invalidate the digital
     signature associated with that message. This problem and possible
     solutions is discussed in Appendix 1 to this Chapter.

### Infrastructure Issues

379. Due to their complexity PKI interoperability issues are discussed
     separately in Chapter 4.

## CULTURAL DIFFERENCES

380. The rollout of PKI has been beset by confusion and misapprehension,
     in different parts of the world, much of which has, in part, a
     cultural angle.

381. In some economies, there is a historical suspicion of "hierarchies"
     and this has made it hard to accept orthodox PKI structures,
     regardless of whether they involve top-down or bottom-up policy
     distribution. In places this has inhibited the construction of
     central root CAs, with the result that PKI rollout can become
     fragmented. Note that in itself this might not be a bad thing,
     since there can be other reasons for PKI to be de-centralised.
     There is little evidence that the absence of centralised root CAs
     has had negative effects on e-business overall.

382. An associated issue in some economies is that the concept of a
     single national identifier does not have community support.
     Governments in these economies have generally adopted decentralised
     approaches to minimise any community perceptions of the creation of
     single electronic national identifiers.

383. In some economies, there has been greater enthusiasm for strongly
     hierarchical PKIs, often based on a recognised national photo
     identity system. By the same token, commercial uptake of national
     CAs has generally been slow, and so it cannot be argued
     convincingly that the presence of centralised PKI ensures success
     in e-business.

## AWARENESS

384. There is a bewildering amount of information available on PKT and
     PKI. Much of it is available on the web. In some cases the
     information relates to specific implementations and can be
     confusing if considered out of context.

385. Key concerns for business and individual users include:

-   Selection of technology;

-   Roles and responsibilities;

-   Legal effect of transactions;

-   Security of transactions;

-   Interoperability;

-   Privacy;

-   Consumer protection and dispute resolution.

386. There is also a need for PFT product developers and vendors and PKI
     implementors to be aware of the legal, policy and technical
     standards frameworks of economies and jurisdictions in which their
     products might be used.

387. These issues need to be addressed in any awareness raising
     activities. It is in this context that this report has been
     produced.

### Government Awareness

388. While there is general awareness of the concepts of PKT and PKI in
     government, there is less understanding of the detail of the issues
     involved. Furthermore the focus up until recently has been on
     domestic issues without considering the international
     interoperability aspects of implementations. In recent years a
     number of resources on the use of PKT and PKI and the international
     interoperability aspects have emerged. However in many cases the
     international activities have yet to be reflected in domestic
     approaches. In other cases domestic interpretations of
     international approaches continue to cause problems. This is
     discussed in more detail Chapters 4 and 9.

389. A number of economies have produced awareness raising documents on
     both PKI and other security and authentication aspects of
     electronic commerce. The eSecurity Task Group is in the process of
     establishing a website to facilitate access to these resources.

390. One of the principal problems has been a lack of a common
     understanding of the concepts and terminology associated with the
     implementation of PKI. This is an issue that needs to be addressed
     by international groups including vendor and standards making
     groups.

### Business Awareness

391. Awareness among business is patchy and often riddled with confusion
     and misunderstanding. This continues to be a major impediment to
     the uptake of both PKI and electronic commerce. This is
     particularly the case for Small and Medium Enterprises (SMEs) who
     often don't have the technical skills to understand both the
     technology and the debate surrounding it. Within APEC a number of
     electronic commerce awareness seminars for small business have been
     conducted by Asia Oceania Electronic Marketplace Association
     (AOEMA)[^34] that include elements on the role and use of PKI.

392. An important development in PKT awareness is the establishment of
     domestic, regional and international "PKI Forum" organisations.
     Many of these have established web based resources to improve
     awareness of the technology and its use. These resources can be
     used by both product developers and vendors as well as the general
     public.

393. The original PKI Forum[^35] is an international US-based vendor
     association formed to promote the development of the PKI industry.
     It has several technical working groups and has published white
     papers on interoperability and small business issues. Regional
     forums have been established in Asia (Asia PKI Forum)[^36] and
     Europe (European Certification Authority Forum)[^37].

394. While most economies provide information on their legal and policy
     regimes, these often do not assist business in understanding the
     approaches in other economies with whom they might wish to
     transact. Instead, the best legal and regulatory information is
     perhaps available from several international law firms, which link
     to authoritative government sources. A wide ranging survey of
     e-signature legislation has been published by the Internet Law and
     Policy Forum[^38]. This work covers a number of APEC economies but
     not all. Another international source of information on PKI law and
     policy is the Digital Signature Law Survey[^39].

### Individual User Awareness

395. Awareness among individual users is even lower than among business.
     Many are using products such as browsers that incorporate PKT but
     are often not aware of its presence or its use. Information from
     vendors on the PKT capabilities of their products and how they
     might be used is often difficult to find on their websites. While
     some user groups may provide information on PKT and PKI to their
     members, most users are not members of such groups. There is a role
     for both governments and vendors in making information resources on
     PKI and PKT more widely available to individual users.

## LEADERSHIP

396. The leadership required to encourage the practical usage of
     electronic authentication clearly will vary according to the
     circumstance within each economy. Most if not all economies will
     find public key authentication increasing in importance as a
     function of its deep integration with all commercial Internet
     commerce applications. Economies need to find their own balance
     between technology neutrality and support infrastructure for what
     has become a commercially critical technology.

397. The following suggests some of the initiatives that may be
     appropriate. Broadly, leadership is required from governments,
     international organisations, business corporations, the IT Industry
     and academic institutions.

### Governments

398. Governments can provide significant leadership by establishing the
     appropriate legal and policy frameworks for PKT. The possible
     absence of policies in this important area may impede many related
     developments or confuse users and developers in need of guidance.
     Policy helps the private sector, and indeed government departments,
     to make their own plans, with reasonable confidence as to how their
     own authentication systems will integrate smoothly into whatever it
     is that the government proposes, or else sit alongside government
     initiatives. Government policies initially need not be too
     detailed.

399. There are several possible government policy models.

400. **Minimal regulation model.** Government may decide to leave the
     authentication arena wide open. It might establish CAs within its
     own agencies on a case by case basis but leave the private sector
     free to set up CAs, commercial or otherwise, as it sees fit. There
     is no jurisdictional root CA or other higher level authority in
     this model. Each CA would be responsible for ensuring
     interoperability with other CAs, domestically and internationally.
     No licensing of CAs would be required, save for the usual consumer
     protection regulations.

401. **Optional root accreditation model.** Government may decide to
     establish a non-mandatory root CA or similar high level authority,
     as a resource to facilitate the interoperability of other CAs. By
     opting into a central recognised authority, CAs can enhance the
     acceptance of their certificates outside their own systems. Mutual
     recognition would be mediated with other economies by the central
     authority. Non-mandatory licensing and/or technology accreditation
     for each CA would be required. Special legal protection may or may
     not be granted to transactions covered by certificates from
     accredited CAs.

402. **Mandatory licensing model.** Government may decide to establish
     one central jurisdictional root CA and PKI, to the exclusion of all
     others within the economy. Licensing and approval exemptions would
     be controlled by a central agency, with the objective of ensuring
     uniformity and high levels of dependability of all certificates
     issued within the economy.

403. The interoperability and legal implications of adopting different
     policy approaches are discussed in subsequent chapters to this
     paper.

404. Governments can also provide leadership by becoming early adopters
     of the technology and encouraging its use by both business and
     individuals in their transactions with government. While the
     general principle of market lead development of electronic
     authentication is important, experience to date is that the market
     is looking to governments to provide leadership in this area. This
     does not resile from the general principle that product development
     should be market lead.

405. Another key leadership activity is in the establishment or
     sponsoring of advisory groups to assist in the development of
     policies relating to the use of PKT and implementation of PKI.
     Similar leadership can be shown in the respect of the development
     of standards for PKT and PKI.

### International Organisations 

406. International organisations can provide leadership through the
     development of the necessary frameworks to facilitate the use of
     PKT in cross-jurisdictional transactions. They can monitor
     developments in various economies and regularly issue policy advice
     papers to all governments setting out the advantages and
     disadvantages of particular approaches, based on actual experience
     of successes and failures. Such international organisations can
     also play a coordinating role to assist economies to establish
     systems in their control to interoperate with other systems that
     are not under their control.

407. A number of international business associations such as the
     International Chamber of Commerce[^40] have provided leadership to
     their members by participation in debates on electronic commerce
     and the use PKI and PKT.

408. There is also a leadership role for standards making bodies, both
     formal and informal in development of the necessary standards and
     protocols to support PKT.

### Business Corporations

409. Business corporations can play a leadership role by the adoption of
     PKT where appropriate to their electronic business requirements.
     They can also provide leadership by encouraging governments to
     develop legal and policy frameworks to support their business
     requirements in respect of the technology. A number of domestic
     business groupings have established working groups to address
     issues relating to the use of PKT and to lobby governments. In some
     cases business corporations or associations are represented on
     government advisory bodies relating to the development of PKI legal
     and policy frameworks.

### Users and User Groups

410. A number of user groups are providing leadership by participation
     in debate on PKT and PKI. In some cases they are involved in
     government advisory bodies developing legal and policy frameworks.
     They also have a role in advising governments and product
     developers on their requirements and concerns regarding the
     technology and its implementation.

411. A number of broader interest groups such as those dealing with
     privacy and consumer interests are also engaged in debate
     highlighting their specific concerns and requirements.

412. User groups also have a role in ensuring that their membership and
     the general public are aware of the technology and their activities
     in protecting their constituency's interests.

### IT Industry

413. The IT industry is already providing leadership through the
     establishment of domestic, regional and international PKI forums
     and industry bodies that are developing standards and protocols.
     They are also participating in interoperability experiments and
     pilots to facilitate the use of PKT. The PKI forums are liaising
     with users and governments to facilitate the adoption on PKT and
     development of PKI frameworks.

414. They can provide further leadership at the individual corporate
     level by show casing their products and providing information on
     the technology and its use.

### Academic Institutes

415. Academics institutes have played a significant role in the
     development of asymmetric cryptography algorithms and key
     generation packages as well as the testing of public offerings. In
     addition they have also been actively involved in debates on legal
     frameworks and individual rights. In many cases, however, their
     work is not widely known outside the academic community.

416. They can provide further leadership by more wide dissemination of
     their work and by incorporating that work in IT, business and law
     courses.

## COMBINATION WITH OTHER TECHNOLOGIES (HYBRIDS)

417. Asymmetric cryptography and public key technology can be either
     chained with other authentication technologies or used to protect
     other forms of authenticators through the confidentiality
     functionality. These hybrid approaches are discussed in detail in
     the Hybrid Technologies Chapter (Chapter 7).

#   {#section-2 .unnumbered}

# Appendix 1

# Electronic Authentication in a Multi-Format/Multi-Protocol Environment

1.  Electronic authentication is not always easy to achieve even in an
    environment that utilises a single format and a single protocol over
    the whole end-to-end transmission path, for example a plain text
    message transmitted over TCP/IP. In an environment where more than
    one format or more than one protocol are utilised at various stages
    of the end-to-end transmission path, electronic authentication
    becomes even more complex.

```{=html}
<!-- -->
```
418. An example of a multi-format/multi-protocol environment might be
     the transmission of data from a shipping company's system (which
     might use the CARGO.IMP EDI standard over SMTP) to a customs
     authority that requires the data in a UN/EDIFACT format transmitted
     by X.400.

419. Despite the decades long efforts of many public and private bodies
     towards the goal of standardisation, in practice there are a great
     many different standard and proprietary formats and protocols in
     use today and this situation is unlikely to change in the
     foreseeable future.

420. The following discussion tries to summarise some of the issues
     associated with Electronic Authentication in a
     multi-format/multi-protocol environment.

## TERMINOLOGY

  ------------------- ---------------------------------------------------
  Translator          The term Translator is used in this Appendix as a
                      generic expression to describe any computer program
                      (be it an end-user module or a large EDI
                      clearing-house system) that accepts messages in one
                      or more formats and/or in one or more
                      communications protocols and then translates the
                      messages as required into different formats
                      acceptable to the recipients and routes them to
                      their destinations using the appropriate, and again
                      possibly different, communications protocols.

  Message             For the purposes of this Appendix the term Message
                      encompasses both free text unstructured messages
                      and structured messages, including the many
                      different formats used in EDI systems.

  Authentication      Authentication means any one of the several
                      processes that assure the recipient that a message
                      did in fact originate from the claimed computer or
                      individual sender. Authentication technologies also
                      often provide confirmation that the received
                      message is exactly the same as the message
                      originally transmitted by the sender.

  Digital Signature   An Authentication technology providing confirmation
                      of origin, assurance of the integrity of the
                      content, and non-repudiation. Digital signatures
                      rely on a mathematical digest of all or part of the
                      original message, and if any change is made to such
                      message during transmission, the signature will not
                      validate (see Figure 15 below).
  ------------------- ---------------------------------------------------

**NOTE:** In the context of this Appendix, the sender and the recipient
may be individual persons at each end of a communications link or may be
computer systems.

## METHODS OF ACHIEVING AUTHENTICATION

### Message Security

421. Message security is a technology in which the security elements are
     attached to the message itself, allowing it to travel across as
     many different communication media as may be needed without
     affecting the security of the message. EDIFACT ISO 9735-5/7 and
     X12.58 define security of this type.

422. PKCS#7 (also RFC 2315) may be regarded as another example of
     message security since it is independent of any communication
     protocol and is applicable to any data format. However, it wraps
     the original message into an envelope that hides the sender and the
     recipient IDs in the original message, unlike the EDIFACT or X12
     security standards. Note: such an envelope is not a "communication
     envelope" to which envelope security elements are attached (see
     below); hence PKCS#7 should be viewed as a message security
     standard.

### Envelope Security

423. Envelope security is a technology in which the security elements
     are attached to a "communication envelope" but not to the message
     itself. Such envelope security elements are lost if the same
     protocol is not used end-to-end. S/MIME (in combination with
     RFC-822 or HTTP), PEM and X.400 security standards are examples of
     envelope security.

### Transport Security

424. Transport security is also dependent on a particular protocol, but
     operates at a lower level. It is the continuous flow of messages
     secured between the two entities at each end of the protocol link.
     SSL, and its newer version TLS, are examples of transport security
     standards.

### Network Security

425. Network security operates at yet a lower level, and consists of the
     protection of the physical communication lines as well as access to
     the network. SWIFT, the worldwide inter-bank network, is an example
     of a secured network.

426. Network or transport level security are often better alternatives
     than envelope or message level security, as they relieve both
     senders and recipients of all security burdens, and yet they
     provide a level of authentication and confidence adequate for the
     conduct of many business transactions.

427. However, where a community becomes very large or where it expands
     across multiple third party networks, the maintenance of an
     adequate level of security within the network or transport layers
     may become increasingly difficult, and then envelope or message
     level security techniques become more attractive.

### Access Control

428. Access control is a form of authentication used only to confirm the
     identity of an entity seeking access to a resource. Once the access
     is granted, no further security controls are applied. Access
     control is a necessary feature of network or transport level
     security.

## TYPES OF AUTHENTICATION

### End-to-End Authentication

429. End-to-end authentication occurs when A sends a signed message to
     B, and B itself is able to validate the signature of A. This is the
     standard simple case in which A is called the "principal" because A
     has said "this message comes from A" and B has been able to
     validate this statement.

### Delegated Authentication

430. Delegated authentication occurs when an entity C tells B that the
     message in question comes from A. In other words, C verifies A's
     signature and then reports the result to B (and C may use another
     signature to sign the report). In this circumstance C is said to
     "speak for A" and C becomes the "principal" because C has said
     "this message comes from A" and B has been able to validate this
     statement.

431. When C "speaks for A", then C is called a Security Proxy Agent.
     Such a system is widely used in both SWIFT and SITA, two examples
     of closed and secured networks.

## BASIC ISSUES

### Invalidation of a Digital Signature

432. Where a digital signature is based on a digest of the whole or a
     major part of the original message, which is the standard
     procedure, then if the translator makes any changes in the format
     of that message or makes any alterations to the content of the
     message, the signature will no longer validate.

![](media/image18.wmf)SENDER

RECIPIENT

Figure 15: Message Translation

433. To clarify this most critical issue, consider that the original
     message is, for example, the phrase "The cat drank the cream". This
     phrase is inserted by the sender, together with the sender's
     private key, into the mathematical algorithms that produce the
     digital signature. The digital signature is sent to the recipient
     accompanied by the original message "The cat drank the cream". When
     the original message plus the sender's public key is inserted into
     the appropriate mathematical algorithms, the digital signature will
     verify.

434. But let us suppose that somewhere along the transmission path there
     is a link that requires that the message must be "formatted" into
     fields containing Subject, Verb and Object. Thus the received
     message now reads "Subject: The cat - Verb: drank -- Object: the
     cream". The content of the message is essentially the same. But
     when the received "formatted" message is inserted together with the
     sender's public key into the mathematical algorithms, the digital
     signature will not verify as the specific wording of the original
     message has been changed. This is what happens when a translator
     has to make any change, for formatting or other reasons, to the
     original message.

### Preservation of End-to-End Authentication

435. Should the format of the original message be one that offers
     inherent end-to-end authentication (S/MIME for example) it may be
     difficult, if not impossible, to preserve such end-to-end
     authentication if the message needs to be forwarded by the
     translator using a different communications protocol which does not
     support the original format.

     **NOTE:** Any combination of these circumstances multiplies the
     difficulties.

## POSSIBLE SOLUTIONS

436. There are several possible solutions based on an appropriate
     selection of message handling and authentication techniques:

### Proxy Agent

437. ![](media/image19.wmf)A commonly used technique is for the
     translator itself to validate the original digital signature and
     then to create a new digital signature based on the new format and
     the translator's private key.

Figure 16: Secure Proxy Agent

In this case the translator assumes the role of a security proxy agent
(see above).

### Bypass Technique

438. Another technique would be for a translated message to be passed by
     the translator to the recipient accompanied by both the original
     digital signature and the original message in its original format.
     The recipient may not be able to read the original message, but
     would be able to use it to verify the signature. This process
     requires the recipient to trust the translator to accurately
     re-format the original message.

![](media/image20.wmf){width="5.2in"
height="2.9965277777777777in"}Figure 17: Bypass Technique

### Selective Translation

439. In circumstances where there is a requirement (for example a legal
     requirement) that messages should be passed through the translator
     without any action on the part of the translator that would
     invalidate end-to-end authentication/validation of a digital
     signature, this may be accomplished by the careful selection of
     message formats, communications protocols and authentication
     techniques.

440. As an example, one of the techniques that could be used to achieve
     this objective may be the authentication of only selected sensitive
     words or fields in the message, possibly by means of Syntax
     Independent Signatures (SIS) using XML technology.

### Secured Community

441. End-users may be grouped into a secured community. Communications
     between each member of the community is effected through a secure
     clearing house that incorporates a translator, using any of a
     number of different cryptographic techniques including that of a
     security proxy agent. All messages both incoming to and outgoing
     from the secure clearing house can be authenticated in a manner
     appropriate to the requirements of each member of the community.

442. Such solutions give very great flexibility, but impose on the
     secure clearing house the role of a trusted third party and all the
     participants must agree to this.

### Secure Gateway

443. To permit members of a secured community to exchange messages with
     a party who is not a member of that community, the secure clearing
     house may provide a secure gateway between the external party and
     the community using an appropriate authentication technique.

444. The security of the community is not compromised and the secure
     clearing house acts as the secure interface with the external
     party, using appropriate formats and protocols.

445. Once again, the translator assumes the role of a trusted third
     party and all participants including the external party must agree
     to this.

#   {#section-3 .unnumbered}

# 3. PUBLIC KEY INFRASTRUCTURE INTEROPERABILITY

1.  As Public Key Infrastructures (PKIs) are being established
    domestically and in industry sectors, attention is turning to
    interoperability between those PKIs. Because of the complex nature
    of PKIs there is a need to consider interoperability at three
    levels: legal, policy and technical. Initially the Task Group
    decided to only address the policy level issues relating to
    interoperability however as work progressed it became clear that the
    two other levels needed to be at least partially addressed.
    Differing implementations of UNCITRAL model laws and identified lack
    of standards have been addressed in an effort to bridge the
    differences and identify technical standards requirements.

```{=html}
<!-- -->
```
446. The objective of the Task Group is to ensure that business and
     individuals in each APEC economy have access to a certificate that
     will allow them to undertake cross jurisdictional electronic
     transactions. This involves ensuring that the certificates meet
     assurance requirements and have legal effect as required. This is
     discussed in more detail in the Legal Issues Chapter (Chapter 9).

447. The basic issues relating to technical interoperability are
     discussed in the previous chapter. In addition there are now a
     number of international initiatives addressing technical
     interoperability such as the UK Communications-Electronic Security
     Group (CESG*) Secure Messaging and PKI Interoperability Trial*[^41]
     and the European Forum for Electronic Business (EEMA*) PKI
     Challenge*[^42]. Domestic and regional PKI forums have also
     established interoperability working groups. Within the framework
     of the Asia PKI forum, a number of APEC economies are addressing
     interoperability[^43].

448. Early approaches to interoperability were premised on one of two
     basic assumptions:

-   Large hierarchical structures that would allow interoperability
    under a common root CA; or

-   The existence of a cross certification agreement between the sender
    and recipient's CAs or their respective root CAs.

449. As PKIs began to be established different models emerged. For
     commercial and political reasons large hierarchical structures with
     national root CAs were not established in many economies. Rather
     national accreditation or licensing schemes for a number of
     commercially independent PKIs with there own root CAs started to
     emerge. With these smaller, flatter schemes it is less likely that
     there will be a cross certification agreement between the sender
     and recipient's CAs, particularly in the case of cross border
     transactions.

450. Another emerging trend is for CAs to be accredited under several
     schemes. As discussed in the Legal Issues Chapter (Chapter 9),
     legal effect for cross border transactions may require
     accreditation in the sender's, recipient's or a third jurisdiction.
     It is therefore necessary for trust paths to be established to the
     appropriate trust anchor or accreditation process.

451. For these reason the then APEC Electronic Authentication Task Group
     (now the eSecurity Task Group) looked for alternative approaches to
     achieving PKI Interoperability.

452. The PKI Forum has also examined a number of different models for
     interoperability in its *CA-CA Interoperability White
     Paper*[^44]*.* Most of these models are specific implementations of
     either cross-certification or cross-recognition. In view of the
     legal implications of these models they are discussed in more
     detail in the Legal Issues Chapter (Chapter 9).

453. A fundamental problem for APEC was to achieve interoperability
     between economies that used the single economy root CA approach and
     those that accredited or assessed multiple independent CAs. Another
     problem encountered was that in some schemes multiple levels of
     certificates were supported. For that reason part of the APEC
     approach has been to establish functional equivalence of
     certificates issued under schemes rather than trying to establish
     equivalence of the individual CAs operating under those schemes.
     While a CA's CP and CPS are still an important element of the
     process, such an approach allows more flexibility for CAs to
     operate within their own business models.

454. Furthermore focussing on the accreditation scheme can reduce the
     demands on users, be they senders or recipients. If they trust the
     scheme then they can trust certificates accredited under the scheme
     without needing to consider the individual CA's CP and CPS. This is
     particularly the case for schemes where accreditation is required
     for legal effect or for certain legislated liability aspects.

455. The accreditation scheme approach also allows the Task Group to
     focus on its objective of ensuring the availability of a
     certificate that can be used for global electronic commerce. It
     does not need to address all the levels of certificates that might
     be issued by a particular CA.

456. While the term "accreditation" is used in this Chapter, a number of
     the arguments equally apply to other assessment or audit of a CA's
     compliance with either established criteria or standards or its CP
     and CPS.

## Achieving PKI Interoperability

457. For global electronic commerce (e-commerce) to flourish in a
     trusted, secure and predictable environment, the interoperability
     of existing and future electronic authentication schemes is a key
     issue.

458. The Public Key Infrastructure offers a mature and integrated
     electronic security scheme, offering authentication,
     non-repudiation, confidentiality and integrity. A PKI is
     defined[^45] as the set of hardware, software, people, policies and
     procedures needed to create, manage, store, distribute, and revoke
     certificates based on public-key cryptography.

459. This section examines in detail two PKI interoperability schemes -
     cross-certification and cross-recognition. It compares and
     contrasts the two schemes in terms of their technical
     implementation, legal and policy implications, and operational
     requirements. It also proposes a list of actions that can be
     undertaken to facilitate work leading towards greater
     interoperability among electronic authentication schemes.

460. Although these two schemes have their roots in PKI, and discussion
     focuses primarily on PKI, the concepts discussed are potentially
     extendible and applicable to other electronic authentication
     schemes.

461. The study of "*cross-certification and the use of a root
     certification authority, to promote interoperability and trust and
     to facilitate cross-border electronic commerce*" was included in
     the work programme of the *"APEC Blueprint for Action on
     E-Commerce"*[^46]*.* The Blueprint was endorsed at the APEC
     Economic Leaders' Meeting in Kuala Lumpur, Malaysia on 17-18 Nov
     98.

462. At the 19^th^ TEL meeting in Miyazaki, Japan, Canada and Singapore
     presented the joint paper *"Cross-Certification Within APEC"*[^47]
     and proposed the formation of a Cross-Certification Expert Group
     under the auspices of the then Electronic Authentication Task
     Group. The proposal was supported by six other economies, including
     Australia, Chinese Taipei, Hong Kong China, Japan, Korea, and
     Thailand. Malaysia, who did not attend the meeting, also expressed
     its support subsequently.

463. A number of reasons necessitated the expansion of the scope of work
     of the Cross-Certification Expert Group which subsequently became
     the PKI Interoperability Expert Group. These included:

-   rapid developments in related technologies e.g. validation
    authorities (VAs);

-   complexity of cross-certification, mainly because of the elaborate
    procedure involved;

-   emergence of other interoperability schemes e.g. cross-recognition,
    that are less elaborate and easier to implement.

    These new developments accentuated the need for the Expert Group to
    consider the whole spectrum of interoperability issues from a more
    holistic perspective.

### Terminology

464. For the purpose of this section whose discussion centres primarily
     on the PKI, the following terms as defined by the Internet
     Engineering Task Force (IETF) Public Key Infrastructure X.509
     (PKIX) Working Group[^48] [^49] are used:

  ----------------------- -----------------------------------------------
  Public-key Certificate  a record that binds a public-key value to a set
  (Certificate)           of information that identifies the entity (such
                          as person, organisation, account, or site)
                          associated with use of the corresponding
                          private key (this entity is known as the
                          \"subject\" of the certificate).

  Certification Authority an authority trusted by one or more users to
  (CA)                    create and assign certificates. Optionally the
                          CA may create the user\'s keys.

  Registration Authority  an optional entity given responsibility for
  (RA)                    performing some of the administrative tasks
                          necessary in the registration of subjects, such
                          as confirming the subject\'s identity,
                          validating that the subject is entitled to have
                          the attributes requested in a certificate, and
                          verifying that the subject has possession of
                          the private key associated with the public key
                          requested for a certificate.

  Relying Party           a user or agent (e.g., a client or server) who
                          relies on the data in a certificate in making
                          decisions.

  Subject (Subscriber)    a subject is the entity (CA or end-entity)
                          named in a certificate. Subjects can be human
                          users, computers (as represented by DNS names
                          or IP addresses), or even software agents.

  CA-Certificate          A certificate for one CA\'s public key issued
                          by another CA.

  Certificate Policy (CP) A named set of rules that indicates the
                          applicability of a certificate to a particular
                          community and/or class of application with
                          common security requirements. For example, a
                          particular CP might indicate applicability of a
                          type of certificate to the authentication of
                          electronic data interchange transactions for
                          the trading of goods within a given price
                          range.

  Certification Practice  A statement of the practices, which a CA
  Statement (CPS)         employs in issuing, certificates.
  ----------------------- -----------------------------------------------

465. To maintain consistency in the use of terminology in the area of
     electronic authentication in general within the Task Group, these
     PKI-centric terms are mapped to their corresponding
     technology-neutral terms as defined in the Chapter 1 of this report
     in Appendix 1.

### Analysing PKI Interoperability Schemes

466. In this section, the following three-tier framework (**Figure 18**)
     is used to examine and analyse the two PKI interoperability schemes
     \-- cross-certification and cross-recognition:

-   **Technical** - Can the two PKI domains interoperate with each other
    (\"talk to each other\") from a technical perspective? Specifically,
    can the directory system in one of the PKI domains access the
    directory system of the other PKI domain? In addition, can one of
    the PKI systems process certificates generated by the other PKI
    system?

-   **Policy** - Are the certification policies (CP/CPS) and certificate
    practice statements associated with both PKI domains compatible for
    the application or service at hand to operate?

-   **Applications/Services** - What kind of PKI-enabled
    applications/services can most ideally be supported by the PKI
    interoperability scheme?

Figure 18: A Framework for Analysing PKI Interoperability Schemes

### Cross-Certification

467. There is a myriad of definitions for cross-certification from
     various sources. (See Appendix 2 for a selection of these
     definitions.) For the purpose of this section, the following
     definition adapted from the General Issues Chapter (Chapter 1) is
     used:

The practice of cross-recognition of another CA\'s public key to an
agreed level of confidence and is normally evidenced in a contract or
agreement

468. Essentially, cross-certification results in two PKI domains (in
     whole or in part) being merged into one larger domain through an
     elaborate process carried out by two representative CAs. For
     hierarchical PKIs, the representative CA is usually the root CA.
     However, cross-certification can also be implemented between any
     two CAs. In the latter case, each PKI domain constitutes only one
     CA and its subscribers.

469. In **Figure 19**, after CA-A and CA-B cross-certify with each
     other, U-A and U-B would be able to transact with each other. The
     cross-certification process between CA-A and CA-B is transparent to
     both U-A and U-B. To U-A, U-B is simply another subscriber within
     the extended PKI. The same applies to U-B for U-A.

Figure 19: Cross-Certification Between Two CAs \-- CA-A and CA-B

470. Cross-certification entails an elaborate process that involves
     technical interoperability and harmonisation of CP/CPS policies.
     All these take place within the context of the cross-domain
     applications and services that the merged PKI is meant to support.

471. As discussed in the introduction to the PKI interoperability
     framework the cross-certified PKI domains must communicate at a
     technical level. This involves first a sharing of their two
     respective directories of certificates such that each PKI domain
     can access the directory and hence the certificates generated by
     the opposite PKI domain. Both representing CAs exchange
     certificates with each other, generating a new pair of certificates
     called the cross-certificates*.* This has the similar effect of
     mutually extending each PKI domain to include the cross-certified
     PKI domain.

472. International technical standards are instrumental in ensuring
     technical interoperability across different PKI systems. Both the
     IETF-PKIX Working Group and RSA (in their PKCS Standards) are
     leading the work in this area. However, at the point of writing
     this paper, technical interoperability standards for PKI are still
     rather fluid and have yet to reach a maturity stage. Moreover, the
     PKI technology market is traditionally characterised by a number of
     proprietary players that adopt technologies that do not
     interoperate with one another[^50].

473. Fortunately, there has been growing general awareness of the need
     for greater technical interoperability. This is also fast becoming
     a key agenda for most PKI technologies today. For example At the
     RSA'99 Data Security Conference in California, USA in Jan 99, the
     participating technical vendors vouched to adopt open standards and
     improve technical interoperability with the products of their
     competitors[^51]. Concrete steps such as participation in standards
     bodies by technology vendors, incorporation of PKI open standards
     into products, and organisation of talks and seminars to promote
     interoperability will pave the way for greater technical
     interoperability in the near future.

474. Traditionally, cross-certification has incorrectly been equated
     with only technical interoperability. As aptly clarified in the
     General Issues Chapter (Chapter 1), the process of
     cross-certification includes *\"legal, technical and policy review
     of each others authentication scheme policies\"* (CPs in the PKI
     context) *\"and authentication scheme practice statements,\"* (CPSs
     in the PKI context) *\"implementation and operational
     management.\"*

475. The harmonisation of CPs and CPSs is necessary to ensure that both
     PKI domains are compatible in terms of their certificate management
     operations (i.e. certificate issuance, certificate suspension and
     revocation) and adheres to similar operational and management
     conditions and environments. Other issues such as operational and
     security requirements, and the amount of liability coverage are
     also taken into consideration.

476. The complexity of this policy harmonisation step is easy to
     comprehend, considering the scope of issues covered in the
     documents. Moreover, the general trend of an increase in size in
     these documents further complicates the process. Furthermore, one
     CP typically corresponds to one specific level of assurance in
     terms of the type of certificates the CP supports. Hence, depending
     on the nature of the cross-certification arrangement, multiple CPs
     may need to be harmonised. It is for this reason that the Task
     Group's work is focussing on specific types of certificates.

477. No doubt, it seems that there is no panacea to ease the
     harmonisation of CPs and CPSs. Nevertheless, this process can
     potentially be facilitated if the CPs are authored in adherence to
     the standards defined by IETF-PKIX *in RFC 2527 Internet X.509
     Public Key Infrastructure Certificate Policy and Certification
     Practices Framework*[^52]. In the event that both CPs and CPSs are
     too diverse to be harmonised, a new common CP or CPS can be jointly
     developed and adopted by both parties.

478. In general, cross-certification is relevant for relatively closed
     business models, and at best, open but bounded systems as defined
     in the General Section of this Report. It is most suitable if the
     two PKI domains belong to two work contexts that share a close
     working relationship with each other. For example, both work
     domains may share the set of applications and services e.g. email
     and financial applications. In addition, cross-certification can
     certainly be simplified if the two PKI domains employ technically
     compatible or interoperable systems, have congruent policies and
     reside in economies with the same legal structures in this area.

479. In summary, a number of advantages and disadvantages of
     cross-certification can be inferred.

480. The two primary advantages of cross-certification are as follows:

-   **Transaction Flow** - Cross-border transactions can be carried out
    seamlessly, as cross-certification essentially marries two PKI
    domains into a single larger domain;

-   **User Transparency** - The cross-certification arrangement is
    transparent to the user.

481. The disadvantages of cross-certification are as follows:

-   **Process** - The process of cross-certification is complex. Apart
    from technical interoperability, relatively detailed mapping of PKI
    policies is required;

-   **Scalability** - In terms of scalability, the effort required for
    cross-certification increases exponentially with the inclusion of
    every new PKI domain as discussed in the Asymmetric Cryptography
    Chapter (Chapter 2);

-   **Business Case** - This is strictly speaking, an implication of the
    above two disadvantages. As a result of the complexity and poor
    scalability of cross-certification, it is relatively more difficult
    to justify for the need for cross-certification in a business sense.
    Furthermore, a PKI may demand cross certification to mutually
    exchange certificates -- this will drive the business case.

-   **Third Jurisdiction** -- Cross-certification may not address
    recognition in a third jurisdiction unless there are appropriate
    cross certificates with that jurisdiction.

### Bridge Certification Authorities

482. One approach to the scalability problem has been the establishment
     of bridge certification authorities. In this approach a number of
     CAs can cross-certify with the bridge rather than having to
     establish individual cross-certification agreements between each
     other. It is a "hub and spokes" approach rather than a "mesh"
     approach. Such arrangements have been established by the US
     Government[^53] and are being considered by other economies.

### Unilateral Cross-Certification

483. This is a special case of cross-certification whereby one PKI
     domain trusts another PKI domain but not vice versa. In a way, the
     term unilateral cross-certification is a misnomer as the words
     \"unilateral\" and \"cross\" are paradoxical to each other.
     Technically, this is an atypical scenario, but this is discussed
     briefly to ensure the completeness of this paper.

484. Generally, the above discussion pertaining to bilateral
     cross-certification applies to a unilateral cross-certification
     arrangement as well. However, in such a one-way trust relationship,
     the PKI domain that chooses to exercise the trust relationship
     (thereafter as \"truster\") is at the complete mercy of the trusted
     PKI domain. Hence, (apart from technical interoperability,) in the
     areas of PKI policy, there is no harmonisation process whatsoever.
     The truster has to unilaterally ensure that its policies are
     compatible with those of the trusted PKI domain.

485. Comparatively, there are also seemingly fewer applications and
     services that warrant such an unbalanced arrangement. These
     applications and services conceivably share the common trait that
     the required trust required in the transactions involved is
     unilateral. An example of such an application is a shopping-like
     application in which the merchant has to prove to the customer his
     or her identify before the latter submits a private piece of
     information.

486. One emerging use of unilateral cross-certificates is starting to
     emerge in the form of electronic accreditation certificates. Such
     an approach has been proposed for the Australian Government PKI
     Gatekeeper[^54] and is being considered for other accreditation
     schemes. This approach could involve the issue of a unilateral
     certificate from the accreditation body to CAs accredited under the
     scheme. In this case the term "unidirectional" may be more
     appropriate than "unilateral" as there is an agreement between the
     parties. The use of accreditation certificates can facilitate the
     cross-recognition approach discussed below.

### Cross-Recognition

487. First coined by the then Electronic Authentication Task Group,
     cross-recognition can be defined as

An interoperability arrangement in which a relying party in one PKI
domain can use authority information in another PKI domain to
authenticate a subject in the other PKI domain, and vice-versa.

488. Such authority information is typically the result of either a
     formal licensing or accreditation process in the economy of the
     other PKI domain, or a formal audit process performed on the
     representative CA of the PKI domain. Technically, the information
     can be stored as the value of a certificate field accessible by the
     relying party or can be evidenced by an electronic accreditation
     certificate.

489. Compared to cross-certification, the onus of whether to trust a
     foreign PKI domain lies with the relying party or the owner of the
     application or service, rather than a CA that the relying party
     directly trusts. Also, unlike cross-certification that is, in most
     cases, bi-directional (except in a unilateral cross-certification
     arrangement as above), cross-recognition can be seen as
     constituting one or two unilateral trusts relationships.

490. Consider **Figure 20**. CA-A and CA-B are not cross-certified with
     each other. U-A trusts U-B because CA-B, which issues U-B\'s
     certificate, has either been licensed by a CA licensing body in
     Domain B or has been formally audited by an independent auditor.
     The trust relationship can be represented symbolically as follows:

     U-A  Trusted Authority B CA-B  U-B

     Hence, U-A  U-B.

     Similarly, (vice-versa)

     U-B  Trusted Authority A (not shown)CA-A  U-A

     Hence, U-B  U-A

     Collectively, U-A cross-recognises U-B.

Figure 20: Illustration of the Concept of Cross-Recognition (How U-A
trusts U-B)

491. Like cross-certification, a cross-recognition arrangement entails
     issues pertaining to technical interoperability and policy
     compatibility. However, in cross-recognition, the decision of
     whether to trust a foreign certificate lies with the relying party
     and not his or her CA. It does not necessarily involve a contract
     or an agreement between two PKI domains. Hence, the process is
     comparatively less complicated.

492. Unlike cross-certification which requires almost full technical
     interoperability between two PKI systems, the necessity for
     technical interoperability in a cross-recognition arrangement is
     brought down to the application level. There still needs to be
     interoperability in all aspects such as algorithms, protocols, key
     lengths, etc. The application must be able to process the
     information in the foreign certificate. Moreover, it must be able
     to access the directory system of the foreign PKI domain to
     validate the status of the foreign certificate.

493. If the application is developed to accept certificates issued by
     many different foreign CAs, it must then be able to process all
     these different certificates. Compared to a cross-certification
     arrangement, this is perhaps the most difficult issue. Although
     most digital certificates today are compliant with the X.509 v3
     standard, the interpretation of certificate fields and the use of
     certificate extensions can vary across PKIs[^55].

494. With the event of VAs, technical interoperability can potentially
     cease to be an issue in a cross-recognition arrangement. As VAs are
     established specifically to manage certificates from a wide variety
     of certification revocation systems and directory systems, it is
     arguably much more applicable in the cross-recognition scheme than
     the cross-certification scheme.

495. In a cross-recognition arrangement, detailed mapping of CPs and
     CPSs is not necessary. Instead, the relying party (via the
     application at hand) decides whether to accept a foreign
     certificate for the purpose depending on whether the certificate
     has been issued by a trustworthy foreign CA. The CA is regarded as
     trustworthy if it has been licensed/accredited by a formal
     licensing/accreditation body or has been audited by a trusted
     independent party. Also, the relying party must be able to
     unilaterally make an informed judgement based on the policies
     stipulated in the CP or CPS in the foreign PKI domain.

496. In contrast with cross-certification which is most suitably
     implemented in a closed or open but bounded business model,
     cross-recognition is ideal for open systems as discussed in the
     General Issues Chapter (Chapter 1) of this report.

497. In addition, congruent with the less elaborate interoperability
     process required, cross-recognition is suitable for applications
     that require a relatively lower level of trust.

498. Similarly, a number of advantages and disadvantages of
     cross-recognition can be inferred from the discussion above.

499. The advantages of cross-recognition are as follows:

-   **Implementation** - cross-recognition involves a relatively less
    complex process than cross-certification, especially in terms of
    policy and legal harmonisation;

-   **Scalability** - Cross-recognition supports potentially an
    unlimited scope of interoperable PKI domains, subject to technical
    interoperability.

500. The disadvantages of cross-recognition are as follows:

-   **User Transparency** - The need to be an informed relying party is
    a potential burden to the user. An uninformed user might not be
    aware of the full consequences of choosing to trust a foreign user
    that he or she should not.

-   **Assurance** - Cross-recognition can be procedurally less rigorous
    than cross-certification. This may impact on whether the level of
    trust is fit for purpose.

### Liability Implications of Cross-Certification and Cross-Recognition

501. Liability is a key issue in any e-commerce transaction. In a
     cross-border context, the question of who should bear liability
     when a fraud occurs is made even more complex.

502. In a cross-certification arrangement, one would generally expect
     the local CAs to bear the bulk of the liabilities (depending on
     which domain is proven to be at fault, and any prior agreement
     between the two cross-certified CAs). On the other hand, one would
     assume the relying parties in a cross-recognition arrangement to
     cover most of the liabilities as it is their responsibility to
     decide whether or not to trust the foreign subjects.

503. Most of digital signature laws are deliberately crafted to limit
     the liabilities of CAs so as to provide them with the necessary
     legal support to enable trusted e-commerce to flourish. Moreover,
     there is a general propensity for CAs to protect themselves. Hence,
     apart from the legal support from the digital signature laws, CAs
     would generally tend to shift as much of the liabilities to the
     subscribers and relying parties by stipulating liability caps in
     the CA service contractual agreement and CPS/CP.

504. The amount of liabilities that the relying parties in both
     arrangements would have to bear is arguably not significantly
     different. In the long run, CAs might choose to take on greater
     liabilities to be more competitive than competing CAs, or to
     leverage on the risk management schemes and services offered by
     insurance companies.

### Legal Implications of Cross-Certification and Cross-Recognition

505. The essence in the legal implications of our discussion of PKI
     interoperability lies in the validity of an electronic transaction
     that is performed by virtue of a cross-certification or
     cross-recognition arrangement, especially within a cross-border
     context. For such a transaction that spans across two different PKI
     domains in different economies and hence jurisdictions, is the
     transaction legally recognised? If not, what is the necessary
     supporting legislation, if legislation is required at all?

506. This legal issue has been singled out as a separate topic in this
     section (instead of being included as an element of PKI
     interoperability) as it is an element that is generally beyond the
     direct control of the two interoperable PKI domains. Nevertheless,
     it is a factor that can adversely affect the effective
     implementation of cross-certification and cross-recognition.

507. For global e-commerce to happen at the exponential rate predicted
     by most people, some formal recognition needs to be given to
     electronic transactions conducted within a cross-certification or
     cross-recognition arrangement. This would entail the harmonisation
     of laws pertaining to the electronic transactions and digital
     signature between different jurisdictions. However, it is arguable
     whether direct legal support for cross-certification or
     cross-recognition is needed. (If necessary, this can take the form
     of legislation that stipulates the requirements of a "valid"
     cross-certification arrangement, or laws that allow local CAs to
     recognise digital certificates issued by foreign CAs.)

508. Increasingly countries have implemented laws related to digital
     signatures, electronic transactions and the use of electronic
     authentication schemes. These laws vary in focus and approach (e.g.
     different CA licensing schemes, different degrees of technology
     neutrality) and may be difficult to harmonised. Also, very few of
     these existing laws or regulations however have specific clauses
     supporting cross-certification or cross-recognition. This is
     addressed in more detail in the Legal Issues Chapter (Chapter 9).

### Certificate Trust Lists

509. Certificate trust lists are in effect directories, either online or
     offline, containing information that can establish trust in a
     certificate issued under a particular scheme. The most common
     implementation is in browsers where root certificates of a number
     of schemes are included in the browsers when shipped and updated as
     part of the update process. However, the browsers include a
     capability to allow users to import other root certificates as
     required. This has the potential to be exploited by malicious code
     that could add false root certificates. Some proprietary
     applications have addressed this problem by digitally signing the
     trust list.

510. Certificate trust lists can also be used to support both
     cross-certification and cross-recognition. Directories of
     cross-certificates maintained by CAs, including bridge CAs, are a
     form of certificate trust list. In cross-recognition the
     accreditation or licensing body will typically need to advise the
     CAs it has accredited. While this can be done through an
     accreditation certificate as discussed earlier, it could also be
     done by publishing a list of those CAs possibly also including the
     public keys of those CAs. In both cases the trust lists can
     digitally signed. Users can either regularly download the lists or
     access them as required. Where cross-certificates or the public
     keys of accredited CAs are stored in the trust lists, applications
     can establish the appropriate trust paths.

511. The European Electronic Signature Standardization Initiative has
     been examining a similar approach in its *Provision of harmonized
     Trust Service Provider status information*[^56] project. This
     project is developing a methodology to provide information about
     the trust scheme, and a list of approved Trust Service Providers.

512. Where trust lists are created by accreditation or licensing bodies
     established under legislation that requires such accreditation to
     give legal effect or specific legal presumptions, such lists can
     evidence that legal effect particularly in cross jurisdictional
     transactions. This is discussed in more detail in the Legal Issues
     Chapter (Chapter 9).

### Possible Areas of Work 

513. To increase adoption of global e-commerce in a trusted and
     conducive environment, the Task Group can work with other
     international organisations and technical standard bodies to
     facilitate cross-certification and cross-recognition arrangement.

514. The following areas of work are recommended:

-   **Promote greater awareness of the importance of interoperability
    for cross-border e-commerce -** Through a combination of both formal
    and informal means (e.g. seminars and conferences, and email
    exchange), the Task Group can facilitate the exchange of information
    pertaining to the different laws, policies and technical
    developments related to PKI. This can help to foster greater
    understanding of the different PKI regimes within the APEC
    economies, and greater awareness of the importance of
    interoperability for cross-border e-commerce to flourish. One
    concrete step is to design and implement a PKI Information Bank that
    can serve as a one-stop, non-stop online resource of such
    information.

-   **Promote cross-border pilot trials and feedback -** The lack of
    truly compelling applications and services (or "killer
    applications") to make cross-certification and cross-recognition
    realise their full potential has often been named as a key concern.
    By working with APEC members from other economic sectors, the Task
    Group can help to identify potential cross-border applications and
    services and facilitate cross-border trials and pilot projects among
    the economies.

-   **Examine the need for a generic framework of technical and policy
    procedures -** By working with the private sector, as well as other
    international organisations and technical standard bodies that have
    ongoing work in interoperability, the Task Group can evaluate the
    need for a generic framework of technical and policy procedures that
    will facilitate cross-certification and cross-recognition between
    any two PKI domains.

-   **Develop a program of action for interoperability within APEC -**
    Through collective studying of the various interoperability schemes
    and monitoring developments in electronic authentication
    technologies, the Task Group can develop that will eventually result
    in a network of interoperable PKIs among member economies. This can
    begin with a number of pilot trials and constant feedback as
    discussed earlier.

## Mapping of Certification Authorities Accreditation Schemes[^57]

515. The Telecommunications and Information (TEL) Working Group is
     leading the development of many aspects of electronic commerce in
     APEC. This is in response to instructions from Leaders and from
     Trade Ministers who agreed that electronic commerce is a potential
     catalyst for economic growth in the region. Within the TEL, the
     Business Facilitation Steering Group, the eSecurity Task Group and
     the PKI Interoperability Expert Group are continuing their efforts
     to work with the private sector to build trust and confidence in
     electronic business processes. The focus continues to be on
     developing an understanding of approaches to authentication and
     certification that can serve as policy models for member economies
     and that will eventually facilitate electronic commerce among
     businesses in the region.

516. In this regard, the PKI Interoperability Expert Group has been
     carrying out a project that will assist member economies in
     identifying and mapping the certification authority and
     accreditation linkages that are necessary for organisations to
     securely interact and transact with each other electronically
     across jurisdictional boundaries.

517. It is recognised that there are differences in some of the
     approaches being taken. The value in the project is that it
     facilitates a pulling together of the different approaches and
     provides an analysis of how the variances might be adapted to meet
     the same objectives. This could lead to interoperable e-commerce
     across the region. It is already becoming apparent that different
     business models have emerged and the criteria critical to an
     assessment of a certificate's trust may appear in different
     locations. This mapping exercise will help to encourage and
     facilitate real marketplace interoperability by highlighting
     commonalties and moreover recognising where differences need to be
     addressed.

518. The project has the potential to speed up the development of
     policies and processes that will enable interoperability across the
     region

519. While the following discussion refers to accreditation, the same
     process can be applied to other formally structured assessment and
     audit schemes.

### Terminology

520. For the purposes of this section, the following terminology is
     used:

  ----------------------------------- -----------------------------------
  Certificate Authority (CA)          includes the elements involved in
                                      managing certificates, such as
                                      directory services and registration
                                      services, as applicable. The use of
                                      this term in this section covers
                                      all these elements regardless of
                                      whether they are carried out by a
                                      single or several parties.

  Certificate Policies (CP)           state the security and other policy
                                      requirements ("What") the CA must
                                      satisfy. This also referred to as
                                      "Policy"

  Certificate Practice Statements     document "How" the requirements are
  (CPS)                               to be satisfied within a particular
                                      CA policy domain. This is also
                                      referred to as "Practices".
  ----------------------------------- -----------------------------------

### Implementation Policies and Practices

521. There are three primary dimensions to the business environments
     within which CAs must operate: (1) different legal
     jurisdictions; (2) different business models; and (3) a broad
     spectrum of security policies. The global electronic commerce
     environment is evolving toward the use of electronic signatures
     that will be generated within a mix of legal jurisdictions. Some
     jurisdictions could require regulated/licensed CAs, while others
     will allow for certification accreditation in non-regulated
     regimes. Different business models are emerging in which third
     parties may carry out the processes generally associated with CAs.
     Further, it is becoming evident that different applications will
     likely require a broad range of security policies to support
     differing levels of trust in a variety of business environments. A
     common understanding of security policies and related criteria
     could help facilitate cross border authentication between different
     jurisdictions. Such norms are required to:

-   Define the multiple security policy and business model environments:

-   Define the legal jurisdiction requirements;

-   Establish the management practices suitable for the multiple
    security policy and business model environments;

-   Facilitate recognition of the level of trustworthiness of digital
    signatures and their level of trustworthiness across different
    policy domains. This process of formally evaluating and certifying
    the trustworthiness is often referred to as "accreditation".

### Accreditation Approach

522. A common approach to accreditation can form the basis for
     recognition of CAs between different jurisdictions with different
     licensing or regulatory requirements. Common accreditation
     standards and processes can be used to facilitate sound and
     consistent legal and technical practices across different legal
     jurisdictions. The Internet Engineering Task Force (IETF) *Internet
     X509 Public Key Infrastructure Certificate Policy and Certification
     Practices Framework (RFC 2527)*[^58] could serve as guidance for a
     common CA accreditation approach.

### Accreditation Roles and Interaction

523. While terminology and processes may vary across the international
     jurisdictions, there is an evolving recognition that accreditation
     would somehow involve interaction of players, legal entities,
     parties, or agents having the following roles:

524. **Competent Authority** -- An agent of the legal jurisdiction or
     community of interest. It is responsible, within the jurisdiction
     or community, for a number of actions that could include some or
     all of the following:

-   Defining the policy and legal environment within which the
    accreditation scheme must operate;

-   Negotiating with other competent authorities to ensure harmonisation
    across differing legal jurisdictions;

-   Issuing licenses, authorisations, regulations or other government or
    legal recognition to various CAs;

-   Setting minimum policy requirements for advancing CA accreditation
    schemes across differing legal jurisdictions and communities of
    interest;

-   Giving formal recognition to standards, criteria and frameworks for
    advancing the compatibility accreditation approaches across
    differing legal jurisdictions;

-   Approving and giving formal recognition to the accreditation
    approach; and

-   Giving formal recognition to an evaluator accreditation body, which
    is chartered to carry out the accreditation of evaluators**.**

525. **Evaluator Accreditation Body** -- An independent body, industry
     association or other agency which could be recognised by the
     competent authority or could function on the basis of trust
     relationships with evaluators or policy authorities. Responsible
     for:

-   Approving and giving formal recognition that evaluators are
    professionally competent to perform evaluations of compliance to
    appropriate policies or other requirements which may be provided by
    the competent authority; and

-   Sanctioning, selecting and/or developing policy compliance,
    evaluation guidance, criteria and standards.

526. **Evaluator** -- An independent agent, member of an accounting
     body, financial institution or other qualified professional that is
     trusted by the policy authority. The evaluator accreditation body
     could formally recognise evaluator*,* if such an entity existed in
     that jurisdiction or community of interest. Responsible for:

-   Evaluating the operational authority's compliance to the CA policy;

-   Using specific evaluation guidance, criteria and standards
    sanctioned by the evaluator accreditation body, to determine that:

-   there are adequate controls in place;

-   these controls are operating effectively, such that reliance can be
    placed on transactions that are recorded, processed, executed or
    maintained by the operational authority in question;

-   Evaluating other evidence of compliance with the certificate
    policy*,* where the parties have effected obligations through
    mechanisms such as contracts and membership agreements and through
    the implementation of related operational safeguards or business
    methods. For specific policy requirements*,* an external reference
    may be sufficient to convey an understanding to the evaluator**,**
    of the relevant material practices of the domain;

-   Producing a CA policy compliance evaluation report. The potential
    users of an evaluation report include:

-   Relying parties who have a significant interest in knowing that a
    scheme's practices operate with sufficient effectiveness to achieve
    the requirements within the certificate policy;

-   Subscribers who have an interest in knowing that the CA is meeting
    the requirements of the certificate policy;

-   Competent authorities - An audit is an important component of any
    authorisation, regulation, licensing or other recognition process.
    The competent authority would utilise the evaluation report as part
    of the initial and on-going recognition process; and

-   Policy authorities who are a primary user of the evaluation report,
    as the audit is one of the requirements of the certificate policy
    and it demonstrates CA compliance with that policy. The evaluation
    report would also be used by policy authorities in any
    cross-certification negotiations; and

-   Operational authorities. While the evaluation report is not intended
    to provide recommendations for improvement in the internal controls
    of a CA, a value-added benefit of the CA compliance evaluation would
    often include observations of the auditor for improvements in
    operations.

527. **Security Accreditation Authority** -- An agent of the CA domain
     or enterprise. The security accreditation authority is responsible
     for:

-   Approving the operation of the CA in a particular mode using
    particular safeguards; and

-   Accepting residual security risks on behalf of the CA domain or
    enterprise.

528. **Policy Authority** -- An agent of the CA domain or enterprise.
     The policy authority is responsible for:

-   Selecting and/or defining documentation for use in the CA domain or
    organisational enterprise;

-   Approving any cross-certification or interoperability agreements
    with external domains;

-   Approving practices which the CA must follow by reviewing the

-   CPS to ensure consistency with the CP; and

-   Providing policy direction to the operational authority**.**

529. **Operational Authority** -- An agent of the CA domain or
     enterprise. It should be noted that in some business models, there
     might be several operational authorities involved in the process of
     generating a certificate. In most cases, all elements of the CA
     domain or enterprise must be accredited to establish the required
     level of trust for a particular certificate. The operational
     authority is responsible to the policy authority for:

-   Interpreting the certificate policies that were selected or defined
    by the Policy Authority;

-   Developing the practices documenting compliance to the policies and
    other requirements;

-   Ensuring that the practice statements are updated as required; and

-   Operating the CA or scheme in accordance with the practice
    statements*.*

530. **Subscriber** -- A member of the CA domain or enterprise. A party
     who is the subject of a certificate and who is capable of using,
     and is authorised to use, the private key, that corresponds to the
     public key in the certificate. Responsibilities and obligations of
     the Subscriber would be as required by the CA's policy.

531. **Relying Party** - May or may not be a subscriber of the same
     domain. The relying party is a recipient of a certificate who acts
     in reliance on those certificates and/or digital signatures
     verified using that certificate.

### Accreditation Framework

532. **Figure 21** illustrates the relationships between the various
     roles. To accommodate either the needs of the legal jurisdiction
     and/or closed and open business models, unique CA accreditation
     models can be postulated by combining roles.

Negotiates to ensure

harmonisation across legal

jurisdictions or communities

of interest

Could give formal recognition to mandatory and/or

voluntary CA accreditation schemes

> Approves, accredits or gives formal recognition to

Competency of CA evaluators

Figure 21: Certificate Authority Accreditation Model

533. Using the above approach, it may be possible to reach a common
     terminology and to facilitate analysis and comparison of
     accreditation approaches of various economies. Through this
     proposal it is expected that the PKI Interoperability Expert Group
     will be able to:

-   Identify the key elements for establishing trust in certification
    processes;

-   Map existing schemes against these key elements; and

-   Identify potential obstacles to cross border authentication.

534. Questions that could be considered by economies in undertaking
     mappings are:

-   Have governments, agencies, or private sector entities developed
    policies that correspond to aspects of the model?

-   In relation to the model, where do policy gaps exist domestically?

-   Will the current model facilitate interoperability across
    jurisdictions or in what ways should it be modified?

535. By using the above approach, APEC will be able to provide guidance
     for member economies when developing their national approach in
     such a manner that interoperability can be achieved. For successful
     rollout of secure electronic commerce, it is essential that a
     common understanding be achieved across such diverse stakeholders,
     such as the product vendors, service providers and regulatory
     authorities.

536. It has been noted that a number of APEC economies are attempting to
     achieve interoperability of public key schemes through other
     initiatives. Those exercises are a potential source of information
     for this project.

## INITIAL Mapping of Certification Authorities Accreditation Schemes

537. Using the methodology set out above, the PKI Interoperability
     Expert Group undertook two surveys of APEC economies to identify
     and map the key elements for establishing trust in certification
     processes and to map the approaches being taken in the various
     member economies against these elements. The purpose of the surveys
     was to highlight commonalities, identify policy gaps and provide a
     framework for analysis of how the variances could be addressed.

### Process

538. The first survey involved two rounds. The following questions
     related to the building blocks for establishing certification
     authority linkages were circulated to all economies were used for
     the first round:

```{=html}
<!-- -->
```
1.  *Is there implemented or planned implementation of a government PKI
    scheme?*

2.  *Describe how PKIs work or would work together within the economy
    and internationally?*

3.  *If PKI is not used or planned, how will e-commerce be implemented?*

4.  *What legislation is used to govern electronic or digital
    signatures?*

5.  *Provide a brief description of the legislation*

6.  *Is industry embracing e-commerce? In what way -- via internet
    browsers, PKI or none?*

7.  *What major CA services are available and used*

8.  *What secure services are used, SSL, Pin/Password, PKI or other*

9.  *Is there a "Competent Authority" function. Who is responsible/how
    does it work?*

10. *Is there an "CA Evaluator Accreditation Authority" Who is
    responsible/how does it work?*

11. *Are there "CA Evaluators" or equivalent? Who is responsible/how
    does it work?*

12. *Is there a "Security Accreditation Authority" function? Who is
    responsible/how does it work?*

13. *Is there a "Policy Authority" function? Who is responsible/how does
    it work?*

14. *Is there an "Operational Authority" function? Who is
    responsible/how does it work?*

15. *Have policies been developed that correspond to the model? Describe
    the policy(ies)*

16. *What work, if any, is being done to enable e-commerce across
    different jurisdictions?*

17. *What work, if any, is being done to enable e-commerce between
    government and industry?*

18. *Provide any comments or remarks to assist the project in
    determining barriers to interoperability*

```{=html}
<!-- -->
```
539. Initial responses were received from 8 member economies (Australia,
     Chinese Taipei, Hong Kong China, Japan, Korea, Singapore, Thailand
     and Canada). A document that consolidated the responses from each
     economy and presented preliminary findings was discussed at TEL 23
     in March 2001[^59].

540. During discussion of the exercise at TEL 23, it was agreed that
     updated input should be sought. It was also agreed that the
     questions should be refined to remove certain ambiguities and be
     refocussed to make a distinction between the public and private
     sector in the responses. A revised set of questions was developed
     and provided to member economies for responses. The questions were:

> ***Legislative/Legal Framework:***

1.  *What legislation is used to govern electronic or digital
    signatures? (Please, provide a brief description of the
    legislation).*

2.  *Is accreditation/licensing of trusted agents (i.e. CAs) required
    for legal effect within the economy? If yes, please provide details
    of the competent authority and scheme in Questions 10 -- 16 below.*

3.  *Is accreditation/licensing of trusted agents (i.e. CAs) required to
    give legal effect from foreign jurisdictions? Please provide details
    of the process in for legal effect in Question 17.*

> ***Current Private Sector Environment:***

4.  *Is industry embracing e-commerce? In what way -- via Internet
    browsers, PKI or none?*

5.  *What secure services are used, SSL, Pin/Password, PKI or other?*

6.  *What major CA services are available and used?*

> ***E-Government Initiatives:***

7.  *Is their implemented or planned implementation of a government PKI
    scheme? Please describe.*

8.  *If PKI is not used or planned, how will e-commerce be implemented?*

9.  *What work, if any, is being done to enable e-commerce between
    government and industry?*

> ***Roles and Responsibilities:***
>
> *For each of the following questions, please report separately on
> public sector and private sector implementations. Please refer to the
> schematic for how the roles have been generically broken down:*

10. *Is there a "Competent Authority" function? Who is responsible/how
    does it work?*

11. *Is there an "CA Evaluator Accreditation Authority"? Who is
    responsible/how does it work?*

12. *Are there "CA Evaluators" or equivalent? Who is responsible/how
    does it work?*

13. *Is there a "Security Accreditation Authority" function? Who is
    responsible/how does it work?*

14. *Is there a "Policy Authority" function? Who is responsible/how does
    it work?*

15. *Is there an "Operational Authority" function? Who is
    responsible/how does it work?*

16. *Have policies been developed that correspond to the model? Describe
    the policy(ies).*

> ***Interoperability/International Dimensions:***

17. *Describe how PKIs work or would work together within the economy
    and internationally?*

18. *What work, if any, is being done to enable e-commerce across
    different jurisdictions?*

19. *Provide any comments or remarks to assist the project in
    determining barriers to interoperability.*

```{=html}
<!-- -->
```
541. In the second round, six of the original eight member economies
     updated their input in accordance with the revised set of
     questions. Responses were received from two additional member
     economies (Malaysia and the United States). At TEL 24 in September
     2001 a matrix of the consolidated input received from both rounds
     was presented[^60].

### General Comments 

542. The initial round of the mapping exercise identified areas where
     there was a high degree of consistency and others where there were
     inconsistencies. The updated information obtained from the second
     round confirmed the preliminary findings. However, the expanded,
     refined data sample afforded by the second round provides a
     stronger basis for analysis and therefore a better indication of
     where future work should be focussed.

543. This mapping exercise made it possible to identify the
     commonalities and variances in approaches to authentication and
     certification services. These are identified in the following list.

### Legal/Legislative Framework

Commonalities:

544. All member economies that responded either already have, or are
     planning to have, legislation to establish a legal framework for
     electronic signatures. Virtually all these legislative frameworks
     establish that a signature may not be denied legal effect simply
     because it is electronic. For most, if not all economies, the
     legislation goes on to establish additional provisions relating to
     government transactions.

     Variances:

545. The legislative framework varies considerably in the degree to
     which the legislation (or regulations) prescribe the technology and
     processes that establish the legal effect for the electronic
     signatures. While the spectrum appears to be narrow in the context
     of the public sector environment with governments, in most cases,
     establishing clear criteria that must be met for their operations,
     it is considerably broader in the context of the private sector.
     Specifically, the spectrum relative to the private sector ranges
     from granting legal effect only to signatures certified by licensed
     CAs on the one hand, to essentially leaving it up to the parties
     involved to determine what technology and process they will use to
     establish legal effect for the signatures associated with their
     particular transactions on the other hand.

546. It follows, therefore, that the legislation also varies
     considerably in scope. Some set out an administrative framework for
     licensing CAs and establishing duties and responsibilities for the
     various players. Others take a very minimalist, technology neutral
     approach leaving the market to sort out issues such as allocation
     of duties and liabilities.

### E-Government Initiatives

Commonalities:

547. Virtually all member economies have identified e-government as a
     strategic priority. The solutions are predominantly PKI-based and
     are being deployed by government for government. A small number are
     partnering with the private sector and using their services for
     government requirements.

     Variances:

548. Most government initiatives are being developed to eventually
     provide for linkages to the private sector. For some, the path for
     such linkages is straightforward (i.e. licensed CAs will be
     recognised), but the vast majority are relying on CAs meeting the
     requirements of their cross-certification or cross-recognition
     policies to be the "test".

### Current Private Sector Environment

Commonalities:

549. The consistency in this area is that a wide range of e-commerce
     solutions is currently being deployed by the private sector in all
     member economies (i.e., SSL, PKI and Internet browsers). In all
     cases, the solution chosen depends on the security requirements of
     the environment and/or the particular transaction.

     Variances:

550. The variances in this environment relate not so much to the
     technology being deployed, but rather the legislative environment
     within which the private sector functions (i.e. whether licensing
     of CAs is required). As such, the variances will seemingly be
     discussed and further analysed in that context.

### Roles and Responsibilities

Commonalities:

551. The responses indicate that virtually all the functions and
     responsibilities delineated in the model are recognised and present
     in all approaches. There is therefore a common understanding of the
     necessary components of schemes. Areas of most consistency relate
     to competent authorities and with most indicating that it was a
     role performed by some form of governmental agency or
     representative. A second area of high consistency relates to the
     requirement that there be some form of independent evaluation of
     entities providing CA services.

     Variances:

552. There is, however, a marked difference in how the functions and
     responsibilities are allocated across the players. In many cases,
     single entities are performing multiple roles depicted in the
     model. There are also obvious differences arising from the fact
     that the roles and duties are prescribed in legislation in some
     instances, and left to the market to determine in other cases.

### Interoperability/International Dimensions

Commonalities

553. The responses confirm that member economies view interoperability
     and cross-certification as important to this environment. All
     recognise the need to work co-operatively in this area to minimise
     the potential for trade barriers. It is understood that the work
     needs to be at the policy level but that aspects related to
     "bridging" legal frameworks and technical compatibility (e.g.
     compatibility of directories etc.) may also need to be addressed.

     Variances

554. There appears to be little consistency in the approaches being
     pursued to achieve the desired interoperability. Some are pursuing
     cross-certification while others are providing for alternative
     solutions involving cross-recognition or mutual recognition
     arrangements. In the absence of further analysis, this variety of
     approaches has the potential to create impediments and potentially
     barriers to interoperability as it is unclear the degree to which
     they meet similar objectives.

### Conclusions and Areas for Future Work:

555. In order for organisations to securely interact and transact with
     each other electronically across jurisdictional boundaries, an
     analysis of the above variances is required to see how they can be
     adapted to meet the same objectives. The following list identifies
     the areas where future work could be focussed.

556. **Legislative Frameworks** There is a need to discuss the policy
     gaps that exist in the legislative frameworks. In particular, there
     is a need to understand the process by which the signatures
     certified by foreign CAs from jurisdictions without licensing
     regimes can be given legal effect by those who jurisdictions with
     licensing regimes. A related question would be to understand the
     process by which a member economy with a licensing regime will
     provide for a CA from a non-licensed regime to operate in its
     jurisdiction (i.e. will member economies "license" foreign CAs, and
     if so, how? Would this need to be accomplished via a government to
     government process? If so, there would be implications for those
     member economies pursuing a private-sector led approach to
     certification services.)

557. **Accreditation Schemes** It would be useful to define basic common
     elements or parameters for accreditation schemes. A common approach
     to accreditation can form the basis for mutual recognition of CAs
     between different jurisdictions. Common accreditation standards and
     processes can be used to facilitate consistent legal and technical
     practices. It could also be a building block to establishing common
     criteria for CAs to be on trust lists. While the model of roles and
     responsibilities used in the mapping approach has been useful in
     terms of setting out the areas of responsibility in any scheme, it
     may not necessarily be as important to know who is performing the
     function but rather simply that it is being performed. As long as
     there is a requirement in schemes for independent evaluation that
     adhere to similar guidelines and criteria, a common level of trust
     or reliability should be there.

558. **Interoperability** The mapping exercise has demonstrated the need
     to more closely analyse how interoperability across member
     economies can be achieved. A first step would be to develop a
     common understanding of the various means of achieving
     interoperability (i.e., cross-certification, cross-recognition,
     mutual recognition agreements etc.). A common understanding and
     articulation of the general processes involved and component
     requirements of each approach would be helpful. Information from
     the various pilots and trials within and between economies would
     increase understanding of the issues involved.

## Second Mapping of Certification Authorities Accreditation Schemes

559. At TEL 25 in March 2002 it was agreed to undertake a further
     survey. The purpose of this survey was to compile updated
     information on the legislative/legal framework for electronic
     authentication and gather findings on the security guidelines and
     regulations required of certification authorities in the respective
     APEC member economies. The purpose of this exercise was to allow
     the PKI Interoperability Expert Group to assess
     cross-jurisdictional challenges and impediments and identify any
     gaps in the security standards, guidelines or practices between the
     APEC economies for certification authorities. This results obtained
     will help determine how varying legislative/legal frameworks can be
     "bridged" to provide for cross-jurisdictional acceptance of
     authentication services and provide for legal effect of electronic
     signatures. They also highlight the need to devise international
     standards to address the gaps in technical and operational
     approaches.

### Process

560. A number of the questions used in this survey were based on key
     elements of IETF RFC 2527 which is the widely adopted framework for
     constructing CPs and CPSs. Many of the accreditation schemes use
     this framework for accrediting CAs within their schemes. The
     questions were as follows:

> *I. LEGISLATIVE/LEGAL FRAMEWORK*
>
> *For each of the following questions, please provide information in
> the following contexts:*
>
> *Public sector only?*
>
> *Public and private sector?*
>
> *Separate public and private sector?*
>
> *1. Please name and provide the URL for any legislation you have that
> sets parameters for the establishment and operation of authentication
> service providers. Is there a licensing requirement? If no legislation
> exists and there is no licensing requirement, please describe any
> framework that has been established for the operation of these
> services .*
>
> *2. If there is legislation, describe any aspects that limit or set
> parameters for the operation or use of foreign authentication services
> in your economy.*
>
> *3. What is the framework in which electronic signatures operate? Is
> their legal effect established in legislation and, if yes, how does it
> function?*
>
> *4. How do electronic signatures that have been created outside your
> economy have legal effect within your economy?*
>
> *II. REGULATION STANDARDS*
>
> ***Financial Responsibility for Recognized/Licensed/Accredited
> Certification Authorities***
>
> *1. What are the financial requirements for licensed certification
> authorities?*
>
> ***Fees for Recognized/Licensed/Accredited Certification Authorities
> (for statistics purposes)***
>
> *2. Is there an application fee for the
> license/recognition/accreditation and what is the renewal fee on a
> yearly basis for it?*
>
> ***Recognition of Foreign Certification Authorities***
>
> *3. What are the requirements for recognition of foreign certification
> authorities and their certificates?*
>
> *III. CERTIFICATE POLICY STANDARDS*
>
> *1. Are technical standards mandated through legislation or through
> any other formal arrangements?*
>
> *2. Is the Certification Practice Statement and Certificate Polices of
> recognized/accredited/licensed certification authorities prescribed by
> legislation or regulations to be based on the Internet X.509 framework
> (RFC 2527) adopted by the Internet Engineering Task Force? If so, are
> there indispensable items in the CPS?*
>
> *3. Are directory standards clearly prescribed towards the use of
> X.500 Directory Service produced by ITU and ISO?*

#### *IV. TECHNICAL STANDARDS* 

> ***Registration and Initial Identity Validation***
>
> *1. What are the identification and authentication requirements for
> the CA or RA to validate the identity of a subscriber? (ie
> organization or individual) What are the types of documentation and/or
> identification credentials required?*
>
> ***Private Key Protection and Cryptographic Module Engineering
> Controls***
>
> *2. What standards, if any, are required for the cryptographic module
> used to generate the keys for CA operations, RA operations, subscriber
> operations?*
>
> *3. Is the private key under n out of m multi-person control?*
>
> *4. Is the private key escrowed, backed up or archived? If so, who is
> the escrow/backup or archive agent? What form is the key
> escrowed/backed up/ archived in (examples include plaintext,
> encrypted, split key), and what are the security controls on the
> escrow/backup/archive system?*
>
> ***Key Pair Generation, Installation and distribution***
>
> *5. Are there security guidelines to determine if the key generation
> is performed in hardware or software and how are the keys handed over
> securely?*
>
> *In the case of CA key generation, how is the private key provided
> securely to the entity? How is the entity\'s public key provided
> securely to the certification authority? How is the CA\'s public key
> provided securely to potential relying parties?*
>
> *In the case where CAs provide a generation package for subscribers,
> what are the security safeguards for secure generation of keys?*
>
> *6. Are there provisions for separate confidentiality and signature
> key pairs?*
>
> ***Choice of Algorithms***
>
> *7. What cryptographic algorithms if any are prescribed for the
> electronic signature system? What are the key sizes?*
>
> ***Naming Conventions***
>
> *8. Are there any guidelines to standardise the contents of
> Distinguished Names Components in the certificate fields? ie use of
> non-standard or legacy values within distinguished names, assumptions
> made about the ordering of distinguished names attributes (eg assuming
> common name is always encoded last or that only one organisational
> unit attribute is allowed)*
>
> ***Personnel Security Control***
>
> *9. What are the controls for trusted personnel and are there security
> screening procedures in place for them (ie police record screening and
> financial checks of key personnel)?*
>
> ***Physical Security Controls***
>
> *10. Are there physical security requirements for the protection of
> the CA/RA, including the protection of the private key, protection of
> personal information in registration records etc?*
>
> ***Systems and Software Integrity and Control***
>
> *11. What standards if any are required for systems and software
> integrity and control?*
>
> ***Term of validity of electronic certificates***
>
> *12. What is the duration for the term of validity (or maximum
> certificate revocation period) of electronic certificates?*
>
> ***Archival of Certificates/Logs/Customer Records***
>
> *13. What is the period of retention of archive?*
>
> ***Availability of General Purpose Repository and Certificate
> Revocation List (CRL)***
>
> *14. What are the availability status of the general-purpose
> repository, certificate revocation list (CRL) issuance frequency,
> revocation request grace period and time limits for certificate
> suspension period?*
>
> ***Processing of certificate suspension or revocation***
>
> *15. What is the availability of facilities for processing certificate
> suspension and revocation?*
>
> ***Business Continuity Planning***
>
> *16. Are there provisions for business continuity planning and for
> disaster recovery planning in the guidelines?*
>
> *17. In the event that a CA discontinues its operations, what are the
> relevant provisions and how can both past and present transactions be
> validated?*
>
> ***Compliance Audits***
>
> *18. What is the frequency of compliance audits for licensed
> certification authorities, what are the requirements for audit and who
> are qualified to undertake such audits?*

***\[NEED TO INSERT THE REPORT TO TEL 26 HERE\]***

## DETAILED MAPPING OF SELECTED PKI SCHEMES

561. A number of individual economies have been examining bilateral or
     multilateral approached to cross-certification or
     cross-recognition. These activities have been regularly reported to
     the eSecurity Task Group meetings. Some of these are sector
     specific such as the Pan Asian e-Commerce Alliance[^61], while
     others are examining economy to economy interoperability such as a
     current pilot project between Japan, Korea and Singapore under the
     auspices of the Asia PKI Forum[^62].

562. Several other economies are undertaking a more detailed mapping of
     the accreditation or cross-certification criteria for their
     government or economy wide schemes. The methodology involves
     comparison of procedures or standards used for each element of
     RFC 2527. It is a more detailed mapping than the broader APEC study
     discussed above and could provide the basis for cross-certification
     or cross-recognition agreements between the schemes rather than
     individual CAs under those schemes.

# APPENDIX 1

# Terminology Mapping

  ----- --------------------- ---------------------------- ---------------------
  No    Technology-Neutral    Definition                   PKI-Centric Term
        Term                                               

  1\.   Authenticator         A parameter for the          Public Key
                              authentication of individual 
                              or organisational identity,  
                              roles or attributes.         

  2\.   Authentication        The technology used to       Public-Key
        Technology            generate, issue or interpret Cryptography
                              an authenticator.            

  3\.   Authentication        A body that generates,       CA
        Service Provider      issues, receives or stores   
                              all or part of an            
                              authenticator and might add  
                              some further service.        

  4\.   Authentication Scheme A scheme that involves       PKI
                              authenticators and           
                              authentication service       
                              providers.                   

  5\.   Certificate           An electronic document       Certificate
                              generally issued by a third  
                              party that binds an          
                              authenticator to a specified 
                              user.                        

  6\.   Cross-Certification   The practice of cross        Cross-Certification
                              recognition of another       
                              authentication service       
                              provider\'s authenticator to 
                              an agreed level of           
                              confidence and is normally   
                              evidenced in a contract or   
                              agreement. (An extension of  
                              the concept used in PKI)     

  7\.   High Level            A body with responsibility   Root CA, Controller
        Authentication        relating to the activities   of Certification
        Authority             of a number of subordinate   Authorities
                              authentication service       
                              providers.                   
  ----- --------------------- ---------------------------- ---------------------

#   {#section-4 .unnumbered}

# APPENDIX 2

# Selected Definitions of Cross-Certification

### Internet X.509 PKI -- PKIX Roadmap[^63] 

A CA certificate is a certificate in a hierarchy that is neither a
self-signed certificate, nor an end-entity certificate. \[2459bis\] does
not make a difference between a CA certificate and a cross certificate
since it defines a cross-certificate as \"a certificate issued by one CA
to another CA\". Some people in the WG believe that a cross certificate
is a special kind of CA certificate. A cross certificate is issued by a
CA under one Top CA for another CA under a different Top CA. CAs in the
same hierarchy have part of their names imposed by the Top CA or by the
CAs under that Top CAS. When a cross certificate is issued, there is no
relationship between the names of the CAs.

Typically, a cross-certificate is used to allow client systems or end
entities in one administrative domain to communicate securely with
client systems or end users in another administrative domain. Use of a
cross-certificate issued from CA_1 to CA_2 allows user Alice, who trusts
CA_1, to accept a PKC used by Bob, which was issued by CA_2.
Cross-certificates can also be issued from one CA to another CA in the
same administrative domain, if required.

Cross-certificates can be issued in only one direction, or in both
directions, between two CA\'s. That is, just because CA_1 issues a
cross-certificate for CA_2, CA_2 does not have to issue a cross-
certificate for CA_1.

### Electronic Commerce Promotion Council of Japan (ECOM) Certification Authority Working Group, Cross-Certification Guidelines

... the reciprocal certification process of two certification
authorities. Cross certification enables the reciprocal use of the
certificates issued by two certification authorities, increasing the
usage range of users' certificates.

### VeriSign CPS (Version 1.2)

A condition in which either or both a VeriSign PCA and a non-VeriSign
certificate issuing entity (representing another certification domain)
issues a certificate having the other as the subject of that
certificate.

### A Matter Of Trust \-- Deploying A Public-Key Encryption System Extends Trust Across Boundaries[^64], by Amy K. Larsen

... a process in which two certificate authorities in different domains
securely pass key information between them. Those certificate
authorities basically create cross-certificates that guarantee to the
user that one certificate authority trusts the other and that all the
documents validated by it are unchanged.

### Issues Relating to the Use of Electronic Authentication, APEC Electronic Authentication Task Group

The practice of cross recognition of another authentication service
provider's authenticator to an agreed level of confidence and is
normally evidenced in a contract or agreement. (An extension of the
concept used in public key infrastructures)... The process of
cross-certification includes legal, technical and policy review of each
other's authentication scheme policies and authentication scheme
practice statements, their implementation and operational management\...

### Entrust Technologies White Paper -- The Concept of Trust in Network Security 

Cross-certification is a process in which two CAs securely exchange
keying information so that each can effectively certify the
trustworthiness of the other's keys. Essentially, cross-certification is
simply an extended form of third-party trust in which network users in
one CA domain implicitly trust users in all other CA domains which are
cross-certified with their own CA.

### The Burton Group Network Strategy Report - Public Key Infrastructure Architecture

In either a hierarchical or a peer relationship, two CAs can exchange
the information necessary to establish cross-certificates between them,
thus creating a trust relationship.

# 4. SHARED SECRET TECHNOLOGIES

1.  The use of shared secrets as an authentication tool dates back as
    far as, if not further than, the use of signatures. Passwords were a
    common means of authentication of entitlements to pass or membership
    of a community to guard posts in historic times. Shared secrets have
    also been used for a number of years as electronic access control
    techniques. Most readers would still use a password, for example,
    when logging on to their systems. In addition, passwords or PINs
    have been used for a number of years, in conjunction with magnetic
    swipe cards, for access to ATMs and EFTPOS. As a result, many
    businesses are familiar with the business risks associated with
    passwords and PINs.

```{=html}
<!-- -->
```
563. The shared secret group covers implementations such as symmetric
     cryptography; passwords/PINs; and challenge/response. Technologies
     in this group generally only provide for authentication. However,
     only symmetric cryptography can provide confidentiality and
     integrity capabilities in some implementations. Depending on
     whether the secret is unique to each pair of parties, non
     repudiation is possible. This group mainly supports closed business
     models as the secret has to be shared between both parties and
     there is likely to be some form of prior arrangement. It can,
     however, support open but bounded models through a chaining
     arrangement where an authenticator in one closed system could
     generate authenticator for another closed system. For example
     Kerberos[^65] could be used in this way.

## DEFINITIONS

564. The following definitions are taken from:

     **\[NSTISSI\]** National Security Telecommunications and
     Information Systems\
     Security Instruction (NSTISSI) No. 4009, \"National Information
     Systems Security (INFOSEC) Glossary"[^66],

     **\[AJP\]** M. Abrams, S. Jajodia, and H. Podell, eds, "Information
     Security - An Integrated Collection of Essays"[^67]

+--------------------+-------------------------------------------------+
| challenge and      | Prearranged procedure in which a subject        |
| reply              | requests authentication of another and the      |
|                    | latter establishes validity with a correct      |
|                    | reply. \[NSTISSI\]                              |
|                    |                                                 |
|                    | Note: More commonly called challenge/response   |
+--------------------+-------------------------------------------------+
| computer           | Use of a crypto-algorithm program by a computer |
| cryptography       | to authenticate or encrypt/decrypt information. |
|                    | \[NSTISSI\]                                     |
+--------------------+-------------------------------------------------+
| credentials        | Information, passed from one entity to another, |
|                    | used to establish the sending entity\'s access  |
|                    | rights. \[NSTISSI\]                             |
+--------------------+-------------------------------------------------+
| crypto-algorithm   | Well-defined procedure or sequence of rules or  |
|                    | steps, or a series of mathematical equations    |
|                    | used to describe cryptographic processes such   |
|                    | as encryption/decryption, key generation,       |
|                    | authentication, signatures, etc. \[NSTISSI\]    |
+--------------------+-------------------------------------------------+
| key                | Usually a sequence of random or pseudorandom    |
|                    | bits used initially to set up and periodically  |
|                    | change the operations performed in              |
|                    | crypto-equipment for the purpose of encrypting  |
|                    | or decrypting electronic signals, or for        |
|                    | determining electronic counter-countermeasures  |
|                    | patterns (e.g., frequency hopping or spread     |
|                    | spectrum), or for producing other key.          |
|                    | \[NSTISSI\]                                     |
+--------------------+-------------------------------------------------+
| list-oriented      | Computer protection in which each protected     |
|                    | object has a list of all subjects authorized to |
|                    | access it. See also ticket-oriented.            |
|                    | \[NSTISSI\]                                     |
+--------------------+-------------------------------------------------+
| passphrase         | Sequence of characters, longer than the         |
|                    | acceptable length (C.F.D.)\* of a password,     |
|                    | that is transformed by a password system into a |
|                    | virtual password of acceptable length.          |
|                    | \[NSTISSI\]                                     |
+--------------------+-------------------------------------------------+
| password           | Protected/private alphanumeric string used to   |
|                    | authenticate an identity or to authorize access |
|                    | to data. \[NSTISSI\]                            |
+--------------------+-------------------------------------------------+
| PIN                | Personal Identification Number. Similar to a    |
|                    | password but using only numeric characters      |
+--------------------+-------------------------------------------------+
| secret key         | Cryptography based on a single key (or          |
| cryptography       | symmetric cryptography). It uses the same       |
|                    | secret key for encryption and decryption.       |
|                    | Messages are encrypted using a secret key and a |
|                    | secret key cryptographic algorithm, such as     |
|                    | Skipjack, DES (Data Encryption Standard), RC2   |
|                    | (Rivest Cipher 2), or RC4 (Rivest Cipher 4).    |
|                    | \[AJP\]                                         |
+--------------------+-------------------------------------------------+
| secret key         | The key that two parties share and keep secret  |
|                    | for secret key cryptography. Given secret key   |
|                    | algorithms of equal strength, the approximate   |
|                    | difficulty of decrypting encrypted messages by  |
|                    | brute force search can be measured by the       |
|                    | number of possible keys. For example, a key     |
|                    | length of 56 bits is over 65,000 times stronger |
|                    | or more resistant to attack than a key length   |
|                    | of 40 bits. \[AJP\]                             |
|                    |                                                 |
|                    | Note: In some implementations the same secret   |
|                    | key may be shared between all parties in a      |
|                    | closed group.                                   |
+--------------------+-------------------------------------------------+
| seed key           | Initial key used to start an updating or key    |
|                    | generation process. \[NSTISSI\]                 |
+--------------------+-------------------------------------------------+
| session key        | A secret key generated for a particular session |
|                    | between two parties and then discarded.         |
+--------------------+-------------------------------------------------+
| symmetric          | See secret key cryptography                     |
| cryptography       |                                                 |
+--------------------+-------------------------------------------------+
| ticket-oriented    | Computer protection system in which each        |
|                    | subject maintains a list of unforgeable bit     |
|                    | patterns called tickets, one for each object a  |
|                    | subject is authorized to access. See            |
|                    | list-oriented. \[NSTISSI\]                      |
+--------------------+-------------------------------------------------+
| user               | Person or process authorized to access an       |
|                    | IS^\*\*^. \[NSTISSI\]                           |
+--------------------+-------------------------------------------------+
| user ID            | Unique symbol or character string used by an    |
|                    | IS^\*\*^ to identify a specific user.           |
|                    | \[NSTISSI\]                                     |
+--------------------+-------------------------------------------------+
| virtual password   | IS^\*\*^ password computed from a passphrase    |
|                    | meeting the requirements of password storage    |
|                    | (e.g., 64 bits). \[NSTISSI\]                    |
+--------------------+-------------------------------------------------+

\* CFD Common Fill Device

\*\* IS Information System

## TECHNOLOGY

565. The principal forms of shared secrets are

-   symmetric cryptography (secret key cryptography);

-   passwords;

-   passphrases;

-   personal identification numbers (PINs); and

-   challenge/response (challenge and reply).

### Symmetric Cryptography

566. Symmetric cryptography is generally considered an encryption tool.
     However, the possession of the secret, in this case a key, can also
     fulfil an authentication function. If only X and Y share a key and
     Y receives a message encrypted with that key then Y can assume that
     the message has come from X. Furthermore a secret key can also be
     used to encrypt a hash total providing message integrity. As the
     use of symmetric cryptography is quite mature, a number of IETF
     standards[^68] exist. Special implementations such as Kerberos have
     achieved widespread use. In some implementations of symmetric
     cryptography the secret key is reused while in others it is used as
     a seed key to generate a session key. A further implementation
     involves the sharing of a session key produced by one user and
     transferred to another using asymmetric, or public key,
     cryptography to protect its confidentiality. This last case is
     technically not a hybrid approach as the asymmetric cryptography is
     a security device and is not directly involved in the
     authentication process. However the level of security can impact on
     the reliability of the authenticator. This issue is discussed in
     more detail in the Hybrid Technologies Chapter (Chapter 7).

### Password/Passphrases/PINs

567. These are also well established technologies for electronic
     authentication having been used as access control techniques for
     computers and ATMs for several decades. In some implementations
     encryption is used to protect the password, PIN etc during
     transmission. As with symmetric cryptography above, this issue is
     discussed in more detail in the Hybrid Technologies Chapter
     (Chapter 7). A further implementation is the use of one time
     passwords. As this approach is more closely related to
     challenge/response implementations, it has been included in that
     section. Authentication is achieved by verifying the credential
     supplied against the credential included in a list held by the
     recipient.

### Challenge/Response:

568. In these technologies the user requests access, for example, to a
     server; the server issues a challenge; the user provides response
     based on a generation process and finally the server verifies the
     response and grants access. The approach involves synchronisation
     of processes carried out by both the user and the server. These can
     depend on factors such as time where a one time password is
     changing at regular intervals (eg every minute) for both the user
     and server. At the same point in time both should have the same
     password. Another approach is for both parties to use the same
     algorithm so that if the challenge is entered into the process it
     will provide a response to match that generated by the server.
     There are other challenge response approaches under development.

569. While it is possible for the processing to occur on a users
     computer, it is more common for the user to have a token under his
     or her control to undertake the appropriate process. In some cases
     the token itself may be protected by a PIN to control access.
     Challenge/response approaches are most commonly used for
     authentication in access control rather than individual
     transactions.

570. It is not intended that this chapter address technical aspects of
     particular shared secret techniques. Rather it will identify the
     aspects that are common to all techniques and relevant to the
     general discussion of electronic authentication.

571. Shared secrets involve the generation and distribution of the
     secret so that all parties to the scheme have a copy of the secret.
     For subsequent authentication the user sends the secret and this is
     compared with the recipient's stored copy of the secret.

![](media/image7.wmf){width="5.513888888888889in"
height="2.3472222222222223in"}

Figure 22: Shared Secret

572. As mentioned in the General Issues Chapter (Chapter 1), many
     implementations of shared secrets use cryptographic techniques to
     prevent capture of the secret for subsequent replaying or generate
     a new secret for each transaction, again to prevent capture and
     replay. Other implementations store the secret on tokens under the
     control of the individual and the token confirms the secret and
     then generates an authentication message using another technology
     such as asymmetric cryptography. The issues associated with these
     approaches are discussed further in the Hybrid Technologies Chapter
     (Chapter 7).

## USE IN ELECTRONIC BUSINESS MODELS

573. Shared secret approaches rely heavily on the secret being
     restricted to authorised parties. The binding between an individual
     and the authenticator (secret) is achieved through this limit on
     sharing of the secret although in some instances a secret may be
     shared amongst a group rather than between two parties. It is
     possible to input a secret into a machine to allow machine to
     machine authentication. The main factor in determining the degree
     of trust that can be placed on the authenticator is the security of
     the secret itself. This is discussed further under the Trust
     Section of this chapter.

574. While shared secret authenticators can provide a strong binding
     with an individual or machine, they do not provide the same
     facility for corporate, role or attribute authentication. However
     this has also been the case in the paper world where, for example,
     written delegations have been used to link an identity to a
     particular role, attribute or corporate identity. More commonly
     individuals would have different passwords or PINs in respect of
     different attributes or roles.

### Open Model

575. Shared secrets are not generally useful in this model as there
     needs to be a prior arrangement to distribute the secret or secret
     generation process. While asymmetric cryptography could be used to
     distribute the secret, even this approach generally relies on some
     form of authentication occurring before the secret is shared. You
     need to know you are sharing the secret with the right person.

576. The type of open network systems for which Kerberos was designed do
     not equate to the open business model described in the General
     Issues Chapter (Chapter 1). While Kerberos can carry out cross
     realm certification[^69] the requirement to be a member of a
     Kerberos realm places a boundary around the model.

577. Shared secret technologies do not lend themselves to open business
     models.

### Closed Model

578. This model requires some form of prior relationship between the
     parties and this relationship could involve the distribution of the
     shared secret or secret generation process. It could also involve
     establishment of schemes to protect the exchange of the secret.
     Within an organisation this could be simply reliance on security of
     the internal network. In external networks it could involve the use
     of encryption to protect the secret. The use of PINs and passwords
     for ATMs, EFTPOS and online banking and the use of passwords as
     access controls for computer systems are classic examples of a
     closed models.

579. Shared secret technologies lend themselves to closed business
     models.

### Open-But-Bounded Model

580. It is possible for a chain of trust to be established using a
     series of shared secrets. this would allow authentication to move
     outside of a purely closed group and allow parties with no direct
     relationship to authenticate themselves either unidirectionally or
     bidirectionally. This is the principle employed by some
     implementations of Kerberos. This process involves a chain of
     secrets, implemented through tickets, rather than extended sharing
     of the original secret. Other implementations involving chains of
     secrets are possible. However, such chains involve a series of
     agreements between each link in the chain which place a boundary on
     the process.

581. Shared secret technologies can lend themselves to open-but-bounded
     business models.

## USER REQUIREMENTS

582. Shared secret approaches are widely accepted among both the
     business and user communities largely as a result of the use of
     PINs with Automatic Teller Machines (ATM) and Electronic Funds
     Transfer Point of Sale (EFTPOS) terminals and the use of passwords
     in the computer environment. The main disadvantage has been the
     cost and security requirements of the infrastructure required to
     distribute the secrets. However, in many cases cost effective
     solutions have been developed, have wide user acceptance and have
     been integrated into business models. The same can be said for
     symmetric cryptography where key distribution is a long established
     technique.

583. A further disadvantage is that typically secrets are shared between
     discrete parties. Therefore to transact with a number of parties
     will require the use of the same number of secrets. This will
     require users to be able to store that number of secrets.

584. Cost associated with this approach will vary according to the type
     of secret, the implementation and the parties. For an individual
     user the cost can be nil if the person chooses to remember the
     secret. This is commonly the case with PINs and passwords at
     present. Alternatively applications are now available at relatively
     low cost that allow users to store a number of PINs and passwords
     on their systems protected by a single access control. The security
     of such applications would need to be considered in the light of
     the aggregate exposure in the case of compromise of the single
     access control. In other implementations users may use a token such
     as a smart card to store on or more secrets. This is a slightly
     higher cost option.

585. The cost to business will vary depending on its role and client
     base. A business with a small client base will probably be able to
     adopt similar implementations to those of individual users. However
     businesses with large client bases will need to implement secure
     facilities to store, distribute and process shared secret
     authenticators. As mentioned earlier a number of businesses have
     been using this approach for ATM and EFTPOS networks and the
     business models are well established. The impact is more likely to
     be on new Internet businesses who will need to implement new
     systems. However, it should be noted that this technology does not
     require the type of infrastructure required for asymmetric
     cryptography nor the readers associated with biometrics and may
     therefore incur a lower implementation and support cost.

586. The use of shared secret technologies is more familiar to most
     users than other technologies. However there can be some
     inconvenience arising from the number of secrets that may be
     required to be stored, particularly for newly establishing
     businesses with potentially large client bases.

## CERTIFICATION MODELS

587. As the process of sharing a secret requires some form of prior
     contact between the parties shared secrets are generally used in a
     no certification model. While some might argue that the chaining
     process outlined in paragraph 20 above could be considered an
     informal certification model, the fact is that a different
     authenticator is used in each link of the chain. The ultimate
     recipient does not receive the users secret, only that of the
     previous link in the chain. This approach is therefore a chain of
     non certification models.

## TRUST

588. The level of trust in a shared secret depends on a number of
     factors including the strength of the secret, the security of the
     secret and the implementation of technology for the distribution
     and use of the secret.

### Strength of the Secret

589. In purely mathematical terms the strength of a secret can be
     calculated as:

-   password/passphrase - 26^n^ where n is the number of letters in the
    word or phrase. This can be increased to 52 ^n^ if upper and lower
    case are used and 72 ^n^ if numbers and characters are included;

-   PINs - 10^n^ where n is the number of digits in the PIN; and

-   symmetric cryptography - 2^n^ where n is the number of bits in the
    key.

590. Determination of the strength of symmetric cryptography will also
     depend on the strength of the algorithm to which the key is
     applied. Standards have been developed for both symmetric
     algorithms and their implementation. In a number of cases
     algorithms are placed in the public arena to allow experts to test
     their strength. Certain algorithms are known to have weak keys
     which should be avoided.

591. In addition the strength of passwords, passphrases and PINs can be
     reduced by use of words, phrases and numbers that can be readily
     associated with the user such as family names, favourite car or
     sporting team. Passwords are further susceptible to 'dictionary
     attacks' where an attacker uses a dictionary to determine a
     password. These weaknesses can be overcome through good selection
     techniques and controls on the number of attempts to submit a
     password.

### Secret Security

592. The security of a secret can be impacted by secret generation,
     secret distribution, secret storage and management, and secret
     transmission processes.

     Secret Generation/Selection

593. Secrets can either be generated, or selected, by an individual user
     and then shared with the other party or a central authority may
     generate secrets for use by its clients and distribute the secret
     to them. There are advantages and disadvantages of both approaches.
     The centralised approach can be used to ensure the generation of a
     truly random secret. This can avoid the tendency for an individual
     to generate a secret, specifically a password, passphrase or PIN,
     which can be easily remembered but can also be easily guessed or is
     vulnerable to a dictionary attack. However, if a secret is not
     easily remembered there may be a tendency for individuals to record
     it to ensure it is not forgotten. The situation for the generation
     of a symmetric key is more complex. The topic of key generation is
     discussed in detail in Chapter 2 and applies equally for generation
     of symmetric keys. There are a number of guides to assist users
     select good passwords issued by bodies such as the US National
     Security Institute[^70]

     Secret Distribution

594. Where secrets are generated centrally they need to be distributed
     to the users by secure means. The level of security for the
     distribution of the secret needs to be commensurate with the loss
     that could occur if the secret were compromised. There are well
     established processes for the distribution of PINs and passwords
     particularly in respect of credit and debit cards. In some cases
     symmetric keys are distributed using asymmetric cryptography
     although this is more commonly used in the encryption context.
     There are also examples of asymmetric cryptography being used to
     protect distribution of PINs and passwords, particularly in terms
     of online registration processes using browsers.

     Secret Storage and Management

595. As with distribution, secret storage must be secured to a level
     commensurate with the loss that could occur to either the user or a
     person transacting with the user if the secret were compromised. As
     mentioned above, there are a number of measures for protecting a
     secret ranging from committing to memory, to storage on computers,
     to use of tokens. One-way encryption can also be used to prevent
     retrieval of a clear text version of a secret. Another important
     measure is to regularly change the secret to reduce the risk and/or
     consequences of an undetected compromise. There are a number of
     standards and similar documentation[^71] which outline good
     practice in storing and managing secrets.

     **Secret Transmission**

596. Secrets are vulnerable to eavesdropping when they are transmitted
     between the user and recipient. Techniques such as encryption can
     be used to protect a secret while it is in transit. The use of
     encryption in these circumstances is to protect the secret and as
     such is not performing an authentication function. Similarly one
     way encryption can be used to prevent a secret being retrieved.
     Again the level of security for the transmission of the secret
     needs to be commensurate with the loss that could occur if the
     secret were compromised.

     **Secret Sharing**

597. Some computer systems and transactions require sophisticated
     security, best attained when a key or password is shared between
     several people in such a way that it can only be reconstructed by a
     sufficiently large and responsible group acting in agreement.
     Secret sharing security systems are used in banks, in other
     financial institutions, in communications networks and computing
     systems serving educational or commercial institutions, though the
     best known examples are military: for instance, in the activation
     of nuclear weapons or missiles, several officers must concur before
     the necessary password can be reconstructed. Conversely, if the
     weapon becomes activate, each of the shareholders knows the other
     officers who entered their passwords were authorised. They have
     been mutually authenticated.

598. Schemes for determining the distribution of the partial information
     to the people involved are known as secret sharing schemes or
     access schemes and lead to shared control. These pieces of partial
     information are known as shares and may be of equal value (as in
     the military examples mentioned above) or more often of unequal
     value, probably arranged according to a hierarchy of some kind. For
     example in a university computing system, shares which lead to the
     reconstruction of the system manager\'s or superuser\'s key are far
     more valuable than those that lead only to a student\'s key.

599. In its simplest form, taking a three digit secret and sharing it
     between three people in such a way that two can recreate it can be
     achieved as follows:

     Secret 1 2 3

     A's share 1 \_ 3

     B's share 1 2 \_

     C's share \_ 2 3

     While no one party knows the whole secret any two can recreate it
     knowing their share and the positions of that share.

600. Secret sharing is discussed in more detail in Appendix 1 to this
     Chapter.

## LIABILITY

601. As shared secrets involve only the parties between whom the secret
     is shared, issues of liability only arise between those parties.
     There is generally no authentication service provider involved with
     this technology. In some cases there may be liability issues
     involving the suppliers of the technology used to generate, store
     or share the secret but these are normal commercial matters and
     will not be covered here.

602. It is possible for liability issues to be addressed by contract at
     the time the secret is shared. This is already the case in respect
     of debit and credit cards where liability is addressed in the terms
     and conditions of use. While the potential for loss, theft and/or
     misuse is higher than with for example, biometrics, many users are
     more aware of their responsibilities and exposures in this area due
     to the established use of this approach both in banking and finance
     and in computer access control.

603. Issues of liability are discussed in more detail in the Legal
     Issues Chapter (Chapter 9)

## ROLES OF PARTICIPANTS

604. The main participants in shared secret schemes are the parties
     between whom the secrets are shared. Generally one party generates
     the secret and shares it with the other or others depending on the
     scope of the scheme. It is the role of all parties to ensure that
     an appropriate technology is selected and implemented, that the
     secret selected or generated is appropriate for the types of
     transactions and that the secret is appropriately secured. There
     may be a role for governments, standards organisations and industry
     bodies for advising on appropriate types of secret technologies.
     There is also a role in developing user confidence particularly
     with this technology where stories of captured passwords and PINs
     are quite common. This is discussed further in the Awareness
     Section.

## INTEROPERABILITY

605. Shared secrets depend on the parties not only sharing the secret
     but also the technologies to utilise that secret. Those
     technologies can range from a simple browser used by an individual
     user to transmit a secret to sophisticated applications used by
     business to receive and process large numbers of secrets. If the
     business's application meets all its authentication requirements
     then interoperability is not an issue for that business. Similarly
     if the browser meets all the individual user's requirements
     interoperability is again not an issue. Interoperability does
     become a problem where a user, business or individual is required
     to maintain a number of authentication technologies.

606. However, if a number of authentication technologies can be stored
     on a user's IT system and are readily available, interoperability
     may not be an issue. This is particularly the case with shared
     secrets, where a user may be able to store a number of secrets and
     the technology to use them on a system and call them up at will.

607. In general, as shared secrets are generally used in closed systems
     interoperability is not an issue for each system. The question is
     how many systems the user needs to communicate with and the degree
     of inconvenience this might cause. However as the technologies
     themselves can use quite different approaches, they do not lend
     themselves to interoperability in the broader sense.

## ACCREDITATION

608. Secrets themselves cannot be accredited as providing the secret for
     examination immediately compromises it. However the secret
     generation process and the secret sharing technology and its
     implementation can be accredited where standards or other normative
     documents exist. There are a number of standards in existence
     relating to symmetric cryptography algorithms and their
     implementation. Similarly there are a number of reputable
     guidelines for passwords, passphrases and PINs as mentioned in
     paragraph 34 above that could also be used as a basis for
     accreditation.

609. While the secrets themselves cannot be accredited, there are a
     number of implementations that prevent the use of less secure
     passwords, PINs and keys. Consideration of this aspect in the
     broader accreditation of implementations can provide a greater
     level of assurance as to the quality of the particular secret being
     used.

## CULTURAL DIFFERENCES

610. In a number of cultures the concept of an individual is subsumed by
     that of the tribe, clan or extended family. Property is owned by,
     and transactions are undertaken on behalf of, the community not the
     individual. PINs and passwords for credit and debit cards are
     commonly shared in such communities. Shared secret technologies
     lend themselves to these cultures. Similarly in cultures where the
     power to sign is transferred by passing on the signing instrument
     such as a chop or seal, the same result can be achieved by passing
     on the secret.

611. Shared secrets are less likely to be impacted by cultural
     differences than other more technological approaches to
     authentication.

## AWARENESS

612. As mentioned earlier, shared secrets is the most commonly used
     authentication technology today due to its widespread use for ATMs,
     EFTPOS and computer access. People are generally familiar with the
     use of secrets such as PINs and passwords and the need to protect
     them. A smaller, but still significant, number are aware of their
     obligations to protect the secret. Even the use of the term secret
     generally produces an image of something that is not to be shared
     with others. Experience has shown that users are generally
     comfortable with a secret as an authenticator in the electronic
     environment. Their concerns are more about the security of the
     secret in the online environment. It is in the area of secret
     security that awareness and confidence has to be raised both for
     users and system implementors.

### Government Awareness

613. Governments have been using shared secrets as an electronic access
     control technique for many years. Passwords have been used in
     computer security since it first became an issue forty years ago.
     To some extent shared secret use has been overtaken by biometrics
     and asymmetric cryptography which are seen as being more secure.
     However, shared secrets continue to enjoy widespread use. The main
     concern with governments is their potential vulnerability to the
     exposure of information. This is the reason for high security
     authentication techniques, particularly in the area of national
     security and the protection of personal data. However, there is
     other information that does not require this level of security. It
     is in this area that shared secrets continue to be used. As risk
     management techniques are commonly used in government security
     circles governments are aware of the benefits of using
     authentication techniques that match the risk to the data. In this
     context they are generally aware of the strengths and weaknesses of
     shared secret technologies.

### Business Awareness

614. Awareness of shared secrets in the business sector is patchy. While
     most have some awareness of the role of shared secrets in their
     personal business dealings, only larger organisations that have
     operated computing facilities are familiar with the strengths and
     weaknesses in the business environment. It is important that
     business be aware of the security requirements when implementing
     this technology. Poorly implemented systems will be exposed, with
     consequent loss of confidence both in the technology and in the
     business. For many, concerns about the security of shared secrets
     in the electronic environment have led to a reluctance to use this
     approach. A major part of business awareness will be to raise the
     confidence of business in the use of this technology. This will
     include provision of accurate information of the various techniques
     and their strengths and weaknesses to allow business to adopt a
     risk management approach in deciding whether the technology is
     suitable for their business model. This is particularly the case
     for small and medium enterprises who would not normally be aware of
     this information.

### Individual User Awareness

615. While individuals are generally familiar with the use of shared
     secrets, confidence in their use in the electronic environment has
     been undermined by stories about capture of credit card numbers.
     While the capture of the number has no direct relationship with
     authentication, the link between a credit card number and its PIN
     or password has resulted in a perception that shared secrets
     themselves are not secure. As discussed earlier, shared secrets can
     be protected in storage and transit. Users need to be made aware of
     this and be provided with information that will allow them to judge
     whether a particular implementation provides adequate security for
     both their authenticator and their transaction.

616. Awareness of this technology and its associated security can be
     raised through industry providing information on their use of the
     technology and how it is implemented. For example browsers already
     incorporate the ability to secure secrets transmitted to websites
     through the incorporation of SSL in the browsers. This can only be
     activated with websites that provide the capability. Both business
     and individual users need to be aware of this capability and how it
     can be implemented. Many users are not aware of the significance of
     the closed padlock icon on their browsers. There is a role for
     browser manufacturers in raising this awareness.

## LEADERSHIP

617. Unlike some of the other technologies mentioned in the General
     Issues Chapter (Chapter 1), governments, businesses and individuals
     have been using this technology for several decades. In the case of
     this technology, leadership is not so much leading in use of the
     technology but rather making people aware that the technology is
     being used.

### Governments

618. The prime leadership role for governments is in establishing the
     necessary legal and policy frameworks to support electronic
     authentication including shared secrets. As the technology has been
     used for years in EFTPOS and ATM transactions, much of the
     framework will already be in place. In most cases the use of the
     technology is in closed systems that are governed by terms and
     conditions of use agreed by the parties. These are supported under
     existing contract law. However problems may occur where technology
     specific approaches do not address or preclude the use of shared
     secret technology. More recently the trend has been towards the
     establishment of technology neutral frameworks that will support a
     range of electronic authentication technologies. This form of
     leadership is required if shared secret technologies are to
     continue to play a significant role in electronic authentication
     and electronic commerce.

619. The other leadership role for governments is through generating
     confidence in the use of the shared secrets by highlighting their
     own use of the technology. As governments adopt risk management
     approaches, they are in a position to provide advice or guidance on
     circumstances where the use of the technology is appropriate and
     how it might be implemented.

### International Organisations

620. Much of the discussions on electronic authentication in
     international organisation to date has focused on the use of
     asymmetric cryptography in public key infrastructures. The
     exceptions have been APEC and the OECD which have specifically
     addressed the wider range of technologies available. Discussions in
     other organisations will need to be extended if the full range of
     electronic authentication technologies are to be allowed to
     develop. Already other international organisations are adopting
     technology neutral approaches in their considerations. This will
     provide the necessary leadership for shared secrets to be
     recognised as a viable electronic authentication technology.

### Business Corporations

621. Many users and businesses use shared secrets in their day to day
     activities without focussing on the fact that they are using them
     as an authentication technique. The main leadership role for
     business is to provide information on how they are using the
     technology. This can be achieved through providing information on
     the way in which they are authenticating transactions both in the
     business to business and business to consumer context. The
     provision of business to consumer information would be consistent
     with the OECD consumer protection guidelines mentioned in Chapter
     1.

### Users and User Groups

622. Users are already using this technology however there is still a
     great deal of concern regarding the security surrounding the
     transmission and storage of shared secrets. User groups have a
     leadership role in informing themselves about the security of this
     group of technologies and their implementation and passing this
     information on to their membership. Users and user groups also have
     a role in informing manufacturers and suppliers of their concerns
     to ensure that implementations are developed that meet those
     concerns.

### IT Industry

623. The IT industry is already providing leadership through the
     incorporation of services in their products such as browsers and
     email packages to protect secrets during transmission. Applications
     have or are being developed to protect secrets when stored on
     systems. Specialist applications are also being developed that
     incorporate shared secret technologies. The industry can continue
     to provide leadership through the development of products that meet
     user requirements and the development of innovative implementations
     of shared secret technologies.

## COMBINATION WITH OTHER TECHNOLOGIES (HYBRIDS)

624. A number of references have been made in this chapter to the use of
     shared secrets in combination with other technologies as part of a
     hybrid approach or to shared secrets being protected by other
     technologies. Similarly in other chapters references have been made
     to symmetric cryptography, a shared secret technology, being used
     to protect other authentication approaches such as biometrics. The
     distinction between the use of several technologies as part of the
     authentication process and the use of one technology as a security
     measure for another technology is rather fine. In the chained
     approach several technologies form part of an authentication chain
     such as a password triggering a private key and therefore a digital
     signature. In this case the authentication, or signing process,
     begins at the point at which the password is entered.

625. In the secured approach one technology is used to protect an
     authenticator that uses a different technology such as a password
     being used to protect a private key. Entering the password releases
     the private key which is then used to apply a digital signature. In
     this case the authentication, or signing process, begins at the
     point at which the private key is applied. These distinctions and
     their implications will be discussed in more detail in the Hybrid
     Technologies Chapter (Chapter 7).

#   {#section-5 .unnumbered}

# APPENDIX 1

# SECRET SHARING[^72]

1.  Public key technology is mature and widespread in commercial
    Internet applications. Currently it is suggested that keys of length
    2048 bits length are safe. However, suppose an electronic signature,
    for example on an electronic will or electronic trade agreement,
    must remain secure for fifty years will its signature still be
    authentic then given future changes in technology?

```{=html}
<!-- -->
```
626. Longer and longer keys have two main disadvantages

-   it is difficult for a legitimate user to store them safely and
    reproduce them exactly when required; and

-   often material that has been authenticated using encryption
    techniques needs to be accessed after all the legitimate
    owners/users of the key have left the organisation.

627. The only method known to protect against these drawbacks is to use
     secret sharing. Secret sharing also allows mutual authentication of
     shareholders.

628. This Appendix aims to allow the reader to make an informed decision
     regarding the kind of shared secret to use and its security while
     safeguarding against human frailties and the passage of time.

629. Computer systems require sophisticated security, best attained when
     a key or password is shared between several people in such a way
     that is can only be reconstructed by a sufficiently large and
     responsible group acting in agreement. Shared security systems are
     used in banks, in other financial institutions, in communications
     networks and computing systems serving educational or commercial
     institutions, though the best known examples are military: for
     instance, in the activation of nuclear weapons or missiles, several
     officers must concur before the necessary password can be
     reconstructed. Conversely, if the weapon becomes activate, each of
     the shareholders knows the other officers who entered their
     passwords were authorised. They have been mutually authenticated.

630. Schemes for determining the distribution of the partial information
     to the people involved are known as secret sharing schemes or
     access schemes and lead to shared control. These pieces of partial
     information are known as shares and may be of equal value (as in
     the military examples mentioned above) or more often of unequal
     value, probably arranged according to a hierarchy of some kind. For
     example in a university computing system, shares which lead to the
     reconstruction of the system manager\'s or superuser\'s key are far
     more valuable than those that lead only to a student\'s key.

631. The best known secret sharing schemes presently available are not
     hierarchical and may be very unwieldy to implement. Other secret
     sharing questions may need more complicated combining rules: for
     example, in Australia, for a referendum to pass, it must be
     approved by a majority of the people in a majority of the states.
     This can lead to compartmentalised and more specialised schemes.
     None of those known at present are really adequate and limit
     flexibility

632. Secret sharing is concerned with the problems of distributing a
     secret among a group of individuals or entities, so that only
     pre-designated collections of individuals are able to recreate the
     secret collectively by combining their shares of the secret.

633. The earliest and most widely studied type of secret sharing schemes
     are called (t,n)-threshold schemes*.* In these schemes the access
     structure - a specification of which of the participants are
     authorised to recreate the secret - comprises all the possible t
     -element subsets selected from an n - element set.

634. The problem of realising i.e. implementing secret sharing schemes
     for threshold schemes was solved independently by Blakley and
     Shamir in 1979. Shamir\'s solution is based on the property of
     polynomial interpolation in finite fields; Blakley\'s solution is
     formulated and solved using finite geometries. For practical key
     management the scheme based on polynomials is simpler.

635. In a (t,n)-threshold scheme, each of the n participants holds some
     shares (also called shadows) of the secret. The parameter t less
     than or equal to n is called the threshold value. A fundamental
     property of the (t,n)-threshold scheme is that the secret can only
     be recreated if at least t shareholders combine their shares, but
     less than t shareholders cannot recreate the secret. The fact that
     the key can be recovered from the combined shares of any t -sized
     subset is a property which makes threshold schemes very useful in
     key management. Threshold schemes tolerate the invalidation of up
     to n-t shares - the secret can still be recreated from the
     remaining intact shares.

636. Secret sharing schemes are also used to control the authority to
     perform critical actions. For example, a bank vault can be opened
     only if say, any two out of three trusted employees agree to do so
     by combining their partial knowledge of the vault combination. In
     this case, even if one of the three employees is not present at any
     given time the vault can still be opened, and no single employee
     has sufficient information about the combination to open the vault.

637. Secret sharing schemes which do not reveal any information about
     the shared secret to unauthorised individuals are called perfect.
     This notion will be formally defined later. We discuss both perfect
     and non-perfect schemes as the latter are proving useful in various
     secret sharing applications.

638. Besides the (t,n)-threshold structures, more general access
     structures are encountered in the theory of secret sharing. General
     access structures apply to situations where the trust-status of the
     participants is not uniform. For example, in the bank scenario
     described earlier, is might be considered more secure to authorise
     either the bank manager, or any two out of three senior employees
     to open the vault.

639. Since 1979 the study of secret sharing has developed into an active
     area of research in cryptography. The fundamental problem of the
     theory and practice of secret sharing deals with the issue of how
     to implement secret sharing for arbitrary access structures. We
     shall later describe some solutions to this problem.

640. We assume there exists a key distribution centre (KDC) which is
     trusted unconditionally.

## TERMINOLOGY

  ---------------------------- ------------------------------------------
  access structure             a formal specification of the participants
                               in a secret sharing scheme which are able
                               to recreate a shared key from their
                               portions of the key.

  Authentication               is one of the two main goals of
                               cryptography (the other is secrecy). An
                               authentication systems ensures that
                               messages which are transmitted over a
                               communication channel are authentic.

  Cheaters                     the participants in a secret sharing
                               scheme which tender corrupt or modified
                               shares to the combiner with the aim of
                               deceiving the other participants as to the
                               nature of the reconstructed secret.

  Combiner                     this is the combination phase in a secret
                               sharing system. The participants tender
                               their shares of a secret to the combiner
                               (usually considered to be an algorithm
                               within a computing machine) whose task is
                               to faithfully reconstruct the secret if
                               sufficient shared of the require type have
                               been received.

  computationally difficult    the security of many cryptosystems depends
  problems                     on the unproven assertion that certain
                               computational problems are inherently
                               difficult. The accepted instances of such
                               problems are: the discrete logarithm
                               problem in various groups; factorisation
                               of RSA moduli; the RSA inversion problem;
                               finding the square roots modulo n.

  conditionally secure         the security of this type of cryptosystem
                               depends on the unproven assumption that
                               instances computational problems, such as
                               the discrete logarithm problem, are
                               difficult to solve.

  Dealer                       this is the initial phase in secret
                               sharing. The secret is selected by the
                               dealer (also usually considered to be an
                               algorithm within a computing machine).
                               Shares of the secret are distributed by
                               the dealer to each participant in the
                               secret sharing scheme.

  discrete logarithm problem   the problem of finding the index, such
                               that raising a fixed generator of cyclic
                               group to this index yields a given element
                               in the group.

  geometric secret sharing     a realisation of a secret sharing scheme
                               using finite geometry. Usually either
                               affine or projective geometries are used.

  Key                          an input provided by the user of a
                               cryptographic system. This piece of
                               information is kept secret and is the
                               source of security in a cryptographic
                               system. Although some times a part of the
                               key information is made public, in which
                               case the secret part is the source of
                               security.

  key authentication           the identity of a party which may possible
                               share a key.

  key confirmation             evidence that a key is held by some party.

  perfect secret sharing       in such a scheme it is impossible to
                               deduce any partial information about a
                               shared key from less than the critical
                               number of shares of the key.

  secret sharing               protecting a secret key by distributing it
                               in such a way that only the authorised
                               individuals can recreate the key.

  threshold scheme             a secret sharing scheme with a uniform
                               access structure in which any collection
                               of shareholders greater than a given
                               threshold can recreate the secret.
  ---------------------------- ------------------------------------------

##  Models for secret sharing

641. A common model of secret sharing has two phases. In the
     initialisation phase, a trusted entity \-- the dealer, distributes
     shares of a secret to the participants via secure means. In the
     reconstruction phase the authorised participants submit their
     shares to a combiner, who reconstructs the secret on their behalf.
     It is assumed that the combiner is an algorithm which only performs
     the task of reconstructing the secret. We denote the sets of all
     possible secrets and shares by K and S respectively; the set of
     participants in a scheme is denoted by P. Secret sharing schemes
     can be modelled using the information theory concept of entropy.
     This captures the idea of how much information is in each of the
     shares and the secret. A perfect secret sharing scheme ensures that
     no information is leaked about the secret until a required set of
     authorized shareholders combine their shares in the combiners
     algorithm. A necessary condition for a perfect threshold scheme is
     that the entropy of each share is greater than or equal to the
     entropy of the secret. Most of the secret sharing schemes which we
     discuss satisfy this condition, but we will also consider briefly
     schemes, which do not satisfy it; they are called non perfect
     schemes.

642. The information rate of secret sharing scheme is a measure of the
     amount of information that the participants need to keep secret in
     a secret sharing scheme.

643. It is desirable to have secret sharing schemes in which the size of
     the secret information and the size of the information in each
     share is roughly the same.

644. This minimises the amount of information that needs to be kept
     secret by the participants, which means that there is a greater
     chance of the scheme remaining secure. For example, a
     (t,n)-threshold scheme implemented by polynomials is ideal, but
     when the scheme is modified to prevent cheating it is no longer
     ideal.

## Some known schemes

645. We now describe several well known threshold secret sharing
     schemes.

### A Simplified Version of Blakley\'s Scheme

646. A geometric solution is easy to visualise. Suppose that the secret
     is the combination of a safe, and that it consists of three digits,
     xyz. We could share the secret between a group of people by giving
     each of them the equation of a plane through the point (x,y,z).

647. If we choose the planes so their pairwise intersections give
     distinct lines through (x,y,z), then any two people can together
     determine a line through the point and any three can determine the
     point itself, and hence the combination of the lock. This is an
     example of a threshold scheme with threshold three, meaning that
     any three shares determine the secret, but no two shares determine
     it.

648. Suppose on the other hand, we choose the planes so that all but one
     of them have a line, l, say, in common, and the remaining plane, P,
     intersects l in the point (x,y,z). Then finding the point requires
     knowledge of the plane P and any two other planes. This means that
     the agreement of the person who knows P is essential for the
     determination of the secret, and it is not just a threshold scheme.

649. Situations where shares of unequal value are used arise often in
     practice. For example, consider the authorisation of electronic
     transfer of large amounts of money between financial institutions.
     One might expect, say, that two vice-presidents could jointly
     authorise the transfer of amounts over \$10,000,000, two junior
     vice-presidents amounts between \$1,000,000 and \$10,000,000, two
     senior tellers amounts between \$100,000 and \$1,000,000 and two
     tellers lesser amounts. This is in a situation where the
     appropriate password is never revealed outside the electronic
     facility (in the bank\'s head office) which reconstructs the
     password from the information shares fed into it. What if a
     vice-president and a junior vice-president are delayed in another
     city by airport fog?

650. An obvious solution is to share the authorisation code for transfer
     of larger amounts of money between larger numbers of more junior
     staff, but doing this efficiently presents a problem. At present,
     many access schemes are known and some of them, based on
     combinatorial designs and finite geometries, have been proved to be
     the best possible (in a theoretical sense).

### Shamir\'s Scheme

651. Shamir\'s scheme realises (t,n)-access structures based on
     polynomial interpolation over finite fields. In his scheme the
     secrets S belong to a prime power finite field GF(q), in which q is
     greater than or equal to n+1. In the initialisation phase, the
     dealer D chooses n distinct nonzero elements from GF(q) and
     allocates these to the participants. This correspondence is
     publicly known, and creates undesirable side effects if any of the
     participants are dishonest. However for now, we will assume that
     all the participants obey faithfully the protocol for
     reconstructing the secret. Fix a random element of GF(q) as the
     secret K. The shares of K are created using the following protocol.

652. The dealer chooses the coefficients of the polynomial, randomly,
     uniformly and independently and uses them to form a polynomial of
     degree at most t-1. The shares of the secret are the y values
     evaluated at t or more points.

653. With the above data, if any t out of the n participants combine
     their shares then using Lagrangian interpolation, there is a unique
     polynomial of degree at most t-1 passing through the points. So the
     combined shares of the t participants can be used to recreate the
     polynomial and hence the secret, which is the polynomial evaluated
     at zero. The relation between the secret and the shares is obtained
     from Lagrange\'s interpolation formula.

654. Shamir\'s scheme is computationally efficient in terms of the
     computational effort required to create the shares and to recover
     the secret. Also the share size is optimal in an information
     theoretic sense. The reconstruction phase in Shamir\'s scheme can
     also be considered as a system of linear equations, which are
     defined by the shares. If t shares are submitted to the combiner,
     the system of linear equations can be solved. However, if t-1
     participants try to reconstruct the secret, they face the problem
     of solving t-1 linear equations in t unknowns. This system of
     equations has one degree of freedom. Consequently, t-1 participants
     do not obtain any information about the secret, as K was selected
     uniformly and randomly from GF(q). Shamir\'s system is perfect.

### A (t,t) Threshold Scheme

655. Karnin, Greene and Hellman describe a secret sharing scheme which
     realises (t,t)-access structures. The interest in such schemes is
     that they can be used as the basis for other cryptographic
     constructions. In their scheme, the set of secrets S is the ring of
     residue classes Z_m, where m is any integer. (In applications m is
     large.) The secret K is shared using the following algorithm:

     The dealer, D, randomly, uniformly and independently chooses t-1
     elements y_1,y_2,\...,y_t-1 from Z_m; y_t is defined as K minus the
     sum of the t-1 shares modulo m.

     Participant P_i receives share y_i from D.

656. The Karnin-Greene-Hellman system is perfect, as the following
     argument shows. The set of shares of k\< t participants attempting
     to reconstruct the secret either contains the share y_t (formed
     from K minus the sum of all the other shares) or not. In both cases
     the (unauthorised) participants lack the necessary information to
     determine K. Shamir\'s scheme with t=n provides an alternative
     construction of (t,t)-threshold schemes, using the fields GF(q)
     instead of Z_m.

### Threshold Schemes and Discrete Logarithms

657. The discrete logarithm in groups has been widely employed in the
     literature to transform threshold schemes into conditionally secure
     schemes with extra properties.

658. It is a consequence of the linearity of equation used to solve for
     the secret that Shamir\'s scheme can be modified to obtain schemes
     having enhanced properties such as disenrollment capability, in
     which shares from one or more participants can be made incapable of
     forming an updated secret.

659. The modified (t,n)-threshold schemes are capable of disenrolling
     participants whose shares have been compromised either through loss
     or theft, and still maintain the original threshold level. In the
     event that some of the original shares are compromised, the KDC can
     issue using a public authenticated channel a new group generator
     which will allow all the shareholders to calculate their new shares
     from the initial secret data. A similar setting can be used to
     obtain dynamic threshold schemes. Threshold schemes with
     disenrollment capability, without the assumption of the
     intractability of the discrete logarithm problem, can be based on
     families of threshold schemes.

660. The discrete logarithm can be used to transform Shamir\'s scheme
     into a conditionally secure scheme which does not require a trusted
     KDC. The discrete logarithm problem is used to encode the secret
     and the shares so that they can be publicly announced for
     verification purposes.

661. Blakley, Blakley, Chan and Massey established a lower bound on the
     number of bits required to encode the shares in schemes with
     disenrollment showing that this number grows linearly with the
     number of disenrollments.

662. The discrete logarithm can also be used to transform Shamir\'s
     scheme, to meet a very different purpose. One of the properties of
     the discrete logarithm is that the sum of the discrete logarithms
     of the shares of a secret is equal to the discrete logarithm of the
     product of the shares of the secret. This property has an
     application in secret-ballot elections where, in contrast with
     schemes mentioned above, the discrete logarithm problem is required
     to be tractable.

### Combinatorial Structures and Secret Sharing 

663. Various connections between combinatorial structures and secret
     sharing are known. For example, threshold schemes can be based on
     combinatorial designs . Recently defining sets for t-designs and
     critical sets for Latin squares, have been used to design
     multilevel secret sharing schemes, in which a hierarchical
     structure can be imposed on the shares. In recent work critical
     sets in Room squares have also been used to realise multilevel
     secret sharing schemes. The schemes based on Latin and Room squares
     are examples of non perfect schemes.

## The problem of cheaters

664. So far we have assumed that the participants in a secret sharing
     scheme are honest and faithfully obey the reconstruction protocol.
     However, there are conceivable situations where a dishonest clique
     of participants (assuming an honest KDC) may attempt to defraud the
     honest participants by altering the shares they were issued.

665. In the McEliece and Sarwate formulation of Shamir\'s scheme,
     invalid shares can be identified. Schemes with this capability are
     said to have the cheater identification property.

666. Tompa and Woll showed that public knowledge of the ordinates in
     Shamir\'s scheme allows dishonest participants to modify their
     shares resulting in an invalid secret K\' being recreated. The
     cheater tricks the honest participant by submitting a perturbed
     share which results in a perturbed secret from which only the
     cheaters can recreate the correct secret, leaving the honest
     participants to believe that the perturbed secret is the correct
     secret.

667. This type of cheating can be prevented by disguising the publicly
     known ordinates with a randomly and uniformly chosen permutation
     known only to the dealer. This doubles the amount of information in
     each share but gives resistance against up to t-1 cheaters.

668. The problem of secret sharing without the usual assumptions about
     the honesty of the participants, or even the KDC has been
     considered in the literature. For example, in verifiable secret
     sharing it is not assumed that the dealer is honest. This problem
     is studied by Chor, Goldwasser, Micali and Awerbuch. The problem is
     how to convince the participants in a (t,n)-threshold scheme, that
     every subset of t shares of a share set defines the same secret.
     This property is called t-consistency. Shamir\'s scheme is
     t-consistent.

### Realising Schemes Efficiently

669. There are secret sharing schemes which attain the known upper
     bounds on the information rate. Stinson also gave a general method,
     called decomposition to obtain a lower bound on the information
     rate.

## Non perfect schemes

670. It is known that in non perfect schemes the size of the shares is
     less that the size of the secret. Because of this inequality, a non
     perfect scheme can be used to disperse a computer file to n sites,
     in such a way that The file can be recovered from its images which
     are held at any t of the sites (n \> t). Moreover, this can be done
     so that the size of the images is less than the size of the
     original file, resulting in an obvious saving of disk space. Making
     backups of computer files using this method provides insurance
     against the loss or destruction of valuable data.

671. A formal analysis of non perfect secret sharing schemes is given by
     Ogata, Kurosawa and Tsujii. Their analysis characterises, using
     information theory, secret sharing schemes in which the
     participants [not]{.underline} belonging to an access structure do
     gain some information about the secret. This condition is precluded
     in perfect secret sharing schemes.

672. The ramp schemes of Blakley and Meadows are examples of non perfect
     schemes where the access structure consists of semi-access subsets.
     Another way of viewing ramp schemes is that the collective
     uncertainty about a secret gradually decreases as more participants
     join the collective.

673. Ogata *et al* prove a lower bound on the size of the shares in non
     perfect schemes. They also characterise non perfect schemes for
     which the size of the shares is one half of the information
     contained in the secret. Ogata and Kurosawa established a general
     lower bound for the sizes of shares in non perfect schemes. They
     showed that there is an access hierarchy for which the size of the
     shares is strictly larger than this bound. It is in general a
     difficult problem to realise non perfect secret sharing schemes
     with the optimum share size, as in the case of perfect schemes.

#   {#section-6 .unnumbered}

# 5. BIOMETRIC TECHNOLOGIES

1.  Biometrics is the process whereby physiological or behavioural
    characteristics are used to identify or verify the identity of an
    individual. It is the verification process that is synonymous with
    authentication, both in physical and electronic environments and it
    is this process that will be discussed in this Chapter.

```{=html}
<!-- -->
```
674. Biometrics have been used in some cases (particularly fingerprints
     and passport photos) for over a hundred years. In more recent years
     electronic implementations have been used for physical access
     control, initially in areas with high security requirements
     although with reductions in costs it use has become more wide
     spread.

## DEFINITIONS

675. The following definitions have been taken from the *1999 Glossary
     of Biometric Terms* [^73]:compiled by the Association for
     Biometrics and the International Computer Security Association

  ---------------------------- ------------------------------------------
  Biometric System             An automated system capable of:\
                               1. Capturing an biometric sample from an
                               end user;\
                               2. Extracting biometric data from that
                               sample;\
                               3. Comparing the biometric data with that
                               contained\
                               in one or more reference templates;\
                               4. Deciding how well they match; and\
                               5. Indicating whether or not an
                               identification or\
                               verification of identity has been
                               achieved.

  Capture                      The method of taking a biometric sample
                               from the end user.

  Claimant                     A person submitting a biometric sample for
                               verification or identification whilst
                               claiming a legitimate or false identity.

  Enrolee                      A person who has a biometric reference
                               template on file.

  Enrolment                    The process of collecting biometric
                               samples from a person and the subsequent
                               preparation and storage of biometric
                               reference templates representing that
                               person\'s identity

  Identification/Identify      The one-to-many process of comparing a
                               submitted biometric sample against all of
                               the biometric reference templates on file
                               to determine whether it matches any of the
                               templates and, if so, the identity of the
                               enrolee whose template was matched. The
                               biometric system using the one-to-many
                               approach is seeking to find an identity
                               amongst a database rather than verify a
                               claimed identity. Contrast with
                               'Verification'.

  Match/Matching               The process of comparing a biometric
                               sample against a previously stored
                               reference template and scoring the level
                               of similarity. An accept or reject
                               decision is then based upon whether this
                               score exceeds the given threshold.

  Template/Reference Template  Data, which represents the biometric
                               measurement of an enrolee, used by a
                               biometric system for comparison against
                               subsequently submitted biometric samples.

  Verification/Verify          The process of comparing a submitted
                               biometric sample against the biometric
                               reference template of a single enrolee
                               whose identity is being claimed, to
                               determine whether it matches the
                               enrolee\'s template. Contrast with
                               \'Identification\'.
  ---------------------------- ------------------------------------------

## TECHNOLOGY

676. A number of the biometric techniques currently in use or under
     development. Some of these are listed below.

     Physiological

-   fingerprint

-   finger geometry

-   hand geometry

-   iris recognition

-   retina pattern

-   face recognition (geometry and thermal imaging)

-   palm pattern

-   voice verification

-   vein pattern

-   Body Odour

-   DNA

    Behavioural

-   signature verification

-   keystroke dynamics

677. It is not intended that this Chapter address particular biometric
     technologies[^74]. Rather it will identify the aspects of the
     technology that are common to all technologies and relevant to the
     general discussion of electronic authentication.

678. Biometric techniques involve the capture of a sample of the
     individual's biometric characteristic to produce a template that is
     then linked to the individual through an enrolment process and
     stored. For subsequent authentication a new sample is captured and
     compared with the stored template.

![](media/image8.wmf){width="5.194444444444445in"
height="2.3333333333333335in"}

Figure 23: Biometrics

679. As mentioned in the General Issues Chapter (Chapter 1), many
     implementations use cryptographic techniques to prevent capture of
     samples for subsequent replaying. Other implementations use
     templates stored on tokens under the control of the individual and
     the token generates an authentication message using another
     technology such as asymmetric cryptography or shared secret. The
     issues associated with these approaches are discussed further in
     the Hybrid Technologies Chapter (Chapter 7).

## USE IN ELECTRONIC BUSINESS MODELS

680. As a biometric is a characteristic of an individual there is a
     strong binding between that individual and the authenticator. The
     strength of the binding may vary in terms of the particular
     characteristic and the technology being used. As with any
     authentication technology, both the authentication service provider
     and user will need to be aware of the degree of reliance that can
     be placed on the authenticator.

681. While biometric authenticators provide a strong binding with an
     individual, they do not provide the same facility for
     authentication of corporate or machine identity nor for role or
     attribute authentication. However this has also been the case in
     the paper world where, for example, written delegations have been
     used to link an identity to a particular role, attribute or
     corporate identity. Machine identity authentication is a
     requirement unique to the electronic environment and does not have
     a paper based equivalent.

### Open Model

682. Biometric technologies do not lend themselves readily to the open
     business model as they rely on comparison between a sample captured
     at the time of the transaction and a template captured as part of
     an earlier enrolment process. This implies that there was an
     earlier relationship between the parties. Absent some form of
     independent authentication service provider, current biometric
     approaches cannot operate without this prior relationship.

683. Furthermore, in an open system the transmission of a sample or
     template would be unprotected unless encryption were used. If
     symmetric encryption were used it again requires a prior
     relationship to exchange the symmetric key. If asymmetric
     cryptography were used, some form of authentication would be
     required to validate the public key and the approach would then be
     one of hybrid electronic authentication. Another measure is the use
     of one-way encryption which prevents the biometric from being
     recovered from the template. Furthermore as the encryption is
     applied in the validation process this would prevent an encrypted
     template being directly compared.

684. It is feasible for an authentication service provider to provide a
     certified biometric template or validate a biometric authenticator
     forwarded by the recipient of a transaction. However, again the
     process is likely to use some form of encryption to protect the
     biometric information being exchanged and the arguments in the
     previous paragraph would equally apply.

### Closed Model

685. In this model there is some form of prior relationship between the
     parties and this relationship could involve the enrolment of the
     parties biometric data. It could also involve establishment of
     schemes to protect the exchange of biometric information. Within an
     organisation this could be simply reliance on security of the
     internal network. In external networks it could involve the use of
     encryption to protect the biometric information. Within a closed
     system, exchange of symmetric keys would be practical. The use of a
     biometric authenticator as an access control tool is a classic
     example of a closed model.

686. Biometric technologies lend themselves to closed business models.

### Open-But-Bounded Model

687. In the open-but-bounded model the type of general agreement
     envisaged in the General Issues Chapter (Chapter 1) need not exist
     until immediately prior to the transaction occurring. In such cases
     it is unlikely that a biometric authenticator would have been
     enrolled by a recipient prior to a transaction. In this model it
     may be possible for a recipient to obtain a certified copy of a
     template from an authentication service provider. As discussed
     under open models, such processes are likely to involve other
     authentication processes and would fall into the hybrid category.

688. Biometrics alone do not readily lend themselves to open-but-bounded
     business models.

## USER REQUIREMENTS

689. Biometrics lend themselves more towards business rather than
     individual user requirements. The two main factors are the need for
     hardware capture devices and storage capacity for templates. In
     addition the need to enrol parties is more of a problem for
     individual and small business users.

690. The cost of capture devices will vary with the technology adopted.
     More common devices such as fingerprint capture devices can be
     expected to become more affordable as they are more widely
     deployed. Other technologies may be able to be implemented through
     software using other devices already being used. For example it may
     be possible to develop facial recognition software that relies on
     cameras used for video conferencing as the capture device. Voice
     verification could be performed using existing microphone equipment
     attached to PCs.

691. Storage capacity for templates will vary depending on the number of
     biometric authenticators a user is likely to receive. In addition
     as the template and comparison software is critical to the
     authentication process these elements must be secured to a level
     appropriate to the degree of reliance that is to be placed on the
     authenticator. Uptake of this technology will depend on the costs
     of storage and security.

692. Finally there is the enrolment process. Typically this would
     require the enrolee to physically provide a sample. In open and
     open-but-bounded models it is unlikely that this would occur. Even
     in the closed model this may not always be practical. It is,
     however, possible for an authentication service provider to enrol
     authenticators and certify templates. Distribution of certified
     templates or validation of biometric authenticators against a
     certified template does involve some security problems as discussed
     earlier. However, a recipient could have a secure link to an
     authentication service provider under some agreed scheme or hybrid
     technologies using asymmetric cryptography could be used.

693. Whether biometric authentication alone, or as part of a hybrid
     approach, will meet a user's requirements will depend very much on
     the business model and the degree of trust required.

## CERTIFICATION MODELS

694. For the purposes of this discussion certification is, based on the
     definition of certificate in the General Issues Chapter (Chapter
     1*): the process of generating an electronic document, generally
     issued by a third party, that binds an authenticator to a specified
     user*. Enrolment is, as defined earlier, the process of collecting
     biometric samples from a person and the subsequent preparation and
     storage of biometric reference templates representing that
     person\'s identity. As such, certification of a biometric
     authenticator involves issuing an electronic document that binds a
     specified user to a template obtained through an enrolment process.

### Formal Certification

695. In this case an authentication service provider would enrol a user
     and issue a certificate binding the user to the template. The
     template could be incorporated in the certificate and sent with the
     message or stored in a publicly accessible directory.

### Informal Certification

696. In this case a third party or a number of third parties other than
     an authentication service provider would enrol and certify the
     user. The recipient would accept the certificate from a certifier
     that they trust.

### No Certification

697. In this case the relying party directly enrols the user and
     dispenses with the requirement for a certificate. This scenario
     would typically occur in closed models. Biometrics lend themselves
     to this approach.

698. While it would be technically feasible for a person to accept a
     biometric without a template and store it in case of a dispute, it
     is difficult to imagine a scenario in which this would be a
     preferred approach.

## TRUST

699. While the level of trust in a biometric itself is high, it should
     be born in mind that biometric authenticators are based on samples.
     For example a finger print may be assessed on whether there is or
     isn't a ridge at a particular point. Therefore if 20 points are
     sampled the probability of two persons providing the same sample is
     one in 2^20^. The more the points of sample, the lower the
     probability of two persons returning the same sample. . Other
     issues such as assurance of the process used to establish identity;
     assurance of the binding process between identity and the template;
     and the operational integrity of the biometric system will all
     impact on the quality of assurance. The way in which the biometric
     is implemented can therefore determine the level of trust that can
     be placed in the technology.

700. A further factor determined by the implementation and technology is
     the probability of false acceptance (Type II error)[^75] and false
     rejection (Type I error)[^76]. Some technologies can be adapted to
     lower a particular error rate at the expense of increasing the
     other error rate.

701. For these reason biometrics can be implemented with a technology
     and configuration that produces a level of trust that meets an
     organisations business risk model. The disadvantage of these
     technologies is that, as with other authentication technologies
     discussed in the other chapters, for the most part the means of
     establishing the level of trust that can be placed on a particular
     implementation is very dependent on technical issues beyond the
     understanding of the average user. The development of standards and
     accreditation processes for biometrics will assist users in
     determining the product that best suits their needs.

702. The other major trust issue is the security of the sample in
     transmission and the template in storage. Techniques such as
     encryption can be used to protect a sample while it is in transit.
     The use of encryption in these circumstances is to protect the
     sample and as such is not performing an authentication function.
     This is not, therefore, a hybrid approach. Similarly one way
     encryption can be used to prevent a template being used to
     reconstruct a biometric and this, again, is not a hybrid approach.
     There are a number of other security measures that can be taken to
     protect biometric samples and templates.

703. The security of samples and templates is of greater significance in
     biometric authentication due to the unique nature of the various
     characteristics and the inability to change or replace them. If a
     sample or template of a characteristic is captured in a form that
     allows it to be replayed, the compromised characteristic may not be
     able to be used again. There are however some avenues for reuse. If
     several technologies use the same characteristic, such as a
     fingerprint, but sample the characteristic in different ways, it
     may be possible to change technologies. Alternatively an individual
     may start to use a different characteristic. However, alternative
     approaches are limited and would be more costly to effect than the
     revocation and reissue of encryption keys or a PIN or password.

## LIABILITY

704. As a biometric is a physical characteristic of an individual,
     liability issues arising from failure to protect a secret component
     of an authentication technology do not arise. However, the
     vulnerability of biometrics lie in the samples and templates. It is
     possible that an individual's equipment does not adequately protect
     a sample, that a sample is not adequately protected in transit and
     can be captured and replayed, or that the holder of a template has
     not adequately protected that template. Adequate security measures
     are needed to reduce these risks.

705. As with other technologies, if the certification and, in the case
     of biometrics, the enrolment process has not been correctly
     performed, liability issues may arise. Also as with other
     technologies there are liability issues relating to revocation and
     failure to provide service.

706. From the user perspective, however, the reduced probability of
     liability arising from loss of an adequately secured authenticator
     makes this technology more attractive from a liability perspective.

## ROLES OF PARTICIPANTS

707. The communities of interest for this technology are the same as
     those outlined in the General Issues Chapter (Chapter 1). However,
     as mentioned earlier the main strength lies within closed systems.
     For this reason the roles of government, high level authentication
     authorities and authentication service providers are not as
     significant. However, there is a role for enrolment and storage of
     templates that would equate to some elements of an authentication
     service provider; particularly in respect of identification,
     revocation and security of templates and liability arising from
     failure of the authentication service provider to adequately
     provide these services.

## INTEROPERABILITY

708. There is a wide variety of biometric approaches under development
     and it is not possible to achieve interoperability between them as
     each can relate to a different characteristic. Even technologies
     using the same biometric characteristic can have a variety of
     implementations. Typically the reader and template comparison
     require the same approach in terms of the characteristic being
     used, the sampling rate and other special features. The Biometrics
     Consortium[^77] is developing standards for the use and
     interoperability of biometrics.

709. However, in the short term, biometrics, as a stand alone
     authenticator, are unlikely to be widely adopted outside discrete
     closed business models. It is the linking of biometrics with other
     technologies to produce a hybrid technology that is likely to
     produce widespread interoperable authentication schemes. This issue
     is further discussed in the Hybrid Technologies Chapter (Chapter
     7).

## ACCREDITATION

710. Accreditation processes generally rely on the existence of
     standards or other normative documents. While individual devices
     can be tested and their performance against their own targets
     verified, this is not a formal accreditation process.

711. The UK Government's Biometrics Working Group[^78] has developed
     best practice standards for testing and reporting on biometric
     device performance, a Common Criteria Protection Profile for
     biometrics and advice on the selection of biometric products. This
     work is being undertaken in consultation with product developers
     and other governments and should lead to the availability of
     accredited biometric products.

## CULTURAL DIFFERENCES

712. Because biometrics rely on human characteristics it is the
     technology most likely to be impacted by cultural differences. For
     example a face recognition approach is not practical in countries
     where items of clothing traditionally obscure the face.

713. In other countries there are civil liberties objections, still a
     cultural problem, to widespread recording of biometric
     characteristics such as fingerprints and DNA. This fear is
     generally based on a fear of possible misuse of the biometric.
     Developments such as one way encryption of samples to generate
     templates or storage of templates on tokens under the control of
     the individual can reduce these problems. The latter case, however,
     would then need the token to generate another form of
     authentication and would therefore be a hybrid approach.

714. A further issue arises where a person is signing on behalf of
     another person. In some cultures this involves the transfer of the
     signing instrument, or authenticator from one individual to the
     other. The concept of power of attorney does not exist. Biometrics
     are unique to individuals and cannot be transferred. As such they
     could not be used in such circumstances.

715. However, the main cultural problem associated with biometrics is
     that it is based on a characteristic unique to an individual. In a
     number of cultures the concept of an individual is subsumed by that
     of the tribe, clan or extended family. Property is owned by, and
     transactions are undertaken on behalf of, the community not the
     individual. Often numerous members of the community can transact on
     behalf of the community so authority is not attached to a single
     individual. Other authentication technologies allow the secret
     component of that technology to be shared. For example PINS and
     passwords for credit and debit cards are commonly shared in such
     communities. Even private keys could feasibly be shared. Biometric
     authenticators would not be effective in these communities without
     cultural change.

716. When developing biometric authentication schemes, consideration
     needs to be given to potential cultural differences in communities
     with which those schemes are likely to interact.

## AWARENESS

717. There are a number of misconceptions about biometrics and their
     use. People have a natural fear of injury to there bodies and are
     reluctant to use capture devices about which they are uncertain.
     There are also concerns that biometrics, particularly fingerprints
     and DNA, can be misused by governments and law enforcement
     agencies. As mentioned earlier, a number of implementations do not
     allow reconstitution of the biometric. However the fear remains.

718. While a broad section of society accepts that at least some
     biometrics are unique, this acceptance is less than universal. In
     addition many are not confident that the capture techniques will
     retain the 'uniqueness'. Extensive awareness campaigns will need to
     be undertaken to overcome these misconceptions and develop user
     confidence before there is widespread acceptance of the technology.

### Government Awareness

719. Awareness and understanding of biometric authentication within
     government is still limited. While there is a growing awareness of
     the role of biometrics, this does not approach the level of
     awareness of asymmetric, or public key, cryptography. Consequently
     its potential role as an electronic authentication technology is
     not generally understood. Until this level of awareness is
     increased, governments will have difficulty in raising awareness in
     the community. Biometric technologies continue to be underrated as
     a tool for electronic commerce. There is a need for governments to
     better inform themselves of this technology and the contributions
     it can make to electronic authentication and electronic commerce.

### Business Awareness

720. Unlike governments, who at least have a need to be aware of
     emerging technologies, business tends to be driven by what is
     marketed to them. As with governments the electronic authentication
     technology to which they are most exposed is public key. As
     businesses tend to be driven by risk management approaches, they
     are less likely to risk what is to them is an unknown technology.
     Furthermore, unlike governments, many businesses are unlikely to
     have an internal capability to assess the technology and the risk
     implications. Raising business awareness of biometric
     authentication and the trust that can be placed in it will be
     crucial if this technology is to be widely deployed.

### Individual User Awareness

721. The greatest apprehension and misconceptions will be with
     individual users. Even if governments and business were to adopt
     biometric technologies, its uptake by individual users, in many
     cases their largest group of clients, will be slow and patchy
     unless positive steps are taken to increase their awareness of the
     benefits for them of such uptake. There is also a need to consider
     the ease of the enrolment and registration process that would
     minimise the real or perceived intrusiveness in capturing the
     biometric during this process.

722. A further factor for individual users is the uptake of these
     technologies by the suppliers of the equipment to them. If that
     equipment comes with inbuilt features that facilitate biometric
     authentication they are more likely to accept the technology. This
     is particularly the case if reviews of the equipment highlights the
     inbuilt features and outlines the benefits of its use.

723. In general the greatest understanding of the technology is in
     academia and with the product manufacturers. Any awareness raising
     campaign without their involvement and commitment will be futile.
     In addition widely reported pilot projects can significantly raise
     the level of awareness.

## LEADERSHIP

724. While raising awareness is important for the uptake of biometric
     authentication, leadership is even more important. Leadership by
     example through the use of the technology is one of the main
     elements. However, establishing the necessary policy frameworks and
     business models is also important.

### Governments

725. A number of governments have established their legal and policy
     frameworks to support public key approaches to electronic
     authentication. More recently the trend has been towards the
     establishment of technology neutral frameworks that will support a
     range of electronic authentication technologies. Without government
     leadership through the establishment of frameworks that support
     biometric as well as other authentication techniques, biometric
     technology will not be used to its full potential.

726. The other area where governments can provide leadership is through
     the use of biometric authentication in its own activities and the
     publication of that fact. Already governments use biometric
     authenticators extensively as access control tools. The extension
     of the technology to electronic commerce applications both within
     organisations and with client groups will provide significant
     leadership to the community in general.

### International Organisations

727. Much of the focus of discussions on electronic authentication to
     date in international organisation has been on the use of
     asymmetric cryptography in public key infrastructures. These
     discussions will need to be extended if the full range of
     electronic authentication technologies are to be allowed to
     develop. Already some international organisations are adopting
     technology neutral approaches in their considerations. This will
     provide the necessary leadership for biometrics to be recognised as
     a viable electronic authentication technology.

### Business Corporations

728. As with Government, a number of businesses use biometric
     technologies for internal access control. The use of biometrics
     alone or in combination with other technologies, both internally,
     and with their clients, will provide leadership in the use of the
     technology. Furthermore, the identification of the business models
     to which the technology is suited is best carried out by the
     business community.

### Users and User Groups

729. The role of users and user groups is more by way of acceptance of
     the technology and raising awareness of the issues surrounding its
     use. One of the principle misconceptions about this technology is
     that it can be misused by authorities. There is a role ,
     particularly for user groups, in obtaining a better understanding
     of the technology in order to counter the misconceptions. However,
     there is equally a role for governments and biometric manufacturers
     in ensuring that user groups obtain sufficient accurate information
     on which to make their judgements.

### IT Industry

730. The IT industry can provide leadership through incorporating
     biometric technologies alone or in conjunction with other
     electronic authentication technologies in their products. This is
     already occurring with the development of biometric techniques such
     as fingerprint readers that can interface with computers or smart
     cards. The biometric sector of the IT industry can facilitate the
     use of the technology by ensuring users are aware of the benefits
     and risks associated with the technology. The development of
     biometric industry associations is facilitating this process.

## COMBINATION WITH OTHER TECHNOLOGIES (HYBRIDS)

731. While this chapter covers the use of biometric authentication
     technologies, it would not be complete without some reference to
     the use of biometrics in combination with other electronic
     authentication technologies. This aspect is covered in more detail
     in the Hybrid Technologies Chapter (Chapter 7). Biometrics add an
     extra layer of security to the use of authentication technologies
     by linking the use of a stored authenticator to a physiological or
     behavioural characteristic of the owner of that authenticator. At
     present the main application is to link the biometric to the stored
     private key component of an asymmetric cryptographic, or public
     key, authenticator. Conceivably it could also apply to a secret key
     in authentication systems using symmetric cryptography.
     Additionally it can add weight to some of the other approaches to
     electronic authentication such as IP address or email address where
     access to that address is controlled by a biometric. For example
     where a user cannot log on to a particular machine or as a
     particular user without a biometric authentication process this
     adds weight to the reliance that can be placed on that 'other'
     authenticator.

732. While it is likely that the main role of biometric authentication
     technologies is likely to be in hybrid applications, the issues
     involved cannot be addressed without an understanding of the issues
     involved with each of the technologies in the hybrid. This chapter
     is designed to outline the main issues associated with the use of
     biometric authentication technologies.

# 6. OTHER TECHNOLOGIES

1.  At the present point of development of electronic messaging,
    particularly email, the most common forms of authentication do not
    fall into the categories discussed in the previous chapters on
    asymmetric cryptography, shared secrets and biometrics. These other
    forms are also most closely related to the paper environment as they
    involve authentication by either a name or a location, in this case
    an electronic location. These are characteristics of the message or
    machine rather than a specific authentication technology. In some
    cases authentication can occur at the time of the transaction, such
    as in reading an email address, while in other cases it may occur
    after the event, such as in using audit trail information.

```{=html}
<!-- -->
```
733. Most users will have responded to instructions from a superior,
     sometimes with financial implications, based on the name on the
     bottom of an email or the displayed email address of the sender.
     The reliance on simply a name at the bottom of an email can extend
     to parties who have never met. The then Public Key Authentication
     Task Group conducted a workshop at TEL 18 in Port Moresby. A number
     of speakers attended that workshop on the basis of an email from
     the Task Group Chair with no technology used to authenticate the
     message. Their organisations were prepared to commit a not
     inconsiderable sum of money for them to attend the workshop without
     a formally authenticated invitation to attend.

734. This group of characteristics can only provide a limited form of
     authentication and do not provide confidentiality or integrity
     services.

## CHARACTERISTICS

735. The main message or machine characteristics that can be used to
     authenticate a message are:

-   email address;

-   IP address;

-   domain name;

-   signature block;

-   message properties such as those in the message header;

-   terminal identifier;

-   trace route information; and

-   audit logs containing any of the above information.

### eMail Address

736. This information is supplied with an email and shows a user name
     and an associated domain name in the format user name@domain name.
     The two in combination must be unique to allow the email system to
     operate. While in most cases an email address is linked to an
     individual, it is quite common for an email address to be linked
     simply to an organisation. There is also a more secure email
     platform X.400 which includes more detail in the address. An
     address is usually in the format C=Country name; A=Administration
     Management Domain; P=Private Management Domain; O=Organization
     name; OU=Organizational Unit name; S=Surname; G=Given name.

### IP Address

737. The Internet Protocol (IP) address is used primarily as the means
     by which packets are directed to their destination. It consist of
     four numbers of up to three digits separated by dots
     (nnn.nnn.nnn.nnn). Machines with permanent connections have a
     static IP address while those connected through connections to an
     Internet Service Provider (ISP) may be assigned an IP address from
     a bank of addresses for that ISP server. The server assigned IP
     address may vary each time a connection is made. Similarly a local
     area network may be connected through a server with a single IP
     address.

738. While IP addresses were originally designed to direct messages to a
     recipient they also are used to identify the source of a message to
     allow error messages to be returned. It is this source information
     that can be used to authenticate the machine or server which sent a
     message. Where more than one person may be connected to a server
     there is no way of using the IP address to identify the individual
     who sent a message. IP address does have a role in machine to
     machine authentication.

### Domain Name

739. The Domain Name System (DNS) is a hierarchical system that
     translates IP addresses is to easily recognised names. The domain
     names are structured in a hierarchy of country code, such as sg
     (Singapore), au (Australia); domain, such as com (commercial), org
     (organisation) gov (government) edu (education); and distinguished
     name expressed in reverse order. It is possible for the country
     code to be absent as is usually the case for US domain names. For
     example the APEC Secretariat domain is apesec.org.sg. The domain
     name is converted to an IP address through a network of domain name
     servers. As the domain name is essentially the same as an IP
     address the comments in the previous paragraphs also apply here.

### Message Properties

740. Information such as email address, IP address and domain name,
     including routing information, is stored in message headers
     accessible from email packages. This information may be used as the
     means of implementing one of the above approaches to
     authentication.

### Signature Block

741. In many cases email messages have replaced signed letters or
     internal memoranda. Most people sending e-mails use some form of
     signature typed at the end of the message. This is probably the
     most commonly used means of authentication of electronic messages.
     Generally the signature block identifies an individual although in
     some cases it may identify a particular group or organisation. It
     cannot be used to authenticate machines.

### Terminal Identifier

742. Most terminals attached to internal networks have terminal
     identifiers which may or may not involve an IP address. Where an IP
     address is not involved, the terminal identifier can often perform
     the same function as an IP address but limited to the internal
     network. It can perform machine authentication.

### Trace Route Information

743. Some toolkits allow you to trace the route of a message while the
     message is being sent or received. This is of limited use in
     authenticating messages due to its 'real time' nature. It may have
     some role in authenticating a recipient machine before a message is
     sent.

### Audit Logs

744. Audit logs can be set up to record information such as email
     address, IP address, domain name and terminal identifier.
     Information recorded in the logs may be used to authenticate
     individuals or machines as appropriate.

## USE IN ELECTRONIC BUSINESS MODELS

745. There is no formal binding between an individual or organisation
     and the above characteristics. Even in the case of email, while
     there is a distinguished name and a process for the domain issuing
     that name, generally the only check is that the name has not
     already been issued. Even domain names are issued without a
     reliable formal binding at this stage as is evidenced by the
     current problem of 'cybersquatting'. In the case of IP address
     there is some minimal binding between the IP address and the
     machine as this is required to allow connections to be made.

746. The characteristics, other than terminal identifier, can be
     associated with messages in open, closed and open but bounded
     models. Terminal identifier can only be used in closed models as
     they relate to terminals on a particular network. The level of
     trust can vary depending on the model and this is discussed further
     in the Trust section below.

## USER REQUIREMENTS

747. Most users are familiar with the basic concept of an email address
     and domain name and where to find them as they are fundamental
     aspects of Internet usage. The use of signature blocks is the same
     as exists in the paper world and would also be familiar to all
     users. The remaining characteristics require a slightly more
     detailed technical knowledge.

748. Most of the characteristics are integral parts of the appropriate
     applications. For example email packages display the senders email
     address either directly or behind a display name. Most browsers
     display the domain name of the site connected with. Other
     characteristics such as message headers and IP address can be
     displayed using standard applications. The additional costs of
     using these characteristics is generally limited to the time taken
     to show a user how to find the characteristic.

749. The main problem is whether the characteristics are trustworthy
     enough to meet the users requirements. This is discussed in the
     Trust section below.

## CERTIFICATION MODELS

750. Certification was defined in the General Issues Chapter (Chapter1*)
     as: the process of generating an electronic document, generally
     issued by a third party, that binds an authenticator to a specific
     user*. As mentioned above, there is no formal process of binding
     these characteristics to a specific user. However, it may be
     possible for a person to informally advise that a person has a
     particular name or an organisation has a particular domain name.
     This may form an informal certification process. However in most
     cases no certification is used.

## TRUST

751. Many of these characteristics were originally developed as a means
     of identifying individuals or machines and were not developed as a
     means of authenticating that identity. They were simply developed
     to ensure delivery of data to and from particular individuals and
     machines. The emphasis was more on ensuring the uniqueness of the
     identity rather than binding the identity to a particular
     individual. The exception is X.400 which was designed as a secure
     messaging scheme including message origin authentication. However,
     X.400 uses asymmetric cryptography as part of its message origin
     authentication and this approach is included in the Annex on
     Hybrids (Annex E).

752. Instances of IP spoofing, identity theft and cyber squatting
     underline the weaknesses of the characteristics. Tutorials on IP
     spoofing are readily available on the Internet. Most people will
     have experienced SPAM mail from a spoofed email address.

753. The main value of these characteristics as authenticators lies not
     so much in the characteristic as in supporting information. This
     can include an expectation of receiving a message or the content of
     the message itself. This collateral information combined with the
     message characteristics can form an aggregation of trust sufficient
     for a party to rely on the message.

754. The level of trust can be influenced by the nature of the business
     model. The characteristics when used in a closed system can result
     in a high level of trust, the level of trust being inversely
     proportional to the number of participants in the closed model. It
     is quite common to hear of people using another persons terminal to
     send a message even in a closed system. Once you move into an open
     or open but bounded model the potential for misuse such as IP
     spoofing or email address spoofing increases significantly.

755. Ultimately, as with all authentication technologies, it comes down
     to the user to decide whether an authenticator, in this case the
     characteristics, is suitable for the purpose for which it was
     provided. This is a risk management approach. However, it should be
     noted that these characteristics are more widely used than
     generally acknowledged and should not be ignored at this stage.

## LIABILITY

756. While some characteristics such as email address and domain name
     are allocated by third parties this is done to facilitate message
     delivery. Similarly some of the characteristics are generated by
     machines or Internet elements again to facilitate message delivery.
     As none of the characteristics are actually developed for
     authentication, users would carry all liability for their use as
     authenticators unless they could establish that someone had
     deliberately interfered with the process for the purpose of
     misleading them. This may result in criminal rather than civil
     proceedings as such interference can, in some circumstances,
     involve unauthorised access to a machine or data.

## ROLES OF PARTICIPANTS

757. The main participant in the use of these characteristics is the
     recipient. In some cases the characteristics are attached in a
     manner transparent to the user. Application developers and
     standards making bodies have a role in supplying the means by which
     the characteristics are generated and displayed.

## INTEROPERABILITY

758. Most of the characteristics are generated as part of protocols
     designed to ensure interoperability. There may, however, be some
     differences in how they are accessed or displayed between different
     applications. In general interoperability is not a problem with
     these characteristics.

## ACCREDITATION

759. As these characteristics were not developed for authentication
     purposes it is not possible to accredit them for that purpose.
     However, it may be possible to gauge the degree of reliance that
     can be placed on them. This is more a risk management approach than
     an accreditation process.

## CULTURAL DIFFERENCES

760. Cultural differences relate primarily to persons. The
     characteristics covered in this annex relate to messages and
     machines. It is unlikely that there will be any impact of cultural
     differences in those cultures based on the concept of community
     rather than individual. For example an email signature block could
     be used to identify extended families or clan, village or tribal
     groupings. Similarly a machine can be linked back to the community
     in which it is located as easily, if not more easily, as it can be
     linked to an individual.

761. These other characteristics cannot, in general, be transferred from
     individual to individual in the same way as a signing device such
     as a chop or seal. However, it is possible for a person to use
     another person's machine and thereby send a message on their
     behalf, achieving the same result.

## AWARENESS

762. As mentioned earlier, most people already use these characteristics
     as an authenticator often without realising it. However, the
     strength of the authentication is more often related to collateral
     information rather than the characteristic itself. Any awareness
     needs to focus on that aspect rather than on the characteristics
     themselves. The main issue however, is the circumstances in which
     the use of these characteristics is appropriate.

### Government Awareness

763. Governments have a traditionally adopted relatively high levels of
     security for their information. However, as they have moved towards
     information technology for their internal communications, the
     characteristics covered in this chapter are often used for low
     level authentication of messages. As governments generally use risk
     management models for their security they should be aware of the
     circumstances where use of these technologies is appropriate.

### Business Awareness

764. Business, particularly smaller business, is less aware of the risks
     surrounding these characteristics. The result can range from
     complete avoidance to inappropriate use of the characteristics.
     There is a need for raising industry awareness of the role of these
     characteristics and the circumstances in which their use might be
     appropriate.

### Individual User Awareness

765. Most individuals currently use the Internet for ordering and paying
     for goods and services and for personal messages. For the most part
     authentication of the merchant or other individual is restricted to
     DNS or email services although there is some reliance on webserver
     certificates. While there is a lot of hype about security on the
     Internet, the fact is that so far this approach is operating
     effectively for those who have sufficient confidence in the system.
     The problem is more one of generating the necessary confidence.
     While this will eventually lead to more secure authentication and
     payment systems, there is a need to ensure that negative publicity
     does not prevent people using the characteristics until stronger
     techniques are widely deployed.

## LEADERSHIP

766. These characteristics are already well used as a low level
     authentication approach. There is little that governments,
     international organisations, business corporations, users and user
     groups, and the IT industry can do by way of leadership other than
     promoting awareness of the role of the characteristics and the
     appropriate circumstances for their use. There is a role for
     governments in ensuring that these characteristics are not denied
     legal effect in line with the technology neutrality provisions of
     the UNCITRAL Model Law.

## COMBINATION WITH OTHER TECHNOLOGIES (HYBRIDS)

767. These characteristics do not lend themselves to combination with
     other authentication technologies

# 7. HYBRID TECHNOLOGIES

1.  A number of technologies can be combined in the authentication
    process. These combinations can take two basic forms:

-   a number of authentication technologies that are used sequentially
    in a single transaction - called ***chained technologies*** in this
    chapter; and

-   a different technology is used to secure an authenticator in a
    single transaction -- called ***secured technologies*** in this
    chapter.

768. In some cases the use of an authentication technology may involve
     the use of an authentication service provider. Also in some cases
     secured and chained technologies can be combined.

## TECHNOLOGY

### Chained Technologies

769. In this approach an authentication technology is used to trigger
     another authentication technology. The most common example at
     present is the use of a password (shared secret) to release the
     private key for a digital signature (asymmetric cryptography). In
     this case the shared secret is between the user and his or her PC
     or token on which the private key is stored.

770. One of the most common implementations of two element chained
     technology is better known as two factor authentication. This uses
     two of three factors:

-   Something you have;

-   Something you know; or

-   Something you are.

771. Tokens such as smart cards or USB devices (something you have)
     activated by either a PIN (something you know) or a biometric
     (something you are) are examples of two factor authentication using
     chained technology.

772. The technique is more commonly used in authentication for access
     control purposes rather than electronic transactions. However the
     requirement for secure signature creation devices in the European
     Union Directive on Electronic Signatures[^79] and in other
     legislation is likely to result in more common use of this approach
     in authenticating electronic transactions.

![](media/image21.wmf)

Figure 24: Two Element Chained Technology

773. In some cases it is possible that three different technologies can
     be used in a single transaction. An example would be a biometric
     used to trigger the private key for a digital signature (asymmetric
     cryptography) which on receipt generates a Kerberos ticket
     (symmetric cryptography) to access a particular file.

![](media/image22.wmf)

Figure 25: Three Element Chained Technology

774. Extending the above example, it is possible for more than one
     application service provider to be involved in the course of a
     single transaction. An independent certification authority may be
     involved in the provision of the certificate and possibly keys used
     in the public key technology while a separate authentication
     service provider may operate the Kerberos ticket server. In this
     example the authenticator relied on by the receiver is not the same
     as that sent from the sender. Furthermore there may not be a direct
     relationship between the receiver and the sender's certification
     authority. Any presumption in respect of a digital signature would
     benefit the operator of the Kerberos ticket server and not the
     receiver.

![](media/image23.wmf)

Figure 26: Two ASP Chained Technology

775. There has been some discussion that the use of a shared secret or
     biometric in conjunction with a private key is a security process
     rather than an authentication process. This will depend on the
     approach used. If the shared secret or biometric simply provides
     access to the private key which is then independently used as an
     authenticator, then the shared secret or biometric is simply part
     of a security process. However, if the process is automated and the
     action of providing the shared secret or biometric triggers the
     signing process then it can be argued that this is a chained
     authentication process. Ultimately this will be a matter for courts
     to decide. Overly prescriptive legislation that does not recognise
     the possibility of chained authenticators can only complicate the
     legal process.

### Secured Technologies

776. In this approach another technology is used to protect an
     authenticator in storage or transit. A common implementation is the
     use of symmetric cryptography to protect a shared secret. Another
     common implementation is the use of symmetric cryptography (shared
     secret) to protect a biometric between the reader and the template
     storage.

Sender Receiver

Figure 27: Secured Technology

777. In some cases secured technologies are used to protect an
     authenticator without playing a part in authentication of
     individual transactions. In other cases the protective technology
     is an authentication technology and may be used to authenticate the
     receiver to the sender. The most common example of this is the use
     of public key technology (asymmetric cryptography) such as secure
     sockets layer (SSL) to exchange a key for symmetric cryptography
     (shared secret) to protect a PIN or password (again shared secrets)
     during transit. This is still the most common approach in
     electronic commerce.

778. Another example is a token used to store a private key for
     asymmetric cryptography protected by a password (shared secret).
     The token may be used to sign multiple transactions once unlocked.
     While the shared secret does not play a direct role in the
     authentication of an individual transaction, it is a factor to be
     taken into consideration when determining the level of trust in the
     authenticator.

779. In some cases several layers can be involved in a secured
     technology implementation. For example asymmetric cryptography can
     be used to transfer symmetric cryptography session keys to protect
     a shared secret or biometric used for authentication. This is the
     process often used for Automatic Teller Machines (ATM) and
     Electronic Funds Transfer Point of Sale (EFTPOS) machines. Similar
     approaches are used with SSL and Virtual Private Networks (VPN).

Sender Receiver

Figure 28: Multiple Layered Secured Technology

780. In the example of SSL protecting a password, it is generally the
     recipient who sets up the session key exchange using its public key
     (server gated cryptography) generally supported by a webserver
     certificate. As such, the sender is reliant on the security of the
     receiver's public key technology for the security of the overall
     transaction. This is a factor that courts will need to take into
     consideration.

### Combined Technologies

781. It is possible to chain several secured technologies in a single
     transaction. For example a sender may have a number of passwords
     stored on their PC or on a token. The "wallet" of passwords or the
     token may protect the passwords with symmetric cryptography. A
     password or biometric can be used to release the required password
     for the transaction (chained technology). The password could then
     be protected in transit by symmetric cryptography established by
     asymmetric cryptography (secured technology).

Sender Password 1 Receiver

Figure 29: Combined Technologies

782. These types of implementations are already being used and indicate
     the complexity in establishing legal and policy frameworks for
     electronic transactions.

## USE IN ELECTRONIC BUSINESS MODELS

783. The use of hybrid technologies in the different business models
     identified in General Issues Chapter (Chapter 1) will vary
     depending on how the component technologies are linked together.

### Open Model

784. Hybrid technologies can provide greater security for transactions
     in open business models. Chained technologies can be used to
     protect asymmetric public keys through technologies such as shared
     secrets and biometrics. However it is the asymmetric cryptography
     element that is actually used in determining the business model.
     The shared secret or biometric elements of chained technologies are
     generally under the control of the sender or recipient and do not
     impact on the business model.

785. Secured technologies are not generally used in an open model. While
     an open model technology such as asymmetric cryptography may be
     used to secure a shared secret or biometric, the other technology
     has to be established in advance. The establishment of that
     relationship establishes a closed business model. For example the
     use of open model asymmetric cryptography to protect a credit card
     number is not an open business model. First the credit card number
     in itself is not an authenticator although the additional three
     digit authentication number on the back of the card is. Second
     there is a relationship between the credit card holder and issuer
     and the merchant and the issuer. This makes it a closed business
     model.

### Closed Model

786. Hybrid technologies can also provide greater security in closed
     business models. In the secured technology approach symmetric or
     asymmetric cryptography can be used to secure shared secrets, and
     biometrics. The use of symmetric cryptography as the securing
     technology will generally establish a closed system as there is a
     need for a prior arrangement to transfer the keys.

787. Chained technologies can be used to secure authenticators prior to,
     during or after their transmission. As all the likely individual
     technologies can be used in closed environments the hybrid can also
     be used in a closed environment provided the necessary prior
     arrangements are in place.

### Open-But-Bounded Model

788. Chained technologies can be used in open-but-bounded business
     model. Generally this model will involve the use of asymmetric
     cryptography as the technology used in transmission. An example of
     the use of hybrid technologies in an open-but-bounded business
     model is the use of ATMs in the finance sector. In certain cases a
     user may use their credit or debit cards issued by Financial
     Institution A on an ATM operated by Financial Institution B
     provided there is an agreement between the two financial
     institutions to do so. The user uses a shared secret (PIN or
     Password) recognised by Financial Institution A. The shared secret
     is protected by technology used by Financial Institution B. There
     is not, however, an agreement between the user and Financial
     Institution B. The agreement between the financial institutions
     forms the boundary for this model.

## USER REQUIREMENTS

789. Hybrid technologies can meet user concerns regarding electronic
     authentication and improve user confidence in electronic commerce.
     In secured technologies the extra layer of security can meet user
     concerns regarding identity theft. The most common cause of concern
     in undertaking electronic commerce is the use of credit card
     numbers over the Internet. While a credit card number is a low
     strength authenticator, it is a common source of identity theft.
     Misuse of credit card numbers is a common fraudulent activity. The
     use of technologies such as symmetric and asymmetric cryptography
     can reduce the likelihood of their capture and subsequent misuse.
     Although it is beyond the scope of this paper, it should be noted
     that most thefts of credit card numbers occur from inadequately
     protected databases. However the securing of the numbers in transit
     can increase consumer confidence. Consequently hybrid technologies
     of the type described can meet user requirements.

790. In chained technologies the inclusion of extra technologies at
     either the sender or receiver end can improve confidence in the
     authentication of the transaction. A number of economies have used
     the UNCITRAL Model Law on Electronic Commerce as the basis for
     their legislation. The Model Law includes under *Article 7.
     Signature*:

Where the law requires a signature of a person, that requirement is met
in relation to a data message if:

> \(a\) a method is used to identify that person and to indicate that
> person's approval of the information contained in the data message;

791. The inclusion of a step to trigger the authenticator, particularly
     if that step is under the sole control of the sender, can increase
     certainty that the person indicated their approval of the
     information in the data message. This is sometimes referred to as
     "intention to sign".

792. One issue that needs to be addressed is ensuring legal effect for
     hybrid technologies. In some economies technology specific
     legislation gives legal effect to the PKI element but not to other
     elements. In other economies at least partial support for chained
     technologies is implicit even in technology specific legislation by
     the incorporation of requirements for users to secure their private
     keys. An example is the European Union Electronic Signatures
     Directive requirement for the use of a secure signature creation
     device.

793. In some economies legislation giving legal effect to electronic
     authentication is based on the fact that the method used was
     reasonable in respect of the transaction. This is generally left to
     the courts to decide. The added security of both chained and
     secured technologies can add additional weight to any claim that an
     authenticator was in fact reasonable.

794. One of the key requirements for users is that hybrid technologies
     be seamlessly integrated to facilitate their use. Such integration
     is generally beyond the capability of individual users. Another
     factor is that in many cases applications have not been designed to
     support such integration.

795. Legal and integration aspects will need to be addressed at both the
     government and industry level if user requirements are to be
     addressed.

## CERTIFICATION MODELS

796. Certification is the process whereby a trusted person binds an
     individual or entity (including a machine or process) to a
     particular authenticator. In hybrid technologies, that process
     relates to an individual authenticator and therefore to a single
     element of the hybrid process. It is possible for several
     certification processes to occur when hybrid technologies are used
     for a single transaction.

### Formal Certification

797. In chained technologies the certification process most commonly
     involves an ASP formally certifying the public key of the sender.
     However it is possible for two formal certification processes to be
     involved. An ASP may certify the public key of the sender while
     another ASP may certify a Kerberos certificate it issues for the
     recipient. It is possible for a biometric to be formally certified
     although this is more likely to occur with secured technologies.

798. In secured technologies the formal certification process will
     generally relate to the securing technology. For example a
     webserver certificate used to set up a symmetric cryptography
     session key to protect a password may be formally certified by an
     ASP. An exception could be where an ASP formally certifies a
     biometric which may be protected by a securing technology.

### Informal Certification

799. The most common example of informal certification in hybrid
     technologies relates to the certification of asymmetric public
     keys. The use of PGP, SDSI or SPKI implementations of asymmetric
     cryptography in either chained or secured technology are an example
     of informal certification.

### No Certification

800. It is possible for hybrid technologies to operate without
     certification in any of the elements. An example would be a VAN
     which provides secure communications by issuing participants with
     symmetric keys. Issue of the keys does not involve certification of
     the user by the VAN operator. The user uses a password for
     authentication with the recipient. A third party would generally
     not have certified the password. This is use of a secured
     technology without certification.

## TRUST

801. The use of hybrid technologies can increase user trust by providing
     greater assurance that one or more of the following factors applied
     to the transaction:

```{=html}
<!-- -->
```
(a) The authenticator was appropriately protected by the sender;

(b) The authenticator was appropriately protected in transit; and

(c) The authenticator was properly applied on receipt.

```{=html}
<!-- -->
```
802. The more factors that apply the higher degree of trust there will
     be that the transaction has come from the person to whom the
     authenticator relates.

803. The use of chained technologies can increase trust by adding
     elements that satisfy (a), (c) or both. It will not, however,
     satisfy (b) unless it is combined with a secured technology as part
     of the chain. The use of secured technologies can increase trust by
     adding elements that satisfy (b).

804. There is an assumption that the use of hybrid technologies
     automatically increases the security, and consequently strength, of
     the authenticator. This is not always the case. Poor integration of
     the elements of both chained and secured technologies can negate
     the added security that may potentially be offered. There is a
     distinct lack of guidance for users, product manufacturers and
     system integrators in the implementation of hybrid technologies.
     While standards, protocols and best practice guides have been
     developed for a number of the elements that make up hybrid
     technologies, the only examples found of standards or protocols for
     integration of elements related to some specific implementations of
     the use of symmetric or asymmetric cryptography in protecting
     information, including shared secrets and biometrics, during
     transmission. These include protocols for SSL and standards for
     electronic funds transfer in the financial institutions sector.

## LIABILITY

805. In addition to the liability issues already identified in respect
     of the elements that make up a hybrid technology, there are a
     number of issues arising from the hybridisation process.

806. The use of hybrid technologies can result in a higher liability for
     senders in respect of their transactions. The greater assurance
     that a transaction came from the individual to whom the
     authenticator is related can increase their liability in respect of
     transactions using that authenticator. However, the use of hybrid
     technologies can present problems for senders if they are held
     liable for transactions for which they are not responsible. If the
     products being used in the various elements have been supplied by
     different vendors the user may be required to establish the element
     that failed as part of the process of establishing liability.
     Furthermore if a system integrator has been used to integrate the
     various elements there may be a need to establish its liability.

807. The use of hybrid technologies can also complicate the liability
     situation for recipients. If more than one ASP is involved in the
     hybrid process, the ASP responsible for mis-authentication will
     need to be determined before liability can be established. As with
     senders, receivers may also need to establish whose products have
     failed to establish liability as a result of the failure.

## ROLES OF PARTICIPANTS

808. As there are a number of technologies involved in the hybrid
     technology approach, there is an increased number of participants
     in the authentication process.

809. With individual technologies senders have a responsibility to
     protect the authenticator be it a private key, secret key or shared
     secret. Chained technologies may provide a tool to assist the
     sender in undertaking that protection.. However in some instances
     the sender still has a role to protect the element under their
     control. For example if the sender has a key or shared secret
     protected by storage in a wallet or on a token protected by a PIN
     or password then the sender still has a role in protecting that PIN
     or password.

810. With secured technologies the sender may have a role in ensuring
     that the securing technology is either appropriately applied or
     protected. A secret key for symmetric cryptography used to protect
     a shared secret needs to be protected to the same level as the
     shared secret. If the sender is relying on session keys generated
     by SSL then the sender will need to check the webserver certificate
     to ensure that the authenticator is being sent to the appropriate
     recipient.

811. With chained technologies, recipients need to ensure that the
     elements under their control are appropriately protected and
     configured. For example a Kerberos ticket server needs to be
     correctly configured to issue the appropriate ticket for a
     particular sender. For secured technologies the recipient has a
     role in ensuring that the securing technology is appropriately
     applied and protected. If webserver certificates are used for SSL
     then the recipient has a responsibility to ensure that the private
     key associated with that certificate is appropriately protected.

812. Hybrid technologies involve the integration of two or more
     technologies. In some cases that integration will occur on the
     sender or recipients system. In many cases the technical
     integration will be beyond users' capabilities. They will be
     reliant on product manufacturers or system integrators to effect
     the integration. There is a role for manufacturers and integrators
     to ensure that the integration does not introduce vulnerabilities.
     For example if a password wallet and symmetric cryptography
     applications are integrated as part of a hybrid technology the user
     needs to be assured that the channel used to carry a password to
     the encryption application does not allow that password to be
     compromised. There is also a further role for manufacturers in
     ensuring the interoperation of the various elements making up a
     hybrid technology.

813. Where an authentication service provider provides a service as an
     element of a hybrid technology process its role will primarily only
     relate to that element. However, where other elements of the
     process rely on the element provided, the ASP may have a role in
     ensuring that the service it provides will support the entire
     process. For example in secured technologies if a certification
     authority is providing webserver certificates to authenticate a
     recipient who in turn is establishing an SSL session to protect a
     PIN or password, then the ASP has a role in ensuring that the
     webserver certificate can be validated as part of the process even
     though the final authentication of the sender does not involve the
     ASP.

814. With chained technologies the role of ASPs is integral to the final
     authentication process. For example if a Kerberos ticket server
     issues a ticket on the basis of a digital signature validated by an
     ASP then the ASP process is critical to the final authentication
     process.

815. There is a significant role for standards making and protocol
     development bodies in ensuring that the appropriate standards and
     protocols are developed for the integration of the various elements
     of hybrid technologies. These standards or protocols can be used by
     manufacturers in product development and by accreditation bodies in
     evaluating the implementation of hybrid technologies.

816. There is a role for governments in ensuring that electronic
     transactions using hybrid technologies for authentication are
     granted legal effect. At their Fourth Meeting, APEC
     Telecommunications and Information Ministers adopted a Programme of
     Action[^80] including the following points proposed by the then
     Electronic Authentication Task Group (now the eSecurity Task
     Group):

There is a variety of business models, authentication technologies, and
implementation of electronic commerce. There should be free choice of
these models, technologies and implementations.

It should be recognised that in authenticating an electronic transaction
multiple technologies may be used

When developing legal and policy frameworks, consideration should be
given to the role of multiple technologies.

Legal and policy frameworks that focus on specific technologies can
impede the use of multiple technologies.

817. Implementation of these points within APEC and internationally has
     been inconsistent. This issue is discussed further in the Legal
     Issues Chapter (Chapter 9).

## INTEROPERABILITY

818. Where chained technologies are implemented there is a need for
     interoperability between consecutive elements of the chain to
     ensure the transfer of the authenticator. This does not necessarily
     require that the initial and final elements are interoperable. For
     example a private key passed from a token to an asymmetric
     cryptography system to digitally sign a transaction requires the
     asymmetric cryptography application to be able to accept the key
     from the token. The recipients system needs to be able to interpret
     and validate the digitally signed transaction but the fact that the
     private key was stored on a token is not relevant to the processing
     of the transaction. It may, however, be relevant in establishing
     the degree of trust in the transaction.

819. With secured technologies it is necessary that both the securing
     and authentication technologies are interoperable. For example if a
     biometric is secured by symmetric cryptography then the sender and
     recipient must both have the same symmetric cryptography algorithm
     and key and must have the same biometric processing application. In
     addition the recipient must have a previously established template
     of the biometric.

## ACCREDITATION

820. A number of protection profiles for authentication technologies
     have been, or are in the process of being, developed as part of the
     implementation of ISO/IEC 15408 ( also known as the "common
     criteria"). These include cryptographic technologies, biometrics
     and smart cards. These profiles relate to the products and not to
     their implementation or integration with other authentication
     technologies. There are not, however, any protection profiles for
     combining individual elements in hybrid technologies.

821. Some Economies and non-APEC countries have adopted a specification
     for information security management systems based on ISO/IEC 17799.
     This would allow accreditation of implementations of hybrid
     technologies in individual organisations but not of the products
     themselves.

822. A number of Economies and non-APEC countries have accreditation
     schemes for Certification Authorities who may be an element of a
     hybrid technology approach. In some of these processes there is an
     implication that users must be provided with the technology to
     secure their private key. However, as yet, none of these processes
     specifically focus on the hybrid technology approach.

823. An exception to the above is in respect of SSL where protocols
     exist for products which can be used as a securing technology to
     protect authenticators. However no formal scheme exists for
     evaluating implementations against that protocol.

## CULTURAL DIFFERENCES

824. The use of hybrid technologies does not generate any specific
     cultural differences over the cultural differences identified for
     the individual component technologies.

## AWARENESS

825. While there is some awareness among government, business and users
     on the use of individual authentication technologies, the same
     cannot be said about their combined use as hybrid technologies. The
     exception is SSL where there is significant awareness of its use in
     securing online transactions including protection of the three
     digit authentication code on credit cards. While there is some
     awareness of the use of asymmetric cryptography to transfer keys
     for symmetric cryptography, this is generally considered in the
     context of the confidentiality of message content rather than the
     protection of an authenticator.

826. Hybrid technologies are emerging as the most common implementation
     of authentication and there is a need for governments and product
     developers to increase the awareness of the community of the role
     of hybrid technologies. Lack of awareness of hybrid technologies is
     a major impediment to the early adoption of electronic
     authentication and consequently electronic commerce.

### Government Awareness

827. Within some governments there is considerable awareness of the use
     of hybrid technologies in security agencies. However this awareness
     rarely extends to the legal and policy developers responsible for
     developing the framework for electronic commerce. In most cases
     awareness relates to the individual technologies, particularly PKI,
     rather than the integration of those technologies.

828. A similar situation exists in inter-governmental organisations such
     as APEC, OECD and UNCITRAL with most delegates only being aware of
     the individual authentication technologies. The lack of government
     and inter-governmental awareness has hampered the development of
     appropriate frameworks to support the use of hybrid technologies.
     It also places limitations on governments' abilities to promote
     community awareness on the use of hybrid technologies.

### Academic Awareness

829. A number of academic research institutions have considerable
     awareness of the development of hybrid technologies. However this
     has been slow in finding its way into teaching curricula. Once this
     occurs an increase in community awareness can be expected.

### Business Awareness

830. There is some awareness among security professionals and system
     integrators of the role and use of hybrid technologies. However
     this awareness does not, in general, extend to business users who
     may be implementing electronic authentication. Furthermore there is
     little in the way of literature on hybrid technologies to provide
     guidance for business users. There are a number of professional
     bodies and manufacturers' groups but these tend to address
     individual authentication technologies rather than hybrid
     technologies.

831. There are, however, signs that this may be changing. The PKI Forum,
     an international multi-vendor and end-user alliance, has been
     addressing the role other technologies can play in conjunction with
     PKI. They have released papers on the role of smart-cards[^81] and
     biometrics[^82] in the context of PKI implementation.

### Individual User Awareness

832. As with business users, there is very little awareness of the role
     and use of hybrid technologies among individual users. Even more
     than business users, individual users tend to rely on commercial of
     the shelf products and product manufacturer/vendor advice when
     selecting electronic authentication products. As mentioned
     previously these products and advice are generally technology
     specific rather than addressing hybrid technologies.

## LEADERSHIP

833. Increased use of hybrid technologies will be facilitated by
     leadership and sharing of experience by those who have already
     adopted the approach or support its adoption.

### Governments

834. A number of government agencies have already adopted hybrid
     technology approaches. Those who have done so can adopt a
     leadership role by making the general community aware that such
     approaches are feasible and highlighting the benefits of such
     approaches. Providing it does not compromise the security of their
     operations, they can document and publish their experiences.

835. Governments also have a leadership role in developing and
     implementing legal and policy frameworks that support the use of
     hybrid technologies. A number of governments have established
     electronic authentication advisory bodies and/or published advice
     on the use of electronic authentication. That advice can include
     information on the implementation of hybrid technology approaches.

### International Organisations

836. International organisations, both governmental and business, can
     provide leadership by recognising the role of hybrid technologies
     and developing legal and policy frameworks that support their use
     at the international level. APEC has already achieved such
     leadership through the Ministerial endorsement of its activities in
     addressing multiple technologies, encouraging economies to support
     their use and in development of this report.

### Business Corporations

837. A number of business corporations are already using hybrid
     technologies often transparently to users. They can provide
     leadership by publicising the benefits to their clients and
     partners. Business can also provide leadership by continued
     implementation of hybrid technologies. There is a role for business
     associations in promoting the increased security advantages of
     hybrid technologies amongst their membership.

### Users and User Groups

838. There is little awareness of the role and use of hybrid
     technologies amongst individual users. There is a leadership role
     for user groups in advising their membership of the increased
     security advantages of hybrid technologies and how to use such
     technologies.

### IT Industry

839. There are a number of IT industry groups that can undertake a
     leadership role in respect of hybrid technologies. Technology
     specific industry groups can examine the integration of their
     technologies with other technologies to form hybrid technologies
     and encourage development of the necessary products. IT industry
     and IT security groups can provide leadership by encouraging
     members to develop hybrid technologies and their integration.

### Academic Institutes

840. Academic institutions can provide leadership by undertaking
     research and development in respect of hybrid technologies.

#   {#section-7 .unnumbered}

# 7. A Brief Tutorial on Cryptography for the Novice[^83]

1.  The objective of this paper is to provide an introduction to public
    key related cryptographic technologies to permit a basic
    understanding of how they are applied to support and enhance
    e-commerce.

```{=html}
<!-- -->
```
841. The paper will discuss cryptography in the context of the security
     services which we are familiar with and have grown accustomed to in
     the "paper world,\" and will introduce their digital equivalents in
     the context of e-commerce.

842. In cryptography fundamentals the two main families of cryptography
     will be covered: symmetric, or secret key cryptography, and
     asymmetric, or public key cryptography. Certificates and how they
     are used to protect the integrity of public keys will also
     discussed.

843. We use security services every day in our workplaces and society
     has established an intricate set of laws and customs surrounding
     the use of these security services. For example, if we need to
     identify someone, we ask him or her to appear in person, perhaps
     with some credentials. Or, he or she is introduced to us by a
     common acquaintance.

844. If we need to send a paper document securely, we wrap it in an
     envelope, a double-envelope, a sealed diplomatic bag, or a
     strongbox. And, if we need to enforce access to buildings, rooms,
     facilities, computers or information we do so with locks, keys,
     combinations and guards.

845. We verify the integrity of paper documents, by checking their
     signatures and the handwriting. In certain cases, documents are
     "sealed" with wax, stamped, or embossed. Anti-forgery features are
     used on money/cheques.

846. In the paper world, we authorise transactions like cheques and
     purchase orders with a signature.

847. Non-repudiation is the security service that prevents either the
     sender or the receiver of a transaction from denying it occurred.
     We primarily rely on contracts and witnesses to prevent such
     denials.

848. To summarise the above, the traditional security services that
     support commerce in the paper world and how they are provided are
     listed below:

-   **Identification**: Face-to-face meetings, credentials;

-   **Authentication**: Introductions through mutual acquaintances;

-   **Confidentiality**: Sealed envelopes, locked boxes;

-   **Access Control**: Locks, keys, combinations, and security guards;

-   **Integrity**: Handwriting, signature, hand delivery, notaries;

-   **Authorisation**: Signatures; and

-   **Non-repudiation**: Signatures on contracts, witnesses, purchase
    orders, and receipts.

## The Electronic World

849. Now that we live in a digital world, many of the old "paper world"
     mechanisms are not possible:

-   We may never get to meet the recipients of our electronic messages;

-   All electronic documents look the same - zeroes and ones are
    eminently forgeable; and

-   We need new services to replace envelopes, locks and combinations.

850. Not only do our messages and files need new security mechanisms,
     but the security mechanisms themselves may require additional
     security mechanisms. Two main security mechanisms are used to
     provide the digital equivalents of the "paper world" security
     services:

-   Encryption; and

-   Digital signature.

851. Encryption is the process by which plain text data are transformed
     to conceal their meaning. Encryption is a reversible process
     effected by using a cryptographic algorithm and key.

852. Digital signature will be described later - for now, we'll assume
     it is possible to uniquely "mark" a document. For those who need
     it, here is a more formal definition of digital signature:

Data appended to, or a cryptographic transformation of, a data unit that
allows a recipient of the data unit to prove the source and integrity of
the data unit and protect against forgery.

## Security Services

853. Below are the common terms used to describe security services and
     the mechanism that support them in the electronic world:

     Digital Signature

-   Identification and authentication

-   Access control

-   Non-repudiation

-   Authorisation

-   Integrity

-   Encryption (encipherment)

-   Confidentiality/privacy

-   Integrity

-   Continuity of authentication

854. Authentication is defined as those measures designed to provide
     against fraudulent transmission and imitative communications
     deception by establishing the validity of transmission, message,
     station or individual. If a user has a unique "signature," then he
     should be able to sign a random challenge, and no one else should
     be able to create a duplicate or forgery of the signature.

855. Non-repudiation can be achieved by implementing a protocol where a
     user or a process has to send a signed transaction or
     acknowledgment. Future attempts to deny the transaction can be
     refuted by storing the signed transaction and producing it for the
     dispute resolving authority.

856. Finally, having the originator "seal" it with his unique signature
     can ensure a message's integrity and authenticity.

### Pervasive Security Services

857. Just as the justice, legal, and law enforcement community provides
     pervasive, or universally enjoyed security services, similar
     services exist in the digital world. Here is a list of those
     associated with e-commerce:

-   Trusted third party

-   Audit

-   Key management

-   Generation, registration

-   Distribution

-   Storage, archiving

-   Update

-   Revocation, expiry, suspension

-   Destruction

858. Trusted (electronic) third parties are the equivalents of notaries,
     or judges whose impartiality is widely recognised. Audit is defined
     as an independent review and examination of system records and
     activities to assess the adequacy and effectiveness of system
     controls, to ensure compliance with established policies and
     operational procedures, and to recommend necessary changes in
     controls, policies, or procedures. Key management is the
     administration and use of the generation, registration,
     certification, de-registration, distribution, installation,
     storage, archiving, revocation, derivation and destruction of
     keying material in accordance with a security policy.

## Cryptography Fundamentals

859. Cryptography is the discipline that embodies principles, means, and
     methods for the transformation of data in order to hide its
     information content, prevent its undetected modification and/or
     prevent its unauthorised use. While it is possible to use analogue
     processes to perform cryptography, the vast majority of
     cryptosystems are digital. It is therefore necessary that all data
     (voice, fax, video, images, messages, files) be in digital form,
     that is, converted to binary numbers. Cryptography generally takes
     one or several numbers as an input, performs some sort of
     calculations on those numbers, and produces another number as the
     output. A cryptographic algorithm specifies which standardised set
     of calculations is to be performed. Cryptographic algorithms
     therefore perform mathematical calculations (permutations,
     combinations, or transformations) on the data.

860. In order to achieve the desired level of confidentiality (secrecy),
     a cryptographic key is used to control the cryptographic
     computation process. Cryptographic keys are also just numbers that
     control the operation of a cryptographic transformation (e.g.
     encipherment, decipherment, cryptographic check function
     computation, signature generation, or signature verification).
     Different cryptographic keys produce different mathematical
     results. Key guessing is a basic form of cryptographic attack. The
     chances of guessing keys diminish exponentially as the key size
     increases. Below is a 64-bit cryptographic key in digital form. It
     could also be displayed using alphanumeric symbols such as those on
     modern computer keyboards.

> 1101101110111011
>
> 1011101000110000
>
> 1100011011010101
>
> 0011011011011101

Figure 30: Cryptographic Key

861. The desired secrecy to be achieved through encryption is in part
     dependent on the uniqueness of the cryptographic key used by
     communicating users. Key lengths are normally expressed as "number
     of bits". Chances of guessing a 64-bit key are
     1:10,000,000,000,000,000,000 for each try. The chance of getting
     hit by lightening is 1:9,000,000,000.

862. There are two fundamental cryptographic techniques:

-   Symmetric cryptography

-   Asymmetric cryptography

### Symmetric Cryptographic Technique

863. This cryptographic technique uses the same secret key for both the
     originator\'s and the recipient\'s transformation. Without
     knowledge of the secret key, it is computationally infeasible to
     compute either the originator\'s or the recipient\'s
     transformation. Communicating parties must:

-   use the same encryption algorithm

-   use similar implementations

-   use the same key

864. The shared key must be kept secret. It is quite possible that two
     parties using the same algorithm may not inter-operate due to the
     lack of a shared key or differing implementations of the same
     algorithm. The following examples use to represent a key however,
     no physical key is involved

![](media/image1.wmf)Figure 31: Symmetric Cryptography

865. Remember that the original plaintext is digitised. It is therefore
     just a number (composed of zeroes and ones). The encryption
     function enciphers the plaintext by precisely "scrambling" the
     plaintext using an agreed algorithm. The encrypted ciphertext is
     another number, generally the same size as the first (plaintext)
     number. An observer cannot guess (or decipher) the original number
     (plaintext) from the ciphertext. Neither can the receiver, unless
     he has the same secret key that the originator used to create the
     ciphertext. For now, we'll assume the keys were generated and
     distributed by magic. (It will become clear that this is expensive
     magic.)

### Symmetric Key Management

866. Key management includes the systems, people and processes that are
     used to request, generate, distribute, store, account for and
     destroy key material. It is one of those "pervasive security
     services" mentioned earlier. There may also be a requirement for
     archiving key material but this need not be part of the traditional
     key management process.

![](media/image5.wmf)Figure 32: Symmetric Cryptography Key Management
(One-to-many)

867. In the figure above, the user wants to share data with three
     recipients. The three recipients all share a common key, and can
     therefore decipher any data sent to any of their peers. The
     advantage of this is that only one key is required for all four
     users. The disadvantage of this is that no two of the four users
     can send a secret that will remain their private secret. Also, if
     one of the people loses his key, everyone must get a new key.

868. Below is a depiction of the key distribution to satisfy a situation
     where four people would want private communications with each
     other.

![](media/image5.wmf)Figure 33: Symmetric Cryptography Key Management
(Many-to-many)

869. Here, each pair of users has their own key. For four users, six
     keys are needed. In general, for N users, N times (N minus 1)/2
     keys are required to give everyone a unique key pair. This quickly
     becomes unmanageable. 10,000 users would need almost 50 Million
     keys \[(10,000 X 9,999)/2 = 49,995,000\]. Secure distribution is
     the major challenge, particularly in any global network. So, for
     large numbers of users, if each pair of users requires a unique
     key, symmetric key management becomes a complex and very expensive
     proposition.

870. Symmetric cryptography is the most common method of encipherment
     due to its speed and ease of hardware implementation. However, key
     management costs are typically the highest cost of operating a
     symmetric cryptosystem. Some security services are not easily
     implemented. For example, it is difficult to provide a digital
     signature using only secret keys. An important characteristic of a
     digital signature is that it be verifiable by a third party. In the
     case of symmetric algorithms, the argument would be, "well, only
     the two of us knew the key, and I didn't sign it, so he must have."
     Yet this would require revealing the secret key to the third party.
     Further, since both sender and receiver have the same keys, neither
     could conclusively prove that the other signed something.

## Asymmetric Cryptographic Technique

871. This is a cryptographic technique that uses two related
     transformations, a public transformation (defined by the public
     key) and a private transformation (defined by the private key). The
     two transformations have the property that, given the public
     transformation, it is computationally infeasible to derive the
     private transformation. The following paragraphs will attempt to
     "decipher" the meaning of this.

872. In asymmetric cryptography, two keys are used and form a "key
     pair". One of the pair is referred to as the "public key', the
     other as the "private key". Depending on the security service to be
     delivered either may be used to perform the initial computation or
     the reverse computation on data as will be seen as this portion of
     the chapter is developed.

873. The term \"public key\" implies that the key is openly available
     and this is the uniqueness that makes this cryptographic technique
     more suitable for e-commerce applications. The \"private key\" must
     be kept protected from disclosure hence its name. As with Symmetric
     Cryptography, parties must implement the same algorithms and the
     implementation of the algorithms must be compatible. Each party
     therefore has at least one "key pair" associated with him/her as a
     user, one being publicly available, the other kept "secret".

874. A note here on the confusion that has been created by the
     indiscriminate use of the term "public key". Public key
     cryptography is a phrase commonly used to describe or denote
     asymmetric cryptography. The two are therefore synonymous unless
     referring specifically to the public key portion of a
     public/private key pair.

875. Encryption, to provide confidentiality (privacy), is done by using
     the recipient's public key. While it seems counter-intuitive to use
     a public key to encrypt data, only the recipient has the private
     key that is needed to decrypt the data. Public encryption keys are
     required for the recipient every time someone wishes to encrypt
     something for that recipient.

876. Two important points:

-   The recipient's key must be published and highly available (or held
    locally) or the encryption can not occur;

-   Changes to the public encryption keys must not be allowed, otherwise
    an attacker could replace a recipient's public key with his own. The
    sender would then mistakenly encrypt the message for the hacker
    instead of for the intended recipient. This latter point will be
    discussed later in the chapter under certification.

877. The diagram below depicts encryption with the recipient's public
     key and decryption with the recipient's private key.

Figure 34: Asymmetric Cryptography (Encryption)

### ![](media/image2.wmf)Asymmetric Cryptography Key Management

878. As previously stated public keys need to be published and protected
     from modification. Individual users can generate key pairs locally
     or they may be generated at a central facility. Where key pairs are
     generated centrally, it is essential that security measures for the
     generation and distribution of the key pair ensure that only the
     individual for whom the key pair is generated has access to the
     private key. It is also normal to have separate encryption and
     signature key pairs (signature keys will be explained further in
     the paper).

879. Since each user has a unique key associated with him/her the scale
     of distribution is one to one; one key pair per user. This scale of
     distribution is much more efficient and cost effective than that
     for symmetric cryptographic systems when the number of users
     exceeds certain thresholds. Remember the case for 10,000 users:
     50,000,000 keys for a symmetric system versus 10,000 for an
     asymmetric system. This becomes very important when keys must be
     revoked or changed for any reason. In the case of symmetric
     systems, for a closed community of interest, all of the keys are
     the same therefore all must be changed if there is a compromise. In
     an asymmetric system, only those compromised need to be changed in
     most cases. There are specific cases when all must be changed but
     these are exceptional and even then the one-to-one ratio limits the
     problem.

880. Public keys may be published in many different ways: manually
     distributed (hugely inefficient), printed in phone book style
     directories, made available on a web server, an ftp site, or on an
     X.500 directory.

881. Public keys can be protected from modification by keeping them on
     super high-assurance systems, however this is very expensive.
     Instead, they are normally "certified", that is signed by a
     "Certification Authority" (CA) whose signature all parties trust.
     More on this topic later.

882. While at first, it may seem less expensive from a key management
     perspective to generate keys locally, if key pairs are generated
     locally by users, at least the public key may still need to be sent
     to a central location to be "certified" and returned. For a number
     of reasons, it may be desirable to have separate encryption and
     signature key pairs. Different algorithms and key lengths may be
     used, and key-handling procedures may be different.

883. Because the keys are published, and the organisation handing out
     the keys may not have any way to directly contact the users of the
     keys, revocation of compromised, expired, and otherwise unusable
     keys becomes a challenge. Blacklists[^84] can be used to meet this
     requirement. The bottom line is that the one-to-one nature of
     public key management makes this a very viable technology for large
     numbers of users. There are some penalties though because of the
     long key lengths and computational times associated with asymmetric
     cryptography as compared to symmetric products and systems.

884. The security of asymmetric algorithms is based on the difficulty of
     solving certain mathematical problems. Well-designed asymmetric
     algorithms can be extremely difficult to "break." The calculations
     performed to conduct asymmetric cryptography tend to be
     computationally intense. As a result, in general asymmetric
     cryptographic techniques are slower than symmetric cryptographic
     techniques. A chosen plaintext attack is an attack where the
     attacker does not attempt to decipher the ciphertext. Rather, the
     attacker successively encrypts all possible values of the plaintext
     and compares his ciphertext with the original ciphertext. This only
     works when there are relatively few possible values for the
     plaintext.

## Digital Signature

885. A digital signature is not a digitised image of the sender's
     hand-written signature. It has nothing to do with "real"
     signatures. It is a calculation - a number, which when attached to
     a message or a data packet, can be shown to have been created by
     one and only one sender. A more formal definition is: "Data
     appended to, or a cryptographic transformation (see cryptography)
     of a data unit that allows a recipient of the data unit to prove
     the source and integrity of the data unit and protect against
     forgery e.g. by the recipient." Encryption can be provided by a
     number of cryptographic technologies. However, no other technology
     supports digital signatures as well as asymmetric cryptography.
     Below is a pictorial representation of a digital signature process:

![](media/image1.wmf)Figure 35: Digital Signature

886. Note that for digital signature, the original plaintext is now
     encrypted with the originator's private key. Now anyone who has the
     originator's public key can verify the signature on the message.
     Note the difference in the use of the public and private keys in
     that when encrypting to achieve confidentiality the recipient's
     public key is used to encrypt the message, and only the recipient
     can decrypt the message. A digital signature is ordinarily the same
     size as the original message. It is important to realise that the
     original message must also be sent from originator to recipient so
     that it can be compared with the signed copy. The original message
     may not necessarily be protected by a confidentiality service en
     route.

887. Since a digital signature is the same size as the message that was
     signed, we double the size of the message to be transferred. This
     is one of the potential penalties of using asymmetric cryptography
     to provide a digital signature. To avoid this, we use a hash
     function to "summarise" the message. A hash function has the
     characteristic that it takes a large input and produces a small,
     fixed length output. Even minor changes in the input message will
     cause significant changes in the hash. The hash function must also
     be a one way function; it should not be possible to guess two input
     messages whose calculated hashes are the same. If this were
     possible, an attacker could make up a false message and replace the
     original message, and the signature would still verify correctly.

![](media/image1.wmf)Figure 36: Hash Function

888. Above is a simple hash function used by accountants for hundreds of
     years to check their calculations. This simple hash function adds
     the digits of the input numbers to come up with a hash for each
     number. If the answer is more than a single digit number, the
     digits are added again until there is only one digit. To check the
     calculation, the hash results from the operands on the top of the
     calculation are combined in the same manner that the operands are -
     in this case, they are multiplied. If the hash of the results of
     the real calculation is equal to the results of the multiplication
     of the hashes, then the calculation was probably correct. Note that
     in this example there are only nine possibilities for the results
     of the hash. This makes this a particularly poor choice for a hash
     algorithm, since one in nine messages will arrive at similar
     hashes. It would therefore be easy to spoof such a message. Below
     is a pictorial representation of a digital signature provided
     through a hash function.

![](media/image2.wmf)Figure 37: Digital Signature Using Hash Function

889. Note that the original plaintext is sent to recipient, unchanged.
     The same hash function is used on both sides to calculate a hash of
     the original message. The originator signs this hash with his
     private key, and the recipient uses the originators public key to
     verify the signature on the hash. If the signed copy of the hash is
     identical to the hash that the recipient calculates for himself,
     then he knows the message has not been changed, and he can be sure
     the originator sent it.

## Certificates

890. A certificate in the sense of public key system or PKI is
     essentially a public key that has been signed by a CA. A CA is
     normally a trusted third party, that is a source that both sender
     and receiver trust. The issue here is that the CA is trusted to
     ensure the identification of each user, to post the correct and
     trusted public key in the certificate and to digitally sign the
     certificate so that its authenticity and integrity can be
     validated.

891. The main rationale for certificates is to protect the integrity of
     public keys. In order for the users to trust the signature of the
     trusted third party, they must have the signature verification key
     of the trusted third party in their possession. How this key is
     given to them is part of the initialisation challenge for public
     key systems. A very important part of a public key is an entry
     stating the location of the blacklist that would indicate whether
     this key has been compromised or suspended. The figure below is a
     pictorial representation of the contents of a typical digital
     certificate.

![](media/image1.wmf)Figure 38: Certificate Format

892. The important fields here are:

-   The signature algorithm ID which tells users which algorithms to use

-   The user's name

-   The user's public key

-   The extensions which can be used to specify how the certificate is
    used

893. The figure below shows the components of a typical CA. There is
     also a management component associated with a CA which is
     responsible for the identification and authentication of registered
     users.

![](media/image3.wmf)Figure 39: Certification Authority

894. The CA Server holds a private signing key that corresponds to the
     CA public verification key held by all users. This key is the most
     sensitive element in the entire cryptosystem. If the key of the CA
     server is compromised, then no certificate in the system can be
     trusted, and all must be recreated from scratch. The X.500
     directory is populated by the CA server with user public key
     certificates. The CA signs all the user public keys in the X.500
     server. This reduces the burden placed on the X.500 server to
     protect the integrity of the keys. If the keys were changed, it
     could still deny or reduce service to users who needed them, but at
     least the "trust" of the public keys would not be compromised.

# 8. LEGAL ISSUES

1.  There are a number of legal issues associated with the use of
    electronic authentication. These include legal effect of electronic
    transactions and electronic signatures, liability and privacy which
    are addressed below.

```{=html}
<!-- -->
```
895. This section does not address the legal frameworks of individual
     member economies. Information on the legal frameworks of APEC
     economies and other countries and organisations can be found at the
     Digital Signature Law Survey[^85].

## INTERNATIONAL LEGAL FRAMEWORK

896. The United Nations Commission on International Trade Law (UNCITRAL)
     has adopted model laws on electronic commerce and electronic
     signatures. It is currently examining electronic contracting.

### UNCITRAL Model Law on Electronic Commerce

897. The *UNCITRAL Model Law on Electronic Commerce*[^86] contains
     several articles relating to the use of authentication in
     electronic commerce. A number of other articles relate to message
     integrity and are relevant to the use of digital signatures.

###### Authentication {#authentication .unnumbered}

898. **Article 4** allows parties to select the authentication
     techniques for transactions between them. This can provide a bridge
     for transactions between economies that have different legislative
     approaches to electronic authentication.

899. **Article 7** provides that where the law requires a signature,
     that requirement is met if a method is used that identifies a
     person and indicates that persons approval of the information
     contained in the message. Furthermore the method must be as
     reliable as appropriate for the purpose for which the data message
     was generated or communicated.

900. **Article 9** provides that nothing in the rules of evidence shall
     deny admissibility of a data message solely on the grounds that it
     is a data message or if it is the best evidence that a person
     adducing it could reasonably expected to obtain, on the grounds
     that it is not in its original form. Furthermore data messages
     shall be given evidential weight taking into account the
     reliability of the manner in which the data message was generated,
     stored and communicated; the reliability of the manner in which
     integrity was maintained; the manner in which its originator was
     identified; and any other relevant factor. This Article relates to
     both authentication and integrity. The current lack of agreed
     international standards can lead to differing views on what
     constitutes "reliability".

901. **Article 13** provides that a message is deemed to be from the
     originator if the sender had authority to act for the originator.
     An addressee is entitled to assume a message is from the originator
     if the addressee established the originator using a technique
     previously agreed with the originator or if the message came from
     someone whose relationship with the originator enabled them access
     to the agreed procedure. The provision does not apply if the
     originator advises the message is not from the originator or the
     addressee should have known it was not from the originator. This
     has implications in terms of the transfer of authenticators or
     other means of establishing "authority to act".

     **Integrity**

902. **Article 8** provides that where the law requires information to
     be presented or retained in its original form that requirement is
     met it there is a reliable assurance as to the integrity of the
     information from the time it was first generated in its final form.
     The integrity requirement does recognise that changes may occur in
     the normal course of communication, storage and display.
     Furthermore the information required to be presented must be
     capable of being displayed to the person to whom it is to be
     presented. Again establishing what is meant by reliable is subject
     to interpretation.

903. **Article 9** provides, as mentioned above, that integrity is an
     issue in establishing the evidential weight given to a data
     message.

904. [UNCITRAL Model Law on Electronic Signatures]{.underline}

905. The *UNCITRAL Model Law on Electronic Signatures*[^87] addresses a
     number of issues related to the use of types of electronic
     authentication that meet the requirements of the Model Law.

906. **Article 3** provides that nothing in the Model Law shall be
     applied so as to exclude restrict or deprive of legal effect any
     method of creating an electronic signature subject to it meeting
     reliability criteria. While this is a technology neutral approach,
     one of the reliability provisions relates to the ability to detect
     message alteration and consequently will exclude some of the
     technologies outlines in this report from the provisions of the
     Model Law. In other words the excluded technologies are electronic
     authenticators but not electronic signatures.

907. **Article 5** provides that provisions of this law can be derogated
     from or their effect varied by agreement unless that agreement
     would not be effective under applicable law. This provision has the
     potential to limit the ability to vary by agreement allowed under
     Article 5 of the Model Law on Electronic Commerce. Its
     implementation may inhibit the ability of parties to use agreements
     to bridge the differences between differing implementations of the
     Model Laws.

908. **Article 6** provides that where the law requires a signature,
     that requirement can be met in relation to a data message if an
     electronic signature is used which was as reliable as was
     appropriate for the purpose of the data message. Reliability is
     established if the signatory creation data is linked to, and under
     the control of, the signatory and no other person; any alteration
     to the electronic signature after the time of signing is
     detectable; and any alteration to data is detectable. As mentioned
     above this will exclude a number of electronic authentication
     technologies from the provisions of this model law.

909. **Article 7** allows countries to make determinations on which
     electronic signatures satisfy the provisions of Article 6
     consistent with recognised international standards. As mentioned
     above the lack of agreed international standards is a problem in
     implementing this Article and Article 9 of the Model Law on
     Electronic Commerce. This has been recognised by a number of
     international organisations including APEC and is the subject of
     ongoing activity.

910. **Article 8** provides that a signatory shall exercise reasonable
     care to avoid unauthorised use of its signature creation data and
     notify any person reasonably expected to rely on the electronic
     signature in the event of compromise or substantial risk of
     compromise of the data. Furthermore a signatory shall exercise
     reasonable care to ensure accuracy and completeness of
     representations in certificates. A signatory shall be liable for
     its failures in respect of this article.

911. **Article 9** provides that a certification service provider for
     electronic signatures shall act in accordance with representations
     in respect of its policies and practices; exercise reasonable care
     to ensure the accuracy and completeness of representations relevant
     to the certificate; provide reasonable accessible means to relying
     parties; ensure timely revocation service and utilise trustworthy
     systems, procedures and human resources. A certification service
     providers shall be liable for its failures in respect of this
     article.

912. **Article 10** sets out factors relevant to establishing
     trustworthiness of certification service providers including
     financial and human resources, hardware and software systems,
     procedures for processing certificates and applications for
     certificates, records retention, availability of information to
     signatories and relying parties, audit processes and accreditation.

913. **Article 11** sets out the obligations for relying parties to
     verify the reliability of an electronic signature or if it is
     supported by a certificate to verify the validity, suspension or
     revocation of the certificate and observe the limitations with
     respect to the certificate. This could impact on the extent of
     liability of both signatories and certification service providers.

914. **Article 12** provides that geographic location shall not impact
     on legal effect of an electronic signature. The relevant factor for
     legal recognition is a substantially equivalent level of
     reliability to that required in the jurisdiction where legal effect
     is sought. Relevant international standards shall be regarded when
     establishing whether the is substantially equivalent reliability.
     Parties can agree between themselves to use certain types of
     electronic signatures or certificates. Establishing a
     "substantially equivalent level of reliability" is the focus or
     work in a number of international organisations including APEC.

### Hague Conference on Private International Law[^88]

915. The Hague Conference on Private International Law is currently
     addressing aspects of electronic commerce. Of particular relevance
     is their work on jurisdiction and dispute resolution which, while
     directed at broader aspects of electronic commerce, will impact on
     electronic authentication. The work has not yet been finalised.

### European Commission Directive on Electronic Signatures

916. The Council of the European Union has adopted a *Directive on a
     Community framework for electronic signatures*[^89]. This will
     impact on those wanting to use electronic authentication for
     transactions with parties in European Community (EC).

917. At the core of the Directive are the concepts of a
     secure-signature-creation device and a qualified certificate. These
     are defined in the Directive.

918. **Article 3** allows provision of certification services without
     state authorisation. However it requires supervisory processes for
     issuance of qualified certificates and processes for determination
     of conformity with secure signature creation devices requirements.
     Determinations of one member state are to be recognised by other
     member states.

919. **Article 4** provides that member states cannot restrict provision
     of certification services originating in another member state and
     that products complying with the Directive are permitted to
     circulate freely within the internal market.

920. **Article 5** provides that advanced electronic signatures based on
     qualified certificates and created by a
     secure-signature-creation-device satisfy legal requirements of
     signatures and are admissible as evidence. Other electronic
     signatures are not to be denied legal effect and admissibility in
     evidence. The definition of electronic signature in the Directive
     is broader than that in the UNCITRAL Model Law on Electronic
     Signatures and can cover a range of electronic authentication
     techniques.

921. **Article 6** provides that a certification service provider
     issuing qualified certificates shall be liable for damage as
     regards accuracy of information in the certificate and any
     assurance that signatory holds corresponding signature creation
     data unless it can prove that it didn't act negligently.
     Certificate service providers may indicate in a qualified
     certificate limitations on its use and shall not be liable for
     damages if limitations are exceeded.

922. **Article 7** provides that member states shall ensure that
     qualified certificates issued outside the EC are recognised if the
     service provider has been accredited by a member state; its
     certificates are guaranteed by a service provider within the EC
     that meets the requirements of the Directive or who is recognised
     under an agreement with the EC.

923. To support this process the Internet Engineering Task Force (IETF)
     has produced RFC 3039 *Internet X.509 Public Key Infrastructure
     Qualified Certificates Profile*[^90]. In addition APEC is working
     with the European Electronic Signature Standardization Initiative
     (EESSI)[^91] to ensure consistency between their work on electronic
     signatures.

924. **Article 8** provides that certification service providers shall
     comply with the provisions of the personal data protection
     directive. Personal data can only be collected from the data
     subject or with the explicit consent of the data subject. Use of
     pseudonyms is permitted.

## ASSURANCE AND EVIDENCE OF LEGAL EFFECT IN CROSS BORDER TRANSACTIONS

925. The eSecurity Task Group was originally established as the Public
     Key Authentication Task Group to develop PKI interoperability in
     the Asia Pacific region to facilitate electronic trade and
     commerce. Key objectives have been to establish interoperability at
     the legal and policy level and to ensure that users have access to
     a certificate that can be used for trade and commerce in the Asia
     Pacific region in particular and internationally in general.

926. Legal framework, government administration and cultural differences
     in APEC economies have resulted in differences in approaches to PKI
     that are currently impeding its implementation. Some of these
     differences are fundamental and are unlikely to be resolved in the
     foreseeable future. It is now necessary to look at technical means
     of bridging those differences. This section addresses existing
     approaches and how the APEC objective might be achieved. It draws
     heavily on the work of the PKI Forum[^92], the Internet Engineering
     Task Force (IETF) PKIX Working Group[^93] and some unpublished work
     of the European Electronic Signature Standardization
     Initiative[^94] Without that initial work this section would not
     have been possible.

927. The basic APEC definition of electronic authentication is

It is the means by which the recipient of a transaction or message can
make an assessment as to whether to accept or reject that
transaction.[^95]

928. As electronic authentication schemes and legislation have developed
     two basic aspects of that definition have emerged:

-   Trust that the person sending the transaction is the person they
    claim to be (assurance); and

-   Does the transaction have legal effect in the jurisdiction that the
    sender or receiver wants it to have legal effect (legal effect).

929. Both elements will need to be met before a recipient will accept
     the message or transaction.

930. In PKI, assurance is achieved by the CA issuing a certificate that
     binds a public key to an individual, organisation, role or
     attribute. Assurance of that binding can be established through an
     individual examining the policy and practices of a CA evidenced
     through documentation such as the Certificate Policy (CP),
     Certification Practice Statement (CPS), CA Disclosure Statement or
     other documentation provided by the CA. This could include the
     results of any independent audit of the CA and its practices.
     Alternatively an individual could rely on the results of a third
     party assessing the documentation and practices of the CA and
     determining the level of assurance. The third party could be the
     individual's CA, an independent assessment scheme or a government
     licensing or accreditation scheme.

931. Legal effect can be established through written contractual
     arrangements between transacting parties or through legislation. In
     some cases legislation may not permit transacting parties to enter
     into contractual arrangements regarding electronic signatures.
     Where contractual arrangements are permitted, the parties can agree
     the assurance and legal effect of the PKI scheme and how that is
     advised. Where legal effect is established through legislation the
     requirements to establish legal effect will vary according to how
     the legislation is framed. In some cases the legal effect is
     granted, or certain presumptions apply, only where a digital
     signature and its associated certificate were issued by a CA which
     is recognised by a regulatory body at the time of the transaction.
     This is a significant departure from the paper world where once a
     signature is associated with an individual, that signature
     generally has effect irrespective of the time when it is used. It
     is this need to establish legal effect at the point of time of each
     transaction that significantly complicates the use of digital
     signatures.

932. Three different legislative approaches have been used by
     governments:

-   Technology neutral;

-   Technology specific; and

-   Two tiered.

933. The technology neutral approach has been adopted by Australia,
     Canada, New Zealand and the United States. Under this approach it
     is left for courts to decide whether an authentication technology
     was reasonable or appropriate for the transaction. Legal effect is
     based solely on the level of assurance of the scheme. There is no
     specific requirement for evidence of legal effect in these
     jurisdictions. Individuals need to rely on case law to establish
     whether a particular scheme meets the test of reasonableness.
     Schemes such as the American Bar Association PKI Assessment
     Guidelines and Webtrust for CAs as well as other emerging standards
     based assessment processes such as the Certification Forum of
     Australasia[^96] scheme can assist individuals in assessing whether
     a particular PKI scheme is likely to meet the test of
     reasonableness.

934. However, even in technology neutral jurisdictions, schemes such as
     the Canadian Government PKI, the Federal Bridge CA (US Government)
     and Gatekeeper (Australian Government) have implemented approaches
     for ensuring a particular level of assurance. In these cases there
     is a need to establish a process to ensure that a particular CA has
     met the required level of assurance.

935. The technology specific approach has been adopted by Hong Kong,
     China; India; Korea and Malaysia. Under this approach legal effect
     is only granted to schemes, generally PKI, that meet the licensing
     or accreditation requirements specified through the legislation.
     Individuals will need to know whether a scheme meets the
     requirements for legal effect in these jurisdictions. Generally the
     Competent Authority such as the licensing or accrediting body
     established under the relevant legislation will test that the level
     of assurance of a scheme meets the requirements of the legislation.
     Thus evidence of legal effect also covers level of assurance.
     Individuals do not need to establish the level of assurance of the
     scheme.

936. The two tiered approach has been adopted by the European Union
     member states, Japan, Singapore and South Africa. Under this
     approach general legal effect is given to all electronic
     authentication schemes but specific legal effect or presumptions
     attach to those schemes, generally PKI, that meet the requirements
     specified in the legislation -- the top tier. The test of
     reasonableness and level of assurance requirement of technology
     neutral approaches would apply to the lower tier while the evidence
     of legal effect requirements of technology specific approaches
     would apply to the top tier.

937. While much has been spoken and written about business process
     engineering, the basic principles of the paper world now apply in
     the electronic environment. Contracts are still formed and need to
     meet the legal requirements in the appropriate jurisdiction or
     jurisdictions. This could be the sender's jurisdiction, the
     recipient's jurisdiction or both. In some cases, as in the paper
     world, a third jurisdiction is nominated as the jurisdiction whose
     laws apply to the contract. Businesses can use lawyers to examine
     the laws of the appropriate jurisdiction, however they need to know
     whether the scheme supporting the transaction was recognised or had
     legal effect in the appropriate jurisdiction at the time of the
     transaction. A further factor is that a CA may be located in yet
     another jurisdiction. Again legal effect has to be established in
     the appropriate jurisdiction.

938. In March 2001 the PKI Forum issued a discussion paper[^97] which
     primarily addressed inter-domain interoperability. The paper
     identified seven basic approaches to interoperability:

-   Cross-certification;

-   Bridge CA;

-   Cross-recognition;

-   Certificate trust lists;

-   Accreditation certificate;

-   Strict hierarchy; and

-   Delegated path discovery and validation.

939. These approaches are not mutually exclusive. A number were
     developed as a means of establishing a trust relationship similar
     to establishing a level of assurance. In most, but not all, cases
     the approaches were not developed to evidence legal effect which is
     only a recently emerging concept.

### Cross Certification

940. Cross certification is the process where one CA issues a
     certificate to another CA following a mapping of the respective
     policies and practices to ensure an equal or higher standard of
     certificate. The process can be unidirectional (the technical term
     is unilateral but this has caused some confusion amongst policy
     makers who assume that only one party is involved in the decision
     and this is not always the case) or bidirectional (bilateral).
     Where one CA is operating at a higher level than the second CA the
     cross certificate would be unidirectonal.

941. The process of cross certification is well established and
     potentially simple to implement technically. The approach requires
     the mapping exercise to be conducted with each CA with which a
     relationship is to be established. It also requires a relationship
     between the sender and relying parties' CAs. If a third
     jurisdiction is involved it further requires a relationship with a
     CA in that jurisdiction.

![](media/image4.wmf){width="3.8472222222222223in"
height="1.0777777777777777in"}Figure 40: Cross Certifrication

942. The approach can establish assurance. Where legal effect is
     dependent on recognition or licensing, a cross certificate from a
     CA established for licensing in the relevant jurisdiction can
     evidence that legal effect.

### Bridge CA

943. The Bridge CA concept was developed to reduce the number of cross
     certification mappings required for a CA to operate with a number
     of other CAs. Each CA cross certifies with the Bridge CA. This
     removes the requirement for individual cross certification by CAs
     under the Bridge CA. The Bridge CA can itself cross certify with
     other Bridge or Root CAs.

![](media/image5.wmf){width="4.145138888888889in"
height="2.7055555555555557in"}Figure 41: Bridge CertificationAuthority

944. The cross certification process used by a Bridge CA can establish
     assurance. Furthermore if a Bridge CA is established as part of a
     licensing or accreditation scheme to give legal effect, or has
     cross certified with a CA or Bridge CA established for that purpose
     it can provide evidence of legal effect. The approach requires a
     relationship between the sender and relying parties' CAs. If a
     third jurisdiction is involved it further requires a relationship
     with a CA in that jurisdiction.

### Cross Recognition

945. Cross recognition is an approach developed by the PKI
     Interoperability Expert Group and discussed in Chapter 3. The
     approach was developed to address the situation where there was not
     a relationship between the relying party and sender's CAs. It also
     transfers the decision to accept a transaction to the relying party
     rather than the relying parties CA.

Figure 42: Cross Recognition

946. ![](media/image6.wmf){width="4.442361111111111in"
     height="2.634027777777778in"}The means of implementing cross
     recognition was not discussed in the paper. Assurance and legal
     effect can be established through cross certificates
     (unidirectional or bidirectional); accreditation certificates,
     trust lists or even statements such as a list of CAs on a website.
     The level of assurance or weight of evidence of legal effect will
     depend on the particular approach.

### Certificate Trust Lists

947. The trust list approach has been utilised in browsers for some time
     through lists of CAs whose certificates can be trusted. However
     current implementations are relatively insecure as there is no
     mechanism to ensure that invalid entries cannot be imported into a
     trust list. This can be overcome by developing an approach that
     allows the trust lists to be signed by a competent authority. There
     are examples of trust lists being signed and published by users of
     PGP. The trust lists can either be downloaded and imported into
     browsers or accessed through online means such as the Online
     Certificate Status Protocol (OCSP) or the Simple Certificate
     Validation Protocol (SCVP). The problem is for users to identify
     the particular trust list or lists relevant to a transaction. A
     further problem is that the trust list for the CA and the
     CRL/status information for an individual certificate are likely to
     be in different locations thereby complicating processing and
     adding additional band width requirements. The advantage is that
     the approach does not require a relationship between the sending
     and relying parties' CAs nor with the relevant CA in a third
     jurisdiction.

![](media/image7.wmf){width="4.629166666666666in"
height="2.6659722222222224in"}Figure 43:Certificate Trust List

948. The trust list and check of CRL/status information can establish
     assurance. If the trust list is generated and signed by a competent
     authority that is part of a licensing or accreditation scheme to
     give legal effect it can provide evidence of that legal effect.
     Downloading a trust list runs the risk that a certificate may not
     have the assurance or legal effect at the time of the transaction.

949. The trust list approach will require further examination of the
     costs and benefits.

### Accreditation Certificate

950. The concept of an electronic accreditation certificate has been
     developed by the Australian Government Gatekeeper scheme[^98].
     Under the approach an electronic accreditation certificate is
     issued by a CA established under Gatekeeper for that purpose. While
     there are similarities between a CA issuing accreditation
     certificates and a root CA in an hierarchical scheme there are two
     fundamental differences.

951. First the accreditation certificate approach does not have a CP and
     CPS with which an accredited CA must comply. Accredited CAs can be
     root CAs for their own schemes. The approach focuses on ensuring
     that a certificate issued by an accredited CA meets a predetermined
     level of assurance. The approach could also be used for licensing
     where this is required under a legislative approach.

952. The second difference is that the approach does not preclude the
     accredited CA being subordinate to another CA or scheme. As multi
     national schemes emerge it is important that a particular CA has
     the ability to meet both the requirements of the superior CA of the
     multinational scheme and the requirements of schemes in particular
     jurisdictions where these requirements are compatible.

![](media/image8.wmf){width="4.14375in" height="2.31875in"}Figure 44:
Accreditation Certificate

953. An accreditation certificate can be used as a unidirectional cross
     certificate by an accredited CA providing assurance and where the
     accrediting body is part of a licensing or accreditation scheme to
     give legal effect it can provide evidence of that legal effect.

### Strict Hierarchy

954. The concept of strict hierarchy was part of the original
     development of PKI. In some quarters there was a view that there
     would be a single world hierarchy with a single international root.
     The single international hierarchy approach has now been discarded.

955. The hierarchical approach requires subordinate CAs to comply with
     the CP and CPS of the root CA. As the level of assurance required
     varies from scheme to scheme this requirement is no longer
     considered appropriate. A number of multinational schemes have been
     developed that provide an hierarchical approach for particular
     industry sectors.

956. The hierarchical approach can allow the root CA to interoperate as
     any other CA under the approaches discussed in this paper.

Figure 45: Strict Hierarchy

957. ![](media/image9.wmf){width="4.131944444444445in"
     height="2.6958333333333333in"}As all certificates track back
     through a structure of CAs to the Root CA this approach can provide
     assurance. Where the Root CA is part of a licensing or
     accreditation scheme to give legal effect it can provide evidence
     of that legal effect.

### Delegated Path Discovery and Validation[^99] [^100] [^101]

958. Delegated path validation was developed to allow for checking of
     individual certificates. In many respects a certificate status
     server performs a similar role to a certificate trust list. Options
     under OCSP allow for responses to be signed. SCVP is less developed
     but appears to allow tracking beyond the server. SCVP also allows
     for responses to be signed.

![](media/image10.wmf){width="4.343055555555556in"
height="2.6555555555555554in"}Figure 46: Delegated Path Discovery

959. It is feasible that a certificate status server could be
     established specifically for the purpose of providing information
     on the status of CAs that meet requirements for assurance or legal
     effect in a particular jurisdiction. This could be achieved by
     storing the certificates of recognised CAs on a server operated by
     the competent authority in the relevant jurisdiction. If a protocol
     such as SCVP could be further developed to allow that server to
     refer the status request for an individual certificate back to the
     issuing CA or another certificate status server to check current
     validity and return the results to the relying party, the overhead
     for the user would be diminished. The approach may be able to build
     on existing schemes whereby directories of cross certificates or
     accreditation certificates could carry out the role of a
     certificate status server.

960. Because of liability implications, the response may need to be in
     two parts. The competent authority confirms that certificates
     issued by the sender's CA are legally recognised in that particular
     jurisdiction while the issuing CA confirms that the certificate is
     valid. In other words legal effect is established by the Competent
     Authority and assurance is provided by the issuing CA.

961. In many aspects this is similar to the role carried out by
     validation authorities. If a VA were to provide information on both
     assurance and legal effect by storing relevant directories of
     certificates, CRLs and accreditation information, the assurance and
     legal effect could be available from a single source. This would be
     a significant value added.

### Harmonised Trust Service Provider Status Information

962. The European Electronic Signatures Standards Initiative has
     produced a technical report *Provision of harmonized Trust Service
     Provider status information*[^102].

963. The Report outlines an approach to allow relying parties to access
     information on whether a Trust Service Provider was operating under
     the approval of a recognised scheme at the time it provided its
     services. This would included whether the Trust Service Provider
     was recognised as issuing qualified certificates. The approach is
     similar to the Certificate Trust List approach discussed above. The
     status information could include an indication of the legal as well
     as trust status.

![](media/image11.wmf){width="5.763194444444444in"
height="3.1534722222222222in"}Figure 47: Provision of Trust Status
Information

964. The Technical Report goes a step further and suggests the format
     for the provision of the information.

965. In summary the cross certification, Bridge CA and hierarchical
     approaches will not work where there is not a direct or chained
     relationship between the sending and relying parties' CAs. The
     other approaches do not require this relationship.

966. Where the relationship does not exist the development of SCVP and
     signed certificate trust lists could address this issue. Whichever
     approach is adopted any application will need to allow the relying
     party to nominate the jurisdiction that they wish to check. Further
     work is required in this area and APEC economies have a role to
     play in that development.

967. However, regardless of the particular approach adopted, there is a
     requirement for a jurisdiction to examine the level of assurance of
     schemes in other jurisdictions. This may involve examination of the
     CP and CPS of a root or bridge CA or of individual CAs.
     Alternatively it may involve examination of the assessment,
     accreditation or licensing processes. As noted in the PKI
     Interoperability Expert Group mapping exercise the lack of accepted
     international standards, particularly for the CA as opposed to the
     products used by the CA, is hampering the examination of foreign
     schemes. APEC economies have a role to play in promoting the
     development of these standards.

## LIABILITY

968. There are a number of liability issues that need to be addressed.
     These include:

-   liability of the user for misuse of their authenticator, including
    failure to adequately protect the authenticator from misuse;

-   liability of an authentication service provider in certifying the
    holder of an authenticator;

-   liability of an authentication service provider for losses incurred
    through failure to provide a service or for negligence in providing
    a service.

969. There have been some suggestions that liability should be addressed
     through legislation. Others feel that contractual arrangements
     would suffice although there is a "contract privity problem"
     involved where the relying party has no prior contractual
     arrangement with either the user or the user's authentication
     service provider.

970. The "contract privity problem" has existed in aspects of
     international trade for centuries. While the scale of electronic
     commerce will increase dramatically with the uptake of the new
     technology, existing approaches to international trade may, in the
     short term, be able to handle problems that arise.

971. The OECD addressed these issues as they relate cryptographic
     authenticators in the Liability Principle of its Cryptography
     Policy Guidelines.

7\. LIABILITY

WHETHER ESTABLISHED BY CONTRACT OR LEGISLATION, THE LIABILITY OF
INDIVIDUALS AND ENTITIES THAT OFFER CRYPTOGRAPHIC SERVICES OR HOLD OR
ACCESS CRYPTOGRAPHIC KEYS SHOULD BE CLEARLY STATED.

The liability of any individual or entity, including a government
entity, that offers cryptographic services or holds or has access to
cryptographic keys, should be made clear by contract or where
appropriate by national legislation or international agreement. The
liability of users for misuse of their own keys should also be made
clear. A keyholder should not be held liable for providing cryptographic
keys or plaintext of encrypted data in accordance with lawful access.
The party that obtains lawful access should be liable for misuse of
cryptographic keys or plaintext that it has obtained.

972. This principle could be extended to any authentication scheme in
     which case the thrust of the principle would be that contracts or
     legislation can be used to establish the liability of users,
     relying parties or authentication service providers.

973. In some cases governments have intervened to set limits on
     liability in the debit and credit card field as a consumer
     protection issue. At this stage this does not appear to have
     occurred in respect of general online activities. The OECD has
     issued Guidelines for Consumer Protection in the Context of
     Electronic Commerce[^103] which include the following guideline:

Businesses engaged in electronic commerce should provide sufficient
information about the terms, conditions and costs associated with a
transaction to enable consumers to make an informed decision about
whether to enter into the transaction.

974. While the Guideline refers to a transaction, it would also include
     the use of authentication in that transaction. It could also be
     reasonably extended to apply to an electronic authenticator used in
     multiple transactions by a consumer with a particular business. In
     other words business should provide information on the terms and
     conditions associated with the authentication of electronic
     transactions.

975. The Guidelines go on to include under the guideline on payment
     systems:

Limitations of liability for unauthorised or fraudulent use of payment
systems, and chargeback mechanisms offer powerful tools to enhance
consumer confidence and their development and use should be encouraged
in the context of electronic commerce

976. This again could logically be extended to cover limitations of
     liability for the authentication related to a transaction as well
     as a payment system in the consumer environment.

977. In addition to the OECD Principle, UNCITRAL has addressed the
     conduct requirements of signatories, relying parties and
     certification service providers in it Model Law on Electronic
     Signatures. The articles hold the parties liable for their failure
     to meet the specified requirements.

978. The European Commission Directive on Electronic Signatures requires
     member states to ensure that certification service providers are
     liable for damage caused to parties who rely on their certificates
     in specified circumstances unless the certification service
     provider can prove that it has not acted negligently.

979. While liability can be clearly established between a user and its
     authentication service provider through the contact terms and
     conditions at the time an authenticator is issued or received, this
     does not assist the recipient in establishing liability if he or
     she relies on an authenticator. While it would be impractical to
     include all terms and conditions with an authenticator to allow the
     recipient to make a judgement, it may be possible to develop a
     series of model terms and conditions which could be referenced with
     the authenticator.

980. There is also the question of whether governments should limit
     liability to encourage the establishment of authentication service
     providers. The counter argument is that limiting liability may
     discourage electronic transactions of a value above the legislated
     liability limit. In these cases it may be necessary to allow users,
     recipients and authentication service providers to negotiate a
     contract incorporating liability greater than the statutory limit
     possibly based on a higher fee. Limiting liability may also
     discourage rigorous adoption of standards by authentication service
     providers and detract from the trust and certainty sought to be
     achieved by authentication schemes***.***

981. Decisions as to whether to adopt contractual or legislative
     approach will be a matter for individual jurisdictions. However,
     when considering which approach to adopt, jurisdictions need to
     take into consideration that other jurisdictions may take the other
     approach and make appropriate provisions for accommodating the
     differences.

## PRIVACY

982. A significant issue for individual users is the privacy of their
     personal information provided as part of an electronic
     authentication process. In a number of economies the protection of
     personal data is mandated in either electronic transactions or data
     protection legislation. In general the legislation is based on the
     *OECD Guidelines on Protection of Privacy and Transborder Flows of
     Personal Data.* The Guidelines and other OECD material on privacy
     in the electronic environment are available at the OECD
     website[^104].

983. The Council of the European Union has adopted *Directive 95/46/EC
     of the European Parliament and of the Council of 24 October 1995 on
     the protection of individuals with regard to the processing of
     personal data and on the free movement of such data*[^105]*.*
     Chapter IV of the Directive covers the transfer of personal data to
     third countries. Where electronic authenticators are sent from
     European Union member countries to APEC economies, the provisions
     of the Directive may apply. Economies will need to take this into
     consideration when developing their electronic authentication
     frameworks.

984. A number of privacy groups have expressed concerns regarding the
     use of electronic authentication. While recognising their privacy
     enhancing capabilities the technologies offer they are concerned
     that implementations without adequate privacy protection will
     adversely impact on individuals.

985. There is a concern that electronic authentication is being used in
     the electronic environment for transactions where authentication is
     not required in the physical/paper environment. In many
     transactions the fact that a payment has been made is more
     important than who has made that payment. In other cases
     authentication of membership of a community is more important than
     authentication of individual identity within that community. System
     designers will need to ensure that their schemes do not include
     excessive authentication requirements.

986. Another concern is that association of authenticators and
     transactions can allow the building of profiles of individual's
     activities. This is of particular concern in economies where a
     single authenticator is mandated for individuals. Measures to
     prevent the consolidation of transaction data can address this
     issue.

987. In a number of economies there is not community support for single
     national identifiers. Individual identifiers are used for specific
     purposes. There is concern that the introduction of electronic
     authentication can result in the adoption of electronic national
     identifiers. Most of these economies have adopted technology
     neutral approaches to electronic transactions and do not regulate
     electronic authentication giving individuals the opportunity to use
     multiple authenticators. Where single national identifiers are not
     used in the physical/paper world policy makers need to ensure that
     they are not created in the electronic world through inappropriate
     electronic authentication requirements.

988. A major concern is the security of data supplied in the
     authentication process. That data could have been provided to an
     authentication service provider or to the recipient of an
     authenticated transaction. The recipients of personal data need to
     ensure that appropriate security measures are in place to protect
     that data. Where an authentication service provider publishes
     information as part of its services they need to ensure that the
     person to whom that data relates is aware that it will be published
     and has given informed consent to that publication. This should be
     included in the agreement between the individual and the service
     provider.

989. It could be argued that by using an authenticator, the individual
     to whom that authenticator relates has consented to the transfer of
     the personal data involved. This is not necessarily the case.
     Individuals may not be aware of what information is being
     transferred and what is done with it on receipt. Authentication
     service providers need to ensure individuals are aware of the
     implications of using the authenticators they issue. This should be
     included in the agreement between the individual and service
     provider.

990. Recipients of transactions also need to inform individuals of the
     use they will make of authentication data as well as how it will be
     protected. This could be included in the recipients privacy policy.
     The OECD has developed *a Privacy Policy Statement Generator*[^106]
     to assist organisations in developing their privacy policies.

### Public Key Infrastructures

991. Public key infrastructures to support asymmetric cryptography and
     digital signatures have raised serious concern amongst privacy
     groups. Greenleaf and Clarke in their paper *Privacy Implications
     of Digital Signatures*[^107] expressed the concern as:

Digital signatures represent one of the most explosive clusters of
privacy-threatening technologies, motivations and processes that has yet
been invented. Enormous care must be invested in the development of
digital signature infrastructure, and the parallel development of
privacy protections

It is the public key infrastructures that raise the concerns and not the
digital signatures themselves. However it does evidence the concerns
amongst privacy groups.

992. The Australian Privacy Commissioner expressed the concerns as
     follows:

A key issue for the Australian community in the information age is how
they can be confident of their privacy while taking advantage of the
developments offered in information and communications technology. This
is reflected, for example, in recent research into attitudes to privacy
conducted by my Office that indicated more than half of all internet
users had more concerns about the security of personal information when
using the internet.

Public key technology (PKT) and its surrounding infrastructure - public
key infrastructure (PKI) - is a powerful technology which offers
benefits to enhance privacy of individuals. It can, for example, provide
confidentiality of online communications, authentication of parties in
online transactions, as well as non-repudiation of transactions and
message integrity. However, there are privacy risks associated with PKI
and these need to be carefully managed."

993. As a result the Commissioner developed *Privacy and Public Key
     Infrastructure: Guidelines for Agencies using PKI to communicate or
     transact with individuals*[^108]*.* While directed at government
     agencies, the guidelines are equally applicable for private sector
     PKIs. The Guidelines are:

     ***Agency Client Choice on the Use of PKI Applications** Agencies
     should allow their clients to choose whether to use PKI for a
     particular transaction and to offer them alternative means of
     service delivery. The alternative need not always be an online
     alternative. In providing this choice agencies should advise their
     clients of the privacy risks and advantages associated with their
     use of PKI and alternative methods for that transaction*

     ***Awareness and Education** Agencies and their contracted PKI
     service providers should co-operate closely to ensure that their
     clients are fully informed of the proper use of PKI and of the
     risks and responsibilities associated with the use of PKI,
     including the secure management of private keys*

     ***Privacy Impact Assessments (PIAs)** Agencies should undertake a
     Privacy Impact Assessment before implementing a new PKI system or
     significantly revising or extending an existing PKI system*

     ***Evidence of Identity** When developing PKI applications or
     contracting with PKI services providers, agencies should ensure
     that only minimum EOI that is necessary for, or directly related,
     to the process is collected.*

     *In addition, where a client wishes to obtain more than one
     certificate then the client should be given a range of options
     including:*

     *consenting to use a Gatekeeper certificate of equal or higher
     value to apply for a new certificate;*

     *consenting to the re-use of EOI documentation previously provided
     by the*

     *client; or*

     *providing documentation on registration for an additional
     certificate*

     ***Aggregation of Personal Information** In the course of PKI
     transactions with clients, agencies and their contracted PKI
     service providers should ensure that no detailed history of client
     transactions is created or used by the agency or contracted PKI
     service provider, except to the extent that this is required for
     system maintenance or evidentiary purposes*

     *Agencies and contracted PKI service providers, should not use PKI
     transactions to collect personal information that is not necessary,
     or directly related to, the PKI business transaction*

     ***Single or Multiple Certificates** Agencies should allow clients
     to use more than one certificate, where these are fit for the
     purpose of the relevant application. Agencies should also recognise
     certificates they have not issued where these certificates are fit
     for the purpose of the relevant application*

     ***Subscriber Generation of Keys** Where an agency issues
     certificates or contracts for their issue, the agency should allow
     its clients the option of generating their own keys, provided that
     the agency is satisfied that subscriber key generation can be
     implemented securely.*

     ***Public Key Directories** Agency clients should be allowed to opt
     out of including their public keys in a public key directory (PKD)
     where the PKD is published*

     ***Pseudonymity and Anonymity** Agencies should provide their
     clients with anonymous and pseudonymous options for transacting
     with them, to the extent that this is not inconsistent with the
     objectives and operation of the relevant online application.*

994. These Guidelines address the major privacy issues raised by the use
     of PKI. They do not, however, address the use of attribute
     certificates as their use is still being considered by the
     Australian Government for its Gatekeeper scheme. Attribute
     certificates can evidence membership of a community of interest
     without the need for individual identity certificates and
     consequently reduce some privacy concerns.

995. If individual users are to adopt the use of digital signatures
     within a PKI, implementations will need to incorporate privacy
     protections similar to those set out above.

### Biometrics

996. Most of the privacy concerns regarding biometrics have been
     addressed at their use in the physical world. However a number of
     the concerns apply equally to the use of biometrics as electronic
     authenticators. The Electronic Privacy Information Center (EPIC)
     expressed the concerns as follows[^109]:

There are significant privacy and civil liberties concerns regarding the
use of such \[biometric\] devices that must be addressed before any
widespread deployment. Briefly there are six major areas of concern:

> **Storage**. How is the data stored, centrally or dispersed? How
> should scanned data be retained?
>
> **Vulnerability**. How vulnerable is the data to theft or abuse?
>
> **Confidence**. How much of an error factor in the technology\'s
> authentication process is acceptable? What are the implications of
> false positives and false negatives created by a machine?
>
> **Authenticity**. What constitutes authentic information? Can that
> information be tampered with?
>
> **Linking.** Will the data gained from scanning be linked with other
> information about spending habits, etc.? What limits should be placed
> on the private use (as contrasted to government use) of such
> technology?
>
> **Ubiquity.** What are the implications of having a electronic trail
> of our every movement if cameras and other devices become commonplace,
> used on every street corner and every means of transportation?

997. The Australian Privacy Commissioner in a paper *Biometrics and
     Privacy The End of The World as We Know It or The White Knight of
     Privacy?*[^110] noted:

The task I have as the Privacy Commissioner, along with other
Commissioners, is to engage actively with the issue. We need to consider
what can be done to protect privacy while still achieving the benefits
that biometrics is capable of bringing to society and to individuals.
Indeed, wherever possible, the real objective should be to seek ways of
ensuring that biometric technologies achieve these benefits while
actually enhancing privacy

998. The development of guidelines such as those developed for PKI could
     increase user confidence in the use of biometric authenticators
     which conform with those guidelines.

[^1]: APEC Blueprint for Action,
    <http://www.dfat.gov.au/apec/ecom/ecom_blueprint.html>

[^2]: Asia Pacific Economic Cooperation, Telecommunications Working
    Group, Business Facilitation Steering Group, *Public Key
    Authentication Task Group Preliminary Report,* September 1997,\
    <http://www.apectelwg.org/apecdata/telwg/eaTG/eaTG-1.html>

[^3]: Organisation for Economic Cooperation and Development, *Inventory
    of Approaches to Authentication and Certification in a Global
    Networked Society*, Paris, October 1998,
    <http://www.oecd.org/dsti/sti/it/ec/prod/reg_3e.pdf>

[^4]: Office of Government Information Technology, *Government Online
    GATEKEEPER A strategy for public key technology use in the
    government*; <http://www.ogit.gov.au/gatekeeper/pub/GATEKEEPER.pdf>

[^5]: Michael S Baum, Technology Neutrality and Secure Electronic
    Commerce: Rule Making in the Age of "Equivalence\",
    [http://www.verisign.com/repository/pubs/tech_neutral/]{.underline}

[^6]: <http://www.opengroup.org/messaging/wema>

[^7]: <http://www.ilpf.org/events/intlprin.htm>

[^8]: See for example abstract to paper *Let A Thousand (Ten Thousand?)
    CAs Reign\
    * Stephen Kent, BBN Corporation, <http://jya.com/dimacs.txt>

[^9]: <http://www.ietf.org/html.charters/pkix-charter.html>

[^10]: <http://www.ietf.org/html.charters/spki-charter.html>

[^11]: <http://www.ietf.org/html.charters/openpgp-charter.html>

[^12]: See for example\
    Asia Pacific Economic Cooperation, *APEC Economic Leaders
    Declaration: Connecting the APEC Community*, Vancouver, Canada,
    November 25, 1997 http://www.apecsec.org.sg/econlead/vancouver.html\
    Organisation for Economic Cooperation and Development, *Dismantling
    the barriers to global electronic commerce*, Paris, November 1997,
    http://www.oecd.org/dsti/sti/ec/prod/dismantl.htm

[^13]: United Nations Commission on International Trade Law, *Model Law
    on Electronic Commerce*, New York, June 1996,
    <http://www.uncitral.org/english/sessions/wg_ec/index.htm#TOP>

[^14]: See for example:

    Electronic Commerce Promotion Council of Japan, Certification
    Authority Working Group, *Publication of \"Exposition of
    Cross-Certification Technology and Proposed Basic Specification\"*,
    <http://ecom.ecom.or.jp/eng/output/97report_summary/wg08-2.htm>\
    United Nations Commission on International Trade Law, PLANNING OF
    FUTURE WORK ON ELECTRONIC COMMERCE: DIGITAL SIGNATURES,
    CERTIFICATION AUTHORITIES AND RELATED LEGAL ISSUES,
    <http://www.uncitral.org/english/sessions/wg_ec/wp-71.htm>

[^15]: Minister for Communications, Information Technology and the Arts,
    *New e-commerce authentication council members announced*, Press
    Release, 17 September, 1999,
    <http://www.dcita.gov.au/nsapi-text/?MIval=dca_dispdoc&ID=4330&template+Newsroom>

[^16]: Organisation for Economic Co-operation and Development,
    *Guidelines for Consumer Protection in the Context of Electronic
    Commerce*, 9 December 1999,
    http://www.oecd.org/dsti/sti/it/consumer/prod/CPGuidelines_final.pdf

[^17]: http://www.oecd.org/EN/document/0,,EN-document-43-nodirectorate-no-24-10242-13,00.html

[^18]: http://csrc.nist.gov/publications/fips/fips186-2/fips186-2.pdf

[^19]: http://www.cca.gov.sg/

[^20]: http://www.govonline.gov.au/projects/publickey/GatekeeperAccreditation.htm

[^21]: http://www.cio-dpi.gc.ca/pki-icp/index_e.asp

[^22]: http://csrc.nist.gov/pki/fbca/welcome.html

[^23]: http://www.abanet.org/scitech/ec/isc/pagv30.pdf

[^24]: http://www.cpawebtrust.org/certauth.htm

[^25]: http://www.itu.int/rec/recommendation.asp?type=products&lang=e&parent=T-REC-X

[^26]: <http://www.iso.org/iso/en/stdsdevelopment/tc/tclist/TechnicalCommitteeStandardsListPage.TechnicalCommitteeStandardsList?COMMID=143>

[^27]: <http://www.ietf.org/html.charters/pkix-charter.html>

[^28]: <http://csrc.nist.gov/publications/fips>

[^29]: <http://csrc.nist.gov/pki/documents/CIMC_PP_20011031.pdf>

[^30]: <http://www.rsasecurity.com/rsalabs/pkcs>

[^31]: <http://portal.etsi.org/sec/el-sign.asp>

[^32]: <https://committees.standards.com.au/COMMITTEES/IT-012/PRODUCTS>

[^33]: <http://www.sas70.com/index2.htm>

[^34]: <http://www.aoema.org/projects/awareness.htm>

[^35]: [http://www.pkiforum.org](http://www.pkiforum.org/)

[^36]: [http://www.asia-pkiforum.org](http://www.asia-pkiforum.org/)

[^37]: <https://www.eema.org/ecaf>

[^38]: http://www.ilpf.org/groups/index.htm#authentication

[^39]: http://rechten.kub.nl/simone/ds-lawsu.htm

[^40]: http://www.iccwbo.org/home/menu_electronic_commerce.asp

[^41]: [http://www.cesg.gov.uk/technology/pki/cloud-cover/Final%20Report%20v1-2.pdf](http://www.cesg.gov.uk/technology/pki/cloud-cover/Final Report v1-2.pdf)

[^42]: <http://www.eema.org/pki-challenge>

[^43]: <http://www.apectelwg.org/apecdata/telwg/25tel/estg/estg05.htm>

[^44]: http://www.pkiforum.org/pdfs/ca-ca_interop.pdf

[^45]: *http://www.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-08.txt*

[^46]: APEC Electronic Commerce Task Force, Nov 1998, APEC *Blueprint
    for Action on E-Commerce,*
    http://www.dfat.gov.au/apec/ecom/ecom_blueprint.html

[^47]: Communications Security Establishment, Canada and National
    Computer Board, Singapore, Mar 1999, *Cross-Certification Within
    APEC*

[^48]: IETF-PKIX Working Group, Jun 1999, *Internet X.509 Public Key
    Infrastructure PKIX Roadmap.
    http://www.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-08.txt*

[^49]: IETF-PKIX Working Group, Mar 1999, *Internet X.509 Public Key
    Infrastructure Certificate Policy and Certification Practices
    Framework.* ftp://ftp.isi.edu/in-notes/rfc2527.txt

[^50]: The Burton Group, Jul 1997, *Network Strategy Report -- Public
    Key Infrastructure Architecture*.
    <http://www.tbg.com/samples/netsvcs/pkiarc.htm>

[^51]: Rutrell Yasin, 25 Jan 1999, Internet Week Issue 749, Section:
    News & Analysis, *Vendors Adding to PKI Interoperability.*
    <http://www.techweb.com/se/directlink.cgi?INW19990125S0025>

    Rutrell Yasin, 18 Jan 1999, Internet Week Issue 748, Section: News &
    Analysis, *PKI Heads for Mainstream.*
    <http://www.techweb.com/se/directlink.cgi?INW19990118S0003>

[^52]: http://www.ietf.org/rfc/rfc2527.txt?number=2527

[^53]: http://csrc.nist.gov/pki/fbca/welcome.html

[^54]: http://www.govonline.gov.au/projects/publickey/gac.htm

[^55]: IETF-PKIX Working Group, Jan 1999, *Internet X.509 Public Key
    Infrastructure Certificate and CRL Profile*.
    ftp://ftp.isi.edu/in-notes/rfc2459.txt

[^56]: http://portal.etsi.org/sec/el-sign.asp#TR 102 030

[^57]: This section is based upon a study performed by DOMUS Security
    for the Canadian Department of Industry (Industry Canada). Industry
    Canada and LGS Group, 1999. All rights reserved.

[^58]: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-new-rfc2527-01.txt

[^59]: http://www.apectelwg.org/apecdata/telwg/23tel/estg/estg_03.doc

[^60]: http://www.apectelwg.org/apecdata/telwg/24tel/estg/ESTG_16.doc

[^61]: <http://www.apectelwg.org/apecdata/telwg/24tel/estg/ESTG_21.ppt>

[^62]: <http://www.apectelwg.org/apecdata/telwg/25tel/estg/estg05.ppt>

[^63]: <http://www.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-08.txt>

[^64]: <http://www.techweb.com/se/directlink.cgi?IWK19990315S0040>

[^65]: http://web.mit.edu/kerberos/www/

[^66]: National Security Telecommunications and Information Systems
    Security Instruction (NSTISSI)

    No. 4009, *National Information Systems Security (INFOSEC)
    Glossary*,
    http://constitution.ncsc.mil/wws/nstissc/assets/pdf/4009.pdf January
    1999

[^67]: M. Abrams, S. Jajodia, and H. Podell, eds, *Information
    Security - An Integrated Collection of Essays*, IEEE Computer
    Society Press, January1995 referenced at
    http://www.isse.gmu.edu:80/\~csis/glossary/merged_glossary.html.

[^68]: See 'Security Area' at
    http://www.ietf.org/html.charters/wg-dir.html

[^69]: Descriptions of Kerberos realms and cross realm authentication
    can be found in J.G. Steiner, C. Neuman, J.I. Schiller; *Kerberos:
    An Authentication Sever for Open Network Systems*;\
    ftp://athena-dist.mit.edu/pub/kerberos/doc/usenix.PS

[^70]: National Security Institute, *Selecting Good Passwords*,
    http://nsi.org/Library/Compsec/goodpass.html

[^71]: National Institute of Standards and Technology, *FIPS 112 ,
    Password Usage*, http://csrc.nist.gov/fips/

    National Institute of Standards and Technology, *Internet Security
    Policy: A Technical Guide \[Draft}*,
    http://csrc.nist.gov/isptg/html/ISPTG-5.html#Heading40

    Defence Signals Directorate, *Password Management*, Australian
    Communications-Electronic Security Instructions (ACSI) 33, Section
    15, Annex B, http://www.dsd.gov.au/infosec/acsi33/15annexa.html

    Siemens Communications Limited, *Fraud Management Guide*,
    http://www.siemenscomms.co.uk/useful_information/telecom_guides/fraud/part22.htm

[^72]: The Task Group would like to express its appreciation to Jennifer
    Seberry, Centre for Computer Security Research, University of
    Wollongong; Chris Charnes, Department of Computer Science,
    University of Melbourne and Josef Pieprzyk, Centre for Computer
    Security Research, University of Wollongong for their work in
    drafting this Appendix*.*

[^73]: Association for Biometrics website
    <http://www.afb.org.uk/downloads/glossuk2.pdf>

[^74]: A number of the technologies and terminologies are discussed at
    <http://www.afb.org.uk/downloads/glossuk2.pdf>

[^75]: These terms are defined on the Association for Biometrics website
    http://www.afb.org.uk/public/glossuk1.html

[^76]: These terms are defined on the Association for Biometrics website
    http://www.afb.org.uk/public/glossuk1.html

[^77]: <http://www.biometrics.org/html/standards.html>

[^78]: <http://www.cesg.gov.uk/technology/biometrics>

[^79]: Directive 1999/93/EC of the European Parliament and of the
    Council of 13 December 1999 on a Community framework for electronic
    signatures OJ No L 13 p.12 19/1/2000,
    <http://www.qlinks.net/comdocs/elsig/en.pdf>

[^80]: http://www.apectelwg.org/apec/are/telminsub02.html

[^81]: *PKI Note: Smart Cards*,
    http://www.pkiforum.org/pdfs/smartcard-two_color.pdf

[^82]: *PKI Note: Biometrics*,
    http://www.pkiforum.org/pdfs/biometricsweb.pdf

[^83]: The Task Group would like to express its appreciation to Bob
    Stevens, Communications Security Establishment, Canada for his work
    in drafting this Annex)

[^84]: These lists, generally known as certificate revocation lists, are
    discussed in more detail in Chapter 2.

[^85]: http://rechten.kub.nl/simone/ds-lawsu.htm

[^86]: http://www.uncitral.org/english/texts/electcom/ml-ecomm.htm

[^87]: <http://www.uncitral.org/english/texts/electcom/ml-elecsig-e.pdf>

[^88]: http://www.hcch.net/e/workprog/e-comm.html

[^89]: http://europa.eu.int/smartapi/cgi/sga_doc?smartapi!celexapi!prod!CELEXnumdoc&lg=EN&numdoc=31999L0093&model=guichett

[^90]: http://www.ietf.org/rfc/rfc3039.txt?number=3039

[^91]: http://www.ict.etsi.fr/eessi/eessi-homepage.htm

[^92]: http://www.pkiforum.org

[^93]: http://www.ietf.org/html.charters/pkix-charter.html

[^94]: http://www.ict.etsi.fr/eessi/eessi-homepage.htm

[^95]: Asia Pacific Economic Cooperation, Telecommunications Working
    Group, Business Facilitation Steering Group, *Public Key
    Authentication Task Group Preliminary Report,* September 1997,\
    http://www.apecsec.org.sg/telewg/16tel/bfsg/matrix/TELEWG-BFSG-3e-2.html

[^96]: Australasia is a term for Australia and New Zealand

[^97]: PKI Forum Technical Work Group, *CA-CA Interoperability Project
    Discussion Paper,* http://www.pkiforum.org/pdfs/ca-ca_interop.pdf

[^98]: <http://www.govonline.gov.au/projects/publickey/gac.htm>

[^99]: Internet Engineering Task Force, PKIX Working Group. *Delegated
    Path Validation and Delegated Path Discovery Protocols*;
    <http://www.imc.org/draft-ietf-pkix-dpv-dpd>

[^100]: Internet Engineering Task Force, PKIX Working Group. *Online
    Certificate Status Protocol, version 2,*
    http://www.imc.org/draft-ietf-pkix-ocspv2

[^101]: Internet Engineering Task Force, PKIX Working Group. *Simple
    Certificate Validation Protocol,*
    <http://www.imc.org/draft-ietf-pkix-scvp>

[^102]: http://portal.etsi.org/sec/el-sign.asp#TR 102 030

[^103]: Organisation for Economic Co-operation and Development,
    *Guidelines for Consumer Protection in the Context of Electronic
    Commerce*, 9 December 1999,
    http://www.oecd.org/dsti/sti/it/consumer/prod/CPGuidelines_final.pdf

[^104]: <http://www.oecd.org/EN/about_further_page/0,,EN-about_further_page-43-nodirectorate-no-no--13-no-no-1,00.html>

[^105]: <http://europa.eu.int/smartapi/cgi/sga_doc?smartapi!celexapi!prod!CELEXnumdoc&lg=EN&numdoc=31995L0046&model=guichett>

[^106]: <http://cs3-hq.oecd.org/scripts/pwv3/pwhome.htm> .

[^107]: <http://www.anu.edu.au/people/Roger.Clarke/DV/DigSig.html>

[^108]: <http://www.privacy.gov.au/publications/pki.doc>

[^109]: <http://www.epic.org/privacy/biometrics/>

[^110]: <http://www.privacy.gov.au/news/speeches/sp80notes.doc>