<cite>OII Standards and Specifications List</cite>


I*M Europe
OII Home Page
What is OII?
Standards List
OII Guides
OII Fora List
Conference Reports
Monthly Reports
EC Reports
Whats New?
OII Index
OII FAQ
OII Feedback
Disclaimer
Search Database

OII Guide to Trust Services

This guide examines trust services from the perspective of open information interchange. It has the following structure:

  1. A System of Trust
  2. Trusted Third Parties
  3. The Building Blocks of Trust

This guide should be read in conjunction with the OII Guide to Information Security, which provides further information on the guidelines, criteria and technical building blocks for the management and use of trusted third party services, as well as guidelines on the management of information security in general.

In researching this guide, acknowledgement is given to the following:

  • "Standardisation issues for the European Trusted Services (ETS)" produced for the European Commission by Mr Andrew Colleran of Quercus Information Limited, UK
  • "TTPs Overview -- Concepts and Review of the State of Art from a Technical Point of View" produced for the European Commission ACTS Programme Seminar on Commercial Use of TTPs in Telecommunications, November 1996, by Dr Peter Landrock of Cryptomathic, Denmark.

1. A System of Trust

A System of Trust is an environment whereby entities (Administrations, Businesses, Consumers) may trade or transact with each other with the confidence that all entities are who they claim to be, conduct business in accordance with their functional obligations, and in which all exchanges between parties are secure.

It should be noted that 'security' is a subjective term, but may be defined as an acceptable balance of threats against safeguards for a particular circumstance. Central to a system of trust is an acceptable level of security for a given task or activity. Further information is provided in the OII Guide to Information Security.

In open information interchange, and particularly in the context of Electronic Commerce, a trusted system typically involves the presence of one or more third parties who act as an intermediary between the main transacting entities. Such intermediaries may change the value of the transaction by altering or adding to it (e.g. a goods forwarding agent). Alternatively, they may provide information/support services which do not fundamentally alter the value of the transaction itself (e.g. electronic catalogue hosting). These intermediaries are termed 'Trusted Third Parties' or 'TTPs'; they collectively provide the 'System of Trust'.

TTPs are widespread and divergent. They are present in the traditional trading environments, for example, a bank as a TTP between a buyer and a seller; or in less apparent environments, for example, a security alarm company as a TTP between a household and the police. Within the context of an electronic open information interchange environment, the status and implementation of a system of trust and the use of TTPs are of considerable interest and importance. Two features highlight the importance of the role of TTPs:

  • Electronic Commerce has brought new business models and practices to the trading environment and user confidence is required for the new electronic systems. TTPs can significantly enhance confidence in these systems
  • The global and virtual nature of Electronic Commerce means that buyers and sellers often do not, and need not, have any physical contact or direct knowledge of each other. TTPs can be used to provide such a link.

As well as the confidence in the management of the infrastructure of a trusted environment, users would need to be satisfied that there is an adequate technical environment available so that the transactions within that environment can themselves be trusted.

Moreover, in the context of open information interchange, users would need to know more about the content so that they can decide whether or not to retrieve an information object or who is associated with an object that is provided. If the information object is a report, who has reviewed the report and given it a "seal of approval"? Does the information really originate from the claimed author? If the information object is a software program, who has checked it to see that it does what it claims to do and does not contain any viruses? What computing resource does it need? What support is available for it?

Users therefore require information about the information ("meta-information") so that they can reach conclusions about trusting what is provided via open networks such as the Internet. Underpinning trust services is a Common Trust Management Environment. The main aspects of this environment are:

2. Trusted Third Parties

2.1 Overview

Trusted Third Parties (TTPs) offer a vehicle by which an entity can deliver assurances between its subdivisions, between itself and its customers, and between itself and its correspondent institutions. An institution may choose to set up an internal TTP function or use an external provider of TTP services. The provision of TTP function/services includes the provision of guidance for designing and implementing a TTP, management and operation of the TTP, and the interworking of TTPs.

Entities that intend to use TTP services should consider the following aspects of trusted services, which are particularly important for most communities:

  • Generic security requirements of TTPs
  • Establishment of a security policy
  • Provision of security solutions and mechanisms
  • Operational use and management of TTP service security
  • Responsibilities of TTPs
  • Services levels which TTP's can provide
  • Interworking constraints/rules of TTPs
  • The roles, positions and relationships of TTPs and other related entities (e.g. network service providers, end users, etc.)

These can be categorised and are addressed in the following subsections.

2.2 Management and Operation

A TTP function, whether internally or externally provided, can only add value when the users of the services are assured of the quality of the TTP function. Before contracting with a provider or starting operation of an internal system, the entity must satisfy itself that the following issues are addressed (these issues are often known as assurances):

  • Trust: Is the TTP organised, controlled and regulated in such a way that its operation can be relied upon, checked and verified?
  • Accreditation: Is the TTP accredited by recognized national, regional, or international groups?
  • Quality of service: For example, when is the TTP service available? What is the minimal level of service offered?
  • Audit and accountability: Are the quality of service criteria being met? How is this independently proven? To whom is the TTP accountable if the criteria are not met?
  • Compliance: Is the TTP operating in compliance with accepted industry standards and all relevant regulation?
  • Contract: Is there a legally binding contract in place covering the provision of service and addressing all the relevant issues? Are there contracts with co-operating TTPs that also address these concerns?
  • Liability: Is there a clear understanding as to issues of liability? Under what circumstances is the TTP liable for damages? Does the TTP have sufficient resources or insurance to meet its potential liabilities?
  • Policy Statement: Does the TTP have a security policy covering technical, administrative, procedural and organizational requirements?
  • Confidentiality: How is the confidentiality of information ensured?

Standards and Specifications
There are no specific standards within this area. The following generic architecture specifications are, however, of relevance:

2.3 Network of TTPs

The electronic TTP concept is relatively new and a network of co-operating TTPs must be developed before the full potential of TTPs will be realised. This network must be developed whilst ensuring that TTPs can independently maintain their assurances. The fact that competition between TTPs suppliers may reduce costs at the expense of offering reduced levels of service must be balanced against the fact that there should be open competition of TTP suppliers to ensure free market principles. This is most often addressed, as it is with other service industries (e.g. banks), via the availability of supervisory or licensing authorities.

It is of paramount importance to preserve confidence to all parties dealing with TTPs. The two principles for such a network are a dichotomy:

2.3.1 Co-operation guidelines

In order to support a network of Trusted Services, individual services have to make mutual recognition agreements with each other about, for example, cross certification of each other's certificates and mutual liability with respect both to the services offered and the holding of, or access to, related keys. These mutual agreements are much easier and more effective if there are generally agreed codes of practice and management guidelines for the operation of trusted services. Accreditation of trusted services promotes development and acceptance of the services. Agreements then have to be made between service providers and users about their mutual responsibilities and liabilities concerning the services offered and the cryptographic keys associated with them.

Standards and Specifications

  • ISO/IEC 14516: Guidelines for the use and management of Trusted Third Parties. (Part 1, General Overview. Part 2, Technical aspects)
2.3.2 Separating trusted networks

With networks being joined together in a web of trust, it is prudent for organizations to protect their networks from the external world with respect to security threats such as hackers and, to an extent, viruses. This is particularly apparent in a web that joins enterprise networks with uncontrolled, open networks such as the Internet.

'Firewalls' are the term given to devices (hardware and/or software) whose purpose is to establish such safe connections by standing between elements of a network system. A firewall is a collection of components that controls the traffic flow between networks, generally based on content, request or origin. Such a system may permit or deny network traffic according to an organization's defined security policy on which traffic should be permitted and which should be blocked. Firewalls can solve all security problems, for example, 'inside' jobs or application level issues. Basic security issues include: can a malicious client:

  • Get access to sensitive data
  • Trick the server to perform illegal operations
  • Trick a programme to perform illegal operations
  • Upload and execute an external program.

There are two different approaches to build a firewall: advanced packet screen/filtering works at the network level and application level gateways, usually defined as proxy. The most efficient firewalls are based on combinations of both.

Standards and Specifications

  • RFC 1928 (IETF): SOCKS Protocol Version 5. Security of messages passed across firewalls
  • RFC 1929 (IETF): Username/Password Authentication for SOCKS V5. Security of messages passed across firewalls
  • IEEE 802.10 Interoperable LAN Security (SILS). Security of local, wide and metropolitan area networks.

See Firewalls and System Security in the Information Security Standards section of the OII Standards and Specifications List for further information.

2.4 Basic Obligations

There are a number of legal issues that are of special concern in connection to TTPs:

  • Archival and retrieval: The level of requirements for record retrieval. The contract with a TTP should be specific about issues relating to maintenance of keys used for encryption, authentication, and digital signatures, as these may need to be reproduced many years after the transactions for which they were used.
  • Liability: Liability for the misfeasance, malfeasance, or non-feasance ('feasance' being condition or obligation) of the TTP to include direct and consequential damages must also be fully understood and agreed upon. The TTP must have adequate financial reserves or insurance to meet any liability.
  • Privacy: Institutions in many jurisdictions, particularly those relating to financial or ethical professions, are obliged to protect the privacy rights of individuals, especially safeguarding personal data. These obligations are sometimes at odds with the requirement of law enforcement to access information. The contract with an external TTP, or the operating procedures of an internal TTP must address both these concerns.

See section 3.5 for a wider discussion on privacy practices and agreement.

Standards and Specifications
See section 3.5 for specifications in the privacy area.

2.5 Basic Services

The basic services of a TTP are: generation of cryptographic material, key escrow, key distribution, key revocation, certification, directory, authentication etc. Often these are enveloped into what is termed a 'Public Key Infrastructure'. They are discussed in detail in the Key Infrastructure section of the OII Guide to Information Security.

2.6 Supplementary Services

2.6.1 Overview

There are many additional services that can be offered in a TTP network. These are termed 'Supplementary', 'End' or 'Ancillary' services. As the Electronic Commerce age develops, it is highly likely that the list of example services (see below) will grow significantly. Some of the more major/apparent activities are described within the following subsections:

  • Archive: The deposit of information
  • Timestamping: Providing evidentiary time stamps to records or transactions
  • Non-repudiation: Ensuring evidence of transmission or origination
  • Entity authentication: Ensuring the correctness of the entities involved
  • Notary: The attestation that something has been done
  • Audit: The recording of some action
  • Reliability assessment: An entity advising others who receive digital signatures about the reasonableness of reliance on those digital signatures
  • Message corroboration service: A person who creates a hash result to fix the message content and then timestamps the message and/or hash result. Message corroboration relates only to message content and timing and does not include a digital signature, so it provides no evidence of the origin of the message
  • Information brokering: An intermediary in the relationship between the user of information and the provider
  • Payment and billing: Taking payment from users of information and other electronically distributed goods on behalf of providers, for example a copyright use and billing service
  • Financial responsibility service: A person aiding a certification authority in satisfying the financial responsibility requirements. Such a person could be a surety issuing a bond, a bank issuing a letter of credit or a liability insurance carrier.
  • Registration services: Holding information about the attributes of a person or legal entity; this service can also be seen as a support service to a service such as access control
  • Directory services: Providing information about persons or legal entities so that they can be contacted or their certificates can be located
  • Electronic messaging -- e.g. via Value Added Networks.

In general, for each service, codes of practice and guidelines as well as technical specifications are required to enable providers to define the service, its quality, the agreements to be made by providers of the service with other providers, and the agreements to be made by users of the service with the providers.

2.6.2 Archive services

Record keeping is required for a certification authority, repository and users of trust services. The records may be kept off-line for backup purposes, for occasional reference, for risk management, or for any other legal purpose. An archive service differs from a repository in that the archive needs not be readily accessible on-line, but should be durable in light of available technology. Retention needs and duration will vary depending on the requirements or standards established by applicable law, records retention and other management policies. Archived records besides certificates may be needed in dispute resolution to support the certification authorities identification of the subscriber, other representations in the certificate, or possibly the basis for revoking the certificate.

Standards and Specifications
There are no known specific standards in this field.

For general information on archiving, see the OII Guide to Archiving.

2.6.3 Timestamping services

Often it is necessary to timestamp a transaction since the message may be time critical (e.g. proof of transmission date) or may be useful if problems are generated later in the business cycle. For example, if the certificate of a public key is cancelled on the grounds that the corresponding secret key has been compromised, a previously calculated digital signature by the said secret key would retain its legal value, if an independent timestamping service had taken place before the cancellation of the certificate. The user simply collects any number of digital signatures over a period of time (e.g. one day, one month, ...) and sends it off to a TTP for timestamping. The TTP adds the timestamp and a digital signature and returns the message.

Standards and Specifications
An Internet Draft in the Internet X.509 series, Public Key Infrastructure Time Stamp Protocols, is currently being reviewed by the IETFPublic-Key Infrastructure (X.509) (pkix) working group

2.6.4 Non-repudiation services

The purpose of non-repudiation services is to collect, maintain, make available and validate irrefutable evidence. They are based on mechanisms providing evidence generated by non-repudiation certificates using symmetric or asymmetric cryptographic techniques. A clearly defined security policy for a particular application and its legal environment is a pre-requisite for a non-repudiation service. Non-repudiation certificates establish accountability of information about a particular event or action to its originating entity. Non-repudiation mechanisms are specified to establish the following:

  • Non-repudiation of origin
  • Non-repudiation of delivery
  • Non-repudiation of submission
  • Non-repudiation of transport.

The mechanisms typically consist of non-repudiation certificates, non-repudiation tokens, and protocols. Non-repudiation certificates require a TTP as an evidence generating authority when symmetric cryptographic algorithms are used. When asymmetric cryptographic algorithms are used, digital signatures of the data communicated are assured by public key certificates issued by a certification authority. Non-repudiation tokens consist of one or more non-repudiation certificates and, optionally, additional data. Non-repudiation tokens may be stored as evidence that may be used later on by disputing parties or by an adjudicator to arbitrate disputes. Non-repudiation protocols specify the exchange of non-repudiation tokens specific for each non-repudiation service.

Symmetric techniques rely on the existence of a mutually trusted TTP. The ISO non-repudiation standard describes two mechanisms, one of which requires that the TTP is on-line for the generation and verification of evidence. The other mechanism has distribution of keys before the event for which evidence is required and so the TTP can be off-line.

Asymmetric techniques describe non-repudiation mechanisms using digital signatures. A TTP is required to support some of the mechanisms described to perform evidence generation, evidence transmission, evidence recording and evidence verification. Non-repudiation of origin and non-repudiation of delivery can be supported without the direct involvement of a TTP. They can also be provided with the use of a TTP, as must non-repudiation of submission and non-repudiation of transport. Mechanisms for supporting services such as obtaining public-key certificates and revocation information, as well as time stamping and evidence recording, are required.

Standards and Specifications

2.6.5 Entity authentication

The purpose of entity authentication is to corroborate that an entity is what it claims to be. Entity authentication mechanisms are based on the entity to be authenticated corroborating its identity by demonstrating its knowledge of a secret authentication key, which is used to encipher specific data. The enciphered data can be deciphered and its contents validated by anyone sharing the entity's secret authentication key. The claimant and verifier need to share a common secret authentication key, the establishment of which may involve a TTP. Some of the mechanisms can be used to establish mutual authentication, where both entities are authenticated; some can be used to authenticate one of the entities, unilateral authentication. The mechanisms specified can also be used in key distribution.

Entity authentication mechanisms are generally based upon public key algorithms including the use of symmetric encipherment algorithms and cryptographic check functions and a digital signature for the verification of the identity of an entity. The algorithm used is any that satisfies the requirements of the specified authentication mechanism.

The validity and authenticity of the public key are therefore most important. How such a key is securely obtained is outside the scope of this process. The public key could be obtained by using a certificate distributed by a TTP or by some other means mutually agreed by the entity and the verifier. Authentication may be both unilateral and mutual.

Entity authentication mechanisms are often designed around 'zero knowledge' classes of mechanisms are:

  • Identity based, where a trusted accreditation authority provides secret accreditation information which is a function of the claimant’s identity
  • Certificate based, where a claimant has a public, private key pair and the verifier a trusted copy of the claimant's public key -- this may be by using a certificate signed by a TTP).

The management of public key mechanisms is discussed in detail in the Key Infrastructure section of the OII Guide to Information Security.

Standards and Specifications

  • ISO/IEC 9798: Entity authentication (Part 1: General model; Part 2: Using symmetric encipherment algorithms; Part 3: Using a public key algorithm; Part 4: Using a cryptographic check function; Part 5: Using zero knowledge techniques)
  • ISO 9735: EDIFACT - Application level syntax rules (Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of origin); Part 6: Secure authentication and acknowledgement message (message type - AUTACK))
  • ISO/IEC 10181:1996 Information technology -- Open Systems Interconnection -- Security frameworks for open systems. (Part 2: Authentication framework)
  • FIPS PUB 196: Entity Authentication Using Public Key Cryptography

3. The Building Blocks of Trust

3.1 Overview

The building blocks of trust are technical building blocks which provide a common and interoperable basis for the system of trust.

As already discussed, central to a system of trust is an acceptable level of security for a given task or activity. Therefore, many of the technical building blocks of trust are security related. These are examined in the .

Additional building blocks of trust include:

3.2 APIs

APIs need to be available for a number of cryptographic service interfaces in support of trust services, including:

  • Public key delivery and verification interface
  • Certification Authority agent
  • Local registration authority
  • Publication of certificates and certificate revocation lists.

Standards and Specifications

3.3 Smart Cards

Standards are needed for trusted components such as smart cards which are required to support card related, secure commercial and financial transactions and payments. This needs to cover the use of all major currently available card technologies (e.g. magnetic stripe cards, integrated circuit cards) and applications (e.g. debit-credit, electronic purse). In addition, standard protocols for communication between a smartcard, executing security functions, and applications, including certificate management, are needed. Features which need to be addressed include:

  • Application protocols, interface devices and appropriate software requirements need to be defined to ensure implementation of the following functions and services in relation to customers, vendors and financial institutions
  • Recognition and authentication of all parties (e.g. customer, vendor, etc.)
  • Ordering (including but not limited to order form, placement of order by the customer and acceptance of the order by the vendor)
  • Agreement on the means of payment and related authorization to pay by the customer
  • Payment authorization (requested by the vendor to the financial institution)
  • Payment request and impact on settlement
  • The definition of a security architecture to provide appropriate integrity, confidentiality and anonymity.

Smart cards are particularly well suited to host security keys. This allows portability and mobile usage and provides some advantages in terms of security -- for example, it may be more difficult to steal a card rather then break into a computer. For added security smart cards can also deploy PIN techniques either through the reading device or, better, through an embedded key pad actually on the smart card itself.

Standards and Specifications

Relevant on-going activities

  • CEN TC224 is working with ISO TC68 on a study of the standards required to support card related, secure, commercial and financial transactions and related payments on open networks regardless of amount.
  • Industry fora, such as the Java Card Forum, are developing APIs for smart cards.

3.4 Labelling

The precise content of information which is exchanged between parties is often unknown in advance. Thus, even if a recipient is assured of the source and the delivery through specific TTP mechanisms, the final content may be unwanted. Labelling is a means of describing what is in the content associated with the label without users having to open the container to examine the contents. The key to a labelling system is the kind of data provided in the label and what the data in the label actually says. Both are crucial for identifying the content to the user and to enable the user to decide whether he wishes to go a step further: to open the container and access the content. In addition, rating and filtering, as specific applications of labelling, are processes which would enhance the provisioning of trust services.

See OII Guide to Labelling, Rating and Filtering for further information.

Standards and Specifications

  • W3C PICS (Platform for Internet Content Selection)

Relevant on-going activities

3.5 Privacy Practices

Internet users are concerned about the privacy of information they supply to Web sites. This includes personal information as well as information that Web sites may derive by tracking their online activities. Many online privacy concerns arise because it is difficult for users to obtain information about actual Web site information practices. Few Web sites post privacy policies; when they are posted users do not always find them trustworthy or understandable. Thus, there is often a one-way mirror effect: Web sites ask users to provide personal information, but users have little knowledge about how their information will be used. This lack of knowledge leads to confusion and mistrust.

Technical mechanisms could enable users to exercise preferences over Web sites' privacy practices, by enabling users to be informed about Web site practices, delegate decisions to their computer agent when they wish, and tailor relationships with specific sites. Thus, a framework for technical mechanisms which ensures that information relating to the user is released only under an acceptable agreement (reached through "negotiations" between the user agent and the Website concerned) would enhance trust: by giving the user choices and control over privacy preferences.

Standards and Specifications
W3C Platform for Privacy Preferences (P3P1.0) Specification



Section Contents
OII Home Page
OII Index
OII Help

This information set on OII standards is maintained by Martin Bryan of The SGML Centre and Man-Sze Li of IC Focus on behalf of European Commission DGXIII/E.

File last updated: September 1999

Home - Gate - Back - Top - Trust - Relevant