Office of the Federal Privacy Commissioner

The Internet and other electronic means of communicating provide many opportunities. However, there are challenges to be met, including the need to think carefully about privacy where online interactions replace traditional face-to-face or paper based interactions. These challenges include:

the potential for more information to be collected in more circumstances, which is a concern if aggregation of data occurs;
the confidentiality of transmissions; and
in some cases, the need to authenticate transacting parties.

Public Key Technology (PKT) can deal with some of these issues, and can enhance privacy. However, mis-use of the technology has its own associated privacy risks.

The Commonwealth Government has developed a Public Key Infrastructure (PKI) known as Gatekeeper to facilitate e-commerce and the take up of online delivery of government services in Australia. Gatekeeper is the Commonwealth’s Strategy for the use of PKI in government, and includes a number of stringent privacy protections.

The National Office for the Information Economy (NOIE), as the agency responsible for managing Gatekeeper, has invited the Federal Privacy Commissioner to consider issuing guidelines on the privacy implications and good practices for Commonwealth agencies (herein ‘agencies’) using PKI for individuals.

Possible Privacy Guidelines

The Privacy Commissioner sees this as an important issue and critical to building confidence in online government services. This technology can be used to enhance individual privacy. However, in the wrong circumstances PKI could compromise privacy.

Agencies have been mandated to use Gatekeeper when they commission PKI services. The use of PKI by agencies is subject to the Privacy Act 1988 (the ‘Act’) as well as a number of stringent privacy protections imposed on PKI service providers that have achieved Gatekeeper accreditation (which consist of the Information Privacy Principles (IPPs) and other requirements) but there may be more specific or additional measures that agencies, and the Gatekeeper framework, might adopt.

The Office of the Federal Privacy Commissioner (OFPC) has prepared this Paper to assist it to consult widely on privacy issues raised by agency use of PKI for individuals. In particular, the OFPC is interested in hearing views on:

whether there is a need for privacy guidelines addressing the use of PKI for individuals by agencies in their dealings with members of the public; and
if guidelines are needed, whether the draft guidelines proposed in the Paper are appropriate.

The OFPC is interested in receiving submissions on the issues raised in this Paper. Details on how to make submissions are listed on page 5 of this Paper. The OFPC will consider all the submissions, and if appropriate, will recommend to the Privacy Commissioner that he issue guidelines, under section 27.1(e) of the Act. This provision allows the Privacy Commissioner to:

"... prepare, and to publish in such manner as the Commissioner considers appropriate, guidelines for the avoidance of acts or practices of an agency that may or might be interferences with the privacy of individuals or which may or might may otherwise have any adverse effects on the privacy of individuals..."

Consultation and Process to develop guidelines

The Privacy Commissioner seeks to ensure that his consideration of privacy issues is well informed and based on wide consultation. He invited key stakeholders including consumer representatives, agencies and industry representatives to form a reference group for this project. The Reference Group has assisted in defining the scope of the project, identifying priority issues to be addressed, and suggesting possible guidelines. It has also made suggestions about who should be consulted. A list of members of the Reference Group is at Appendix 7

The Reference Group met twice during the development of this Paper and will meet again in late July 2001 to consider the results of the public consultation.

In addition, the OFPC has had a series of meetings with agencies that have indicated an interest in using PKI in online service delivery for individuals. The results of these meetings are outlined in Appendix 2 of this Paper.

NOIE has also collaborated closely on the Project, both as the manager of Gatekeeper and because of its general brief to facilitate the take up of online government services in Australia.

The Privacy Commissioner welcomes the involvement and the support of NOIE as it will be critical that any guidelines issued by the Privacy Commissioner complement Gatekeeper and are compatible with it.

Finally, the OFPC acknowledges the assistance of the consultants, Galexia, who undertook the detailed research and provided the initial draft of this Paper, including the draft guidelines.

Scope of this project

There are three important points to note about the scope of this project.

Firstly, the Act protects personal information - that is information about individuals whose identity is apparent, or can reasonably be ascertained, from the information ^[1].

In general, the Act protects individuals in both private and business capacities. In other words, individuals:

in their private (non-business) capacity as subscribers, tax-payers and recipients of Government services and customers of agencies;
who are designated representatives of corporate entities; or
who are sole traders or partners involved in business activities.

This Paper will focus primarily on the first of these three categories. However, the issues identified may also be relevant for the individuals in the other two categories.

Secondly, privacy issues arise in relation to a number of aspects of PKI. Broadly these can be grouped as follows:

the application and registration processes for digital certificates;
the associated trust framework including public key directories and Certificate Revocation Lists; and
the use of digital certificates.

Although this Paper will discuss privacy issues in relation to all these aspects of PKI, the draft Guidelines will focus on issues raised by the third grouping. Note that agencies will only be involved in the first and second dot points above where they operate as a Certification Authority or Registration Authority or when they have a contract for service provision with either of these entities.

Thirdly, this Paper focuses on the use of PKI for individuals by agencies. This reflects the Privacy Commissioner’s current jurisdiction (the Privacy Commissioner’s function in relation to the private sector to commence on 21 December 2001) and the fact that there has been some focus on the privacy issues emerging in the government sector.

It is possible that, should the Privacy Commissioner decide to issue guidelines, they will also be relevant as good practice guidelines for private sector organisations using PKI for individuals. Before the Guidelines are issued, the Privacy Commissioner will ask the project Reference Group, NOIE and the National Electronic Authentication Council (NEAC) to consider this once the consultation process is finalized.

Implications for NOIE

PKI vendors are bound by specific Gatekeeper privacy related requirements. The Privacy Commissioner understands that NOIE will review those requirements in the light of the recommendations in this Paper, the outcome of the OFPC consultation process, and any guidelines that may be issued by the Privacy Commissioner.

Call for submissions

The Federal Privacy Commissioner invites stakeholders and any other interested parties to contribute by providing comments and suggestions on the need for privacy guidelines on the use of PKI by agencies and on the draft Guidelines in this consultation Paper. Some specific questions have been raised in the text following the draft Guidelines. Submissions may include suggestions for guidelines not already in the Paper.

There is no required format for submissions. These may be sent by e-mail to: consultation@privacy.gov.au

or mailed to

The Office of the Commonwealth Privacy Commissioner
GPO Box 2999
Canberra City ACT 2601

The closing date for submissions is – 27 July 2001

Collection statement - what we will do with your submission

This Office will use the submissions it receives for the purpose of preparing guidelines on use of PKI should the Privacy Commissioner decides these are appropriate. It may publish a list of those who made submissions and we may make submissions public and available to NOIE. If you wish your submission to be treated as confidential you should either write it on your submission or tell us at the time you make your submission.

Contact officer – Paul Bambury, Office of the Federal Privacy Commissioner
e-mail: paul.bambury@privacy.gov.au
Phone: 02 6247 3449

Chapter 1 – Privacy and Public Key Infrastructure – An Overview

1.1 The Scope of this Chapter

This chapter is intended to provide an overview of privacy, PKI and the privacy implications of PKI. It briefly describes the Privacy Commissioner’s jurisdiction, PKI and then discusses a number of privacy issues and the risks associated with PKI. The approach taken in relation to each of the risks is to:

briefly describe the context or activity in which the risk arises;
describe the risk;
what is in place to deal with the risk (Gatekeeper, Information Privacy Principles); and
what is left to do.

Chapter 2 then sets out draft Guidelines that aim to address the residual risk. The remainder of the Paper provides a detailed discussion of PKI, Gatekeeper and the associated privacy issues, the current privacy protections, and privacy impact assessments as one response mechanism for agencies.

1.2 What is Privacy?

Privacy is about protecting our sense of self – that is who we are, what we know, what we think, what we have done and what we want to do. One important aspect of this is the extent of control we have over personal information about us. Exercising choice about our own information can also be an important aspect of retaining personal dignity and humanity in a relationship with another party.

Privacy is not about protecting wrongdoing or encouraging secrecy. There is no absolute right to privacy. Society accepts that there are public interest reasons for particular limitations on individuals’ right to privacy. These include law enforcement, fraud control and public safety.

A certain amount of information sharing occurs in most relationships that individuals have with other people or organisations. As a consequence, there may be a reduction in control over that information because someone else holds it. The individual’s right to privacy sometimes must be balanced against a particular benefit that the individual receives from such relationships.

However, it is clear that privacy is an important issue for Australians. In the last few years privacy has become a vital issue in policy and regulatory debates. Privacy issues have emerged particularly in the context of increasing use of Information Technology, the Internet and developments in e-commerce.

The extent to which individuals will be prepared to divulge their personal information in online transactions will vary from person to person. PKI service providers and agencies should adequately inform them of the benefits and risks, including privacy aspects. It will be important for agency clients as potential PKI subscribers to be able to make informed choices about using PKI.

While there may be economic and technical limits to the extent to which agencies can offer their clients choice in respect to PKI, agency clients should be able to choose whether or not to participate on online transactions incorporating PKI. Agencies should avoid pressing their clients into using PKI. Agency clients should be given sufficient information to make an informed choice about whether to use a PKI system and how to protect their privacy and security should they choose to use it. Such freedom of choice is an essential element of any privacy framework.

1.3 The Privacy Act 1988 (the ‘Act’) – the Commonwealth Privacy Commissioner’s Jurisdiction

In Australia personal information held by most agencies is protected by the Act. The Act sets standards called the Information Privacy Principles (IPPs) for the collection, use and disclosure of personal information and for individuals to access and correct information about them. It also regulates the use of Tax File Numbers (TFN) whether held in the public or private sector and, since 1992, consumer credit reporting.

In December 2000, the Commonwealth Parliament passed legislation to amend the Act to extend privacy protection in the private sector. This legislation will come into effect on 21 December 2001 and sets similar information handling standards called the National Privacy Principles (NPPs) for private sector organisations. The Act also provides for organisations to administer their own privacy code. Privacy codes can replace the NPPs if they provide at least equivalent levels of privacy protection and are approved by the Privacy Commissioner. The Act does not apply to small businesses provided that they do not handle personal information for a benefit, service or advantage or handle health information.

The Act gives the Privacy Commissioner a range of functions including the investigation of complaints from individuals about possible breaches of privacy, the provision of advice to government and organisations about privacy matters and the issue of guidelines for good privacy practices.

More information about the Act and the Privacy Commissioner’s jurisdiction can be found at www.privacy.gov.au.

1.4 Public Key Technology (PKT)

PKT is a form of cryptography and relies on two keys - a public key and a private key. The subscriber must keep the private key secret. The public key can be made known to others and made publicly available. PKT provides four functions:

Authentication. The identity of a subscriber can be assured in online transactions by the subscriber "signing" an electronic communication with their private key. This authentication is performed by the application of the public key to the digital signature.
Integrity. Where a subscriber signs an electronic document a message digest or hash of the message is produced. If the hash value remains the same after the message has been received then the message integrity is assured. That is, the message hasn’t been altered in transit.
Non-repudiation. Where an electronic message is signed with a digital signature, the fact that it was signed with a particular key cannot be repudiated or denied. In practice, this means that messages will be non-repudiable unless it can be shown that the private key was applied by other than its unique and rightful holder.
Confidentiality. This is achieved by encrypting a message with a subscriber’s public key. The message can only be decrypted with the subscriber’s private key.

Depending on the design and application of the system, PKT can deliver some or all of these. For example, it may be used just to ensure the confidentiality of communications.

1.5 Public Key Infrastructure (PKI)

A PKI is a formal trust relationship, which is hierarchical in nature. Some forms of PKT such as Pretty Good Privacy (PGP) depend on a "web of trust". This is an informal trust relationship between PGP subscribers based on personal relationships and references. A PKI is arguably a more robust trust framework than a "web of trust". A detailed description of PKI is included in Chapter 3.

Most PKI’s incorporate bodies known as Registration Authorities (RAs) and Certification Authorities (CAs). RAs register the identity of an individual or entity by performing an Evidence of Identity (EOI) procedure. CAs then issue keys and certificates to those individuals or entities registered by the RA. PKI may also incorporate a policy setting body that establishes the rules and procedures for the trust hierarchy.

Other PKI components include Public Key Directories, where public key certificates are published and Certificate Revocation Lists (CRLs), which are published lists of certificates that have been revoked.

1.6 Digital Certificates

A digital certificate is an electronic document signed by a CA that associates a subscriber with a key pair. The certificate contains the subscriber’s public key and other information including the cryptographic algorithm supported, a serial number, and the distinguished name of the subscriber. The certificate is issued to the subscriber who is then able to use it for any or all of the four functions of PKT.

1.7 Gatekeeper

Gatekeeper is the Commonwealth Government’s Strategy for the policy and implementation of PKI in government, which is managed by NOIE. States and Territories have agreed in-principle to the adoption of the Gatekeeper Strategy. NOIE manages the accreditation of CAs and RAs and sets the accreditation criteria. The Gatekeeper Policy Advisory Committee (GPAC) includes representatives of the Commonwealth government, State and Territory governments, industry representatives and a privacy consultant. The GPAC advises NOIE on the policy framework for Gatekeeper.

The Gatekeeper accreditation process includes privacy requirements (Privacy Criteria 1-12), which implement all the IPPs (plus additional privacy requirements) as they apply to CAs and RAs. For the purposes of this Paper they are referred to as "Gatekeeper additional privacy requirements."

There are a number of privacy protections contained in:

Gatekeeper Head Agreements (which contractually binds Gatekeeper accredited CAs and RAs to the Gatekeeper accreditation criteria on an ongoing basis);
within the Gatekeeper accreditation criteria; and
a set of guidelines for privacy protection in this area (see Appendix 5) all of which contain privacy requirements on top of the IPPs.

NOIE has advised that it intends to review the existing Gatekeeper accreditation criteria in the event of the Privacy Commissioner issuing specific guidelines.

1.8 Privacy Implications of PKI

1.8.1 PKI can be privacy enhancing

While this Paper concentrates on identifying some of the privacy risks that emerge from PKI applications, these applications can also be privacy enhancing.

PKI applications can allow individuals to utilise a wide range of communication channels when dealing with agencies. Individuals who have privacy concerns about speaking to an agency via telephone (for example, in a shared household or at the workplace) can use e-mail or web based communication instead. The use of digital certificates also reduces the need to constantly provide primary EOI (such as a driver’s license) or answer questions about one’s date of birth, home address and so on in order to authenticate oneself.

PKI supports confidentiality of communications (encryption of messages). Individuals who are concerned about sending text messages to agencies would have the facility to encrypt their messages with the agency’s public key so that it can only be decrypted by the agency. Conversely, an individual could require the agency to encrypt any messages they send to the individual with their public key so that only they can decrypt it. This security of communications provided by PKI is certainly privacy enhancing.

These privacy benefits are additional to other consumer benefits offered by PKI, in particular, confidence that their message cannot be altered in transit and that they are in fact dealing with the party they intended.

1.8.2 The Role of NOIE and the OFPC

In the discussion that follows it is important to note that some PKI privacy issues by their nature relate only to the activities of CAs and RAs and are therefore the particular concern of NOIE as manager of the Gatekeeper policy and accreditation framework.

Where this Paper identifies such Gatekeeper related issues, these will be indicated as matters for consideration by NOIE. Other issues relate primarily to agencies in their design and implementation of PKI supported systems and applications. These will be the focus of any guidelines that the Privacy Commissioner might issue.

There are also certain situations where privacy implications stem from activities of both RAs/CAs and agencies, and which may therefore be managed both by NOIE and through the Commissioner’s guidelines. The relative roles of CAs/RAs and agencies in privacy sensitive PKI functions are outlined in the following sections that summarise the major areas of privacy sensitivity.

1.8.3 The Subscriber Registration Process

The issue of how much EOI should be expected before a digital certificate is issued to a subscriber, and how that is obtained, relates to both agencies and CAs/RAs. CAs must be able to give their subscribers (including agencies) confidence that digital certificates have in fact been issued to the correctly identified party (for example, agency subscribers).

An RA must collect EOI information from an individual in order for them to be issued with keys and a digital certificate by a CA. Under Gatekeeper, CAs sets identification levels, sometimes at the request of any agency that has commissioned them to issue digital certificates to their subscribers. Gatekeeper EOI levels are set at 50, 100 or 150 points by reference to the requirements, which operate under the Financial Transaction Reports Act 1988.

Concerns have been raised about the intrusive nature of the registration process where individuals may be required to attend an RA with their EOI documentation. There is also concern that a particular identification level selected might be unduly high and not warranted by the nature of the application. This is seen as more likely if a single digital certificate were used across multiple agencies or applications since it would require an identification level that represented the highest common factor.

In response to this concern, Gatekeeper Privacy Criterion 1 (PC 1) requires RAs to comply with IPPs 1-3, which include the requirement to collect only information for a lawful purpose "directly related to a function or activity of the collector". Gatekeeper accreditation guidelines "require a PKI design that ensures that individuals are only subjected to appropriate identification procedures to meet agency authentication requirements or to satisfy applicable law and that intrusive procedures are minimised to the greatest extent possible".

Agencies should carefully consider which level of EOI is appropriate to their application in order to assure that the personal information collected is necessary for or directly related to the application. Draft Guideline 3 expects agencies to require a level of identification that is sufficient, but not excessive for their business needs.

There will be benefits for agencies and their subscribers in accepting, as adequate for their own purposes, a Gatekeeper compliant identification process already obtained by their subscriber with another agency or RA. This would avoid the inconvenience and possible expense for subscribers of multiple identifications, but would require the client’s consent to allow the existing RA or CA to demonstrate that identity to the subsequent agency or its CA.

Note that Gatekeeper rules are designed to prevent the sharing of RA collected and stored identity and attribute information (for example, copies of identification documents or qualification / membership / eligibility documentation) with CAs or agencies, as this would lead to the centralised storage of personal data.

1.8.4 Public Key Certificates

Concerns have been raised in respect to the possible extent of personal information contained in certificates, which are normally publicly available, and that this may facilitate possible tracking of an individual’s transactions.

This is a matter for CAs as certificate issuers and for NOIE as Gatekeeper manager. Gatekeeper Privacy Criterion 1 requires CAs to comply with IPPs 1-3, in order to minimise the amount of personal information collected and made public. This is reflected in NOIE’s approved profile for digital certificates which only allows personal information in the ‘Distinguished Name’ field and which limits that field to a subscriber’s name or pseudonym.

1.8.5 Public Key Directories and Certificate Revocation Lists

Concerns have been raised about the possible browsing of these public directories, downloading bulk data from them or using them in other ways that may interfere with the privacy of individuals. A risk is that the downloading of digital certificates from a public key directory may reveal an association of an individual to a particular agency, and that associating the name with the digital certificate’s serial number may allow tracking of a pattern of transactions.

In some implementations of PKI it may not be necessary for a public key directory to be published. If the relevant agency is itself a CA, or uses a CA to manage a closed PKI community exclusively for its purposes, the agency will have its own access to its clients’ public keys. In that event, there would be no reason for publishing the subscribers’ public keys.

Agencies should carefully consider whether their PKI applications require the publication of a public key directory. If publication is considered necessary then individual subscribers should be permitted to opt out of having their public keys listed in the directory. This is similar to the way telephone subscribers are permitted to opt out of having their phone number published in the phone directory, as are voters permitted to have their personal information suppressed on the electoral roll.

Gatekeeper Privacy Criterion 9 sets out specific requirements for CAs for CRLs and "other directory services" including Public Key Directories. This Criterion limits personal information published in CRLs and other directory services, and places limits on personal information collected, logged and disclosed.

Gatekeeper accreditation guidelines "require a PKI design that incorporates effective privacy controls over the information contained in CRLs and how CRLs are accessed and searched". This means for example that, while revocation of a certificate must be published in a CRL, the reasons for revocation or suspension must not be disclosed. Also, access to a Certificate Directory or CRL will generally be limited to single searches. In practice, NOIE requires CRLs and other public directories to be configured such that only one search can be made at a time and then only against a certificate serial number (not the Distinguished Name).

The Gatekeeper requirements for CAs can be reinforced by a guideline requiring those agencies, which commission CAs to issue certificates to their clients, to ensure that their digital certificates or revocations are not posted to a publicly available directory if a subscriber opts out (see draft Guideline 8).

1.8.6 Logs and ephemeral data

Servers hosting public key directories, CRLs and other PKI transactions and maintained by CAs and agencies, will normally keep logs of accesses and online transactions. Agencies would legitimately expect to maintain records of checks as non-repudiable evidence of their transactions.

Concerns have been raised about the possibility that CAs and agencies could use logs to track their transactions and then compile profiles of individuals using these services.

Gatekeeper Privacy Criterion 9 provides in part that -

RA/CAs shall collect and hold minimal personal information when logging accesses to CRLs or other directory services.
RA/CAs should not disclose personal information collected by logging access to CRLs or other directory services (except for designated law enforcement purposes).

Agency servers hosting PKI transactions with individuals will also log transactional data. Gatekeeper Privacy Criterion 9 will only apply to agencies if they are also an RA or a CA. Draft Guideline 9 proposes similar rules for agencies.

1.8.7 Access to Logs by Law Enforcement Agencies and under Legal Authority

Law enforcement agencies, government agencies exercising their statutory powers or other parties may become interested in personal data logged or collected in a PKI application, just as they might be interested in other information held or collected in other networks and systems.

There are three types of data that may be of interest:

Raw, encrypted data - this is simply the data as it is communicated. It may establish simply that a communication between two parties took place at a certain time or location (which may be of interest) without divulging any further details;
dentification data - this data may identify one or more individuals involved in a communication. As identification is part of many PKI applications, this type of data will be common; and
Decrypted data - this data may reveal the actual content of a communication. This may occur in a PKI application because some information has been sent in a decrypted form, or because the recipient has subsequently decrypted the information (or has the capacity to decrypt the information). This type of data is common to most PKI applications.

In respect to such data held by agencies IPPs 11.1: (d) provides for disclosures, which are required by or under law and IPP 11.1; and (e) for where disclosure is reasonably necessary for the enforcement of the criminal law or of a law imposing a pecuniary penalty or for the protection of the public revenue.

Gatekeeper Privacy Criteria 9 requires RA/CAs not to disclose personal information collected by logging access to CRLs or other directory services (except for designated law enforcement purposes).

1.8.8 Security of the Private Key

A major security concern relates to the security of the private key. The integrity of a PKI depends on the subscriber keeping the private key inaccessible to any other party.

Digital certificates and their corresponding key pairs can be stored in a number of ways - on dedicated tokens such as smart cards or directly on computer disk drives. Each storage method has a set of perceived benefits and deficiencies. The choice of particular storage solutions is a matter for individual agencies in planning their PKI implementation and for subscribers in reaching a conclusion about using a particular digital certificate. Gatekeeper does not specify particular storage devices, nor does it make any judgment on the merits of any particular storage method

Gatekeeper requirements on CAs to advise of security breaches and to post revocations on CRLs also play an important support role for securing the integrity of private keys.

Agencies could also play a useful role in educating subscribers as to the best way to protect their private key and also could influence CAs in their requirements for how private keys are generated and held. Draft Guideline 7 expects agencies to ensure that that their subscribers are aware of the relevant privacy and security risks. Draft Guideline 6, Subscriber Generation of Keys, is also relevant.

1.8.9 National Identifiers

Concerns have been raised that the use of digital certificates could lead to the development of a de facto national identifier. One of the purposes of these draft Guidelines is to ensure that PKI is not used to implement a national identification system. This may occur if one certificate for individuals came to be used across a wide range of agencies in a way thatenabled agencies with divergent interests to access personal information not intended for them.

At present, there is a significant body of Commonwealth legislation that seeks to ensure the confidentiality of tax, health and social security information about individuals. Consistent with a key overall objective of this legislation which is to avoid the creation of a national identifier, Gatekeeper Privacy Criterion 10 requires subscribers to be allowed more than one certificate from the same CA where this is not inconsistent with the purpose of the digital certificates and when dealing with multiple agencies. Draft Guidelines 1 and 5 seek to address this issue.

1.8.10 Function Creep

Function creep is a progressive accumulation of uses for an application or identifier. An example of function creep relates to the TFN which initially was to be used only for taxation purposes but which additionally came to be used for other purposes including the administration of the welfare system.

An example of this in the PKI setting may be the use of personal information collected for the EOI process for another purpose. It is difficult to predict what other forms of function creep may arise in a PKI.

Agencies need to be wary of any accumulation of additional uses for certificates or associated personal information.

1.8.11 User Choice

Guideline 2 of the OECD Guidelines for Cryptographic Policy applies to Choice of Cryptographic Methods, which provides that:

Users should have a right to choose any cryptographic method, subject to applicable law.

As a member of the OECD, Australia has agreed to these OECD Guidelines. Gatekeeper, in respect of CAs and RAs, supports this right.

In practice, many agencies and CAs will be limited to certain technology platforms, certificate types and key management systems. While all will be Gatekeeper compliant and meet prescribed security and privacy standards, not all may have features that some privacy-sensitive subscribers might prefer.

There should at least be choice over whether or not to transact using PKI. Draft Guideline 1 provides choice to individuals as to whether to use PKI applications and requires agencies to provide alternative means of service delivery.

1.8.12 Anonymity and Pseudonymity

Gatekeeper can support anonymous transactions. Although there has not been a demand for digital certificates of this type, Gatekeeper Criterion PC12 states that:

The CA shall have the ability to provide anonymous or pseudonymous certificates where appropriate.

Gatekeeper policy requires that "Gatekeeper requires a PKI design that enables individuals to:

choose to use any distinguished name in a certificate, except where it would be impractical to do so; and
conduct pseudonymous transactions except where the agency demonstrates that it is impractical to do so."

It is therefore possible for agencies, where appropriate, to issue digital certificates in any reasonable name the subscriber might choose and for the same person to have additional digital certificates issued with another pseudonym for use with another agency.

It is also likely there will be transactions facilitated by a PKI in which identification of the individual is not necessary. Where a PKI has been implemented to enable a range of online transactions some of which may require identification and some of which may not, then subscribers should be able to make the latter transactions without revealing their identity.

There may be scope for CAs to issue special purpose attribute certificates which simply represent the individual’s eligibility for a service without identifying them, however, at this point in time, an attribute certificate framework has not been developed by the relevant standards bodies and is not yet part of Gatekeeper. Draft Guideline 10 expects agencies to provide subscribers with pseudonymous or anonymous alternatives, where appropriate.

Agencies might also consider a secure online application, other than PKI, to allow individual subscribers to deal securely and anonymously with them.

Draft Guideline 10 expects agencies to provide subscribers with pseudonymous or anonymous alternatives, where appropriate.

Chapter 2 - Proposed Guidance for Agencies and PKI Service Providers

The discussion in Chapter 1 on the privacy implications of PKI and the use of digital certificates is the basis for the privacy guidelines proposed in this Chapter.

That discussion and the following draft Guidelines recognize the significant extent to which agencies and PKI service providers (CAs/RAs) are already obliged by the Act, and by contractual obligations with NOIE as Gatekeeper manager (which include to observe the IPPs).

This Chapter identifies a set of draft PKI-specific Guidelines for agencies considering the use of PKI to help them minimize any privacy risks for individuals. If appropriate, following further consultation with key stakeholder groups including agencies and an opportunity for public comment, the Privacy Commissioner may issue these as Guidelines under s.27.1 (e) of the Act.

Agencies must comply with the IPPs in the Act (and with other relevant legislation such as that applicable in the health, social security and taxation sectors), however, they will have discretion in how and the extent to which they would implement any guidelines. These draft Guidelines are intended to give a clear indication of the factors the Privacy Commissioner would consider if investigating a complaint about the use of PKI by an agency.

While there may be economic and technical limits to the extent that agencies can offer their clients choice in respect to PKI, clients should be able to choose whether or not to participate in online transactions (whether they involve PKI or not). It will be important for agency clients as potential PKI subscribers to be able to make informed choices about using PKI.

Agency clients should be given sufficient information to make an informed choice about whether to use a PKI system and how to protect their privacy and security should they choose to use it. Such freedom of choice is an essential element of any privacy framework.

Although PKI can be privacy enhancing it also carries privacy risks. These draft Guidelines aim to assist agencies and potential subscribers to make decisions to use PKI only after proper consideration of the issues and risks.

While the draft Guidelines focus on agencies, there are several instances where privacy sensitivities stem from the activities of other participants in the PKI, especially CAs and RAs. Where relevant, this is pointed out in the draft Guidelines. CAs and RAs are bound by specific Gatekeeper accreditation requirements for privacy and security. These draft Guidelines would apply, where relevant, to agencies who choose to commission a CA or RA to issue certificates on behalf of their subscribers as well as to agencies who choose to use or accept digital certificates.

Draft Guideline 1 – Agency Client Choice on the Use of PKI Applications

Guideline -
Agencies should allow their clients to choose whether to use PKI, and to offer them alternate means of service delivery. In providing this choice, agencies should advise their clients of the considerations associated with using PKI and the alternate methods.

Discussion

This Guideline will ensure that agency clients would have a choice over whether to use PKI for their online transactions. In many cases not using PKI may mean that the client cannot use the online application, as the risks to privacy through the use of less rigorous authentication and security arrangements may inhibit the use of alternate authentication. Arrangements will need to be developed to ensure that an ‘opt-in’ consent is obtained.

Advantages

Agency clients will have the choice of whether to use PKI.
Agency clients will have a choice of whether to use online or other services. This is consistent with the Government Online Strategy.

Disadvantage

Agency clients who choose not to use PKI may not be able to access a number of online services.

Issue for further discussion

Would it be possible for agencies to offer both PKI and alternate online authentication?

Draft Guideline 2 - Privacy Impact Assessments (PIAs)

Guideline -
Agencies should undertake a PIA before implementing any new PKI system or revising or extending an existing PKI system (including whether it is appropriate to use PKI). The PIA should also identify the privacy risks and who would bear them, the agency and/or the subscriber.

Discussion

Any decision to proceed with a new or revised PKI application should be based on a PIA. The PIA should identify possible risks, including who would bear these risks, the agencies, service providers or subscribers.

Conducting a PIA should assist agencies to identify and address privacy risks in the design stage of their projects. In any set of new arrangements between an agency and its clients, the allocation of risk between the parties needs to be fair and the PIA should be able to demonstrate this. Among other benefits, undertaking a PIA before extending a PKI application should reduce the risk of ‘function creep’ that could subsequently compromise individual privacy.

Agencies that are Gatekeeper accredited CAs or RAs, or who are seeking accreditation, are already required by Gatekeeper to produce an approved privacy plan. In these situations, especially where those plans have been developed in consultation with subscriber representatives, it may be that the issue that need to be considered in the PIA process will have been addressed in that planning process. The maintenance of Gatekeeper accreditation is subject to third party auditing including compliance with Gatekeeper approved privacy plans and other privacy requirements. However, it needs to be borne in mind that this Guideline is about agencies making decisions about the use and management of PKI with individual clients (rather than satisfying the Gatekeeper accreditation process). As a result, there may be additional issues to consider.

Agencies should incorporate a PIA into their risk management plan for new or revised PKI projects. PIAs are further discussed in detail in Appendix 1.

Advantages

The effective use of PIAs should be cheaper than rectifying privacy problems after an application has been implemented.
The use of PIAs ensures that less privacy intrusive options in applications are considered by the agency.
The PIA should identify circumstances where risks of using PKI may be borne by the subscriber.

Disadvantages

The requirement to conduct PIAs may be considered as a possible implementation hurdle by agencies considering PKI applications.
PIAs may be repetitive and/or unnecessary in some cases, especially where the privacy risks are low or similar applications have been successfully implemented elsewhere (although in such cases an agency should readily gain recognition of its existing privacy achievements).

Issues for further discussion

What form should a PIA take? Can agencies readily and effectively incorporate the essence of a PIA into their risk management plans for new or revised PKI projects?
Should agencies be expected or encouraged to publicise a PIA? If yes, at what stage during the design, building or operation of the PKI application should the PIA be the subject of consultation and/or published?
What should the consequences of a poor result in a PIA be for agencies?
Should the draft Guidelines expect agencies to abandon PKI applications that ‘fail’ the PIA or, if appropriate, redesign such applications?

Draft Guideline 3 - Identification of Agency Subscribers

Guideline -
Agencies should only require a level of identification of their subscribers that is sufficient for, but not in excess of, their business requirements. Agencies should also consider the benefits of allowing one EOI process to be used for the issue of multiple certificates.

Discussion

The registration process where individuals may be required to attend an RA with their EOI documentation may be intrusive to some individuals. The solution may be to allow one EOI process to be used for multiple certificates. This may reduce the amount of information that is required to be gathered from individuals.

However, there is also concern that a particular identification level might be unduly high and not warranted by the nature of the application. Gatekeeper individual certificates are designed to allow a CA or an agency to specify either 50, 100 or 150-point checks (using the framework in the Financial Transaction Reports Act (Cth) 1988).

Advantages

This Guideline is consistent with IPP 1 and Gatekeeper additional privacy requirements that limit the collection of personal information that is necessary for or directly related to the purpose of collection.
The operation of this Guideline would avoid the inconvenience and possible expense for both agencies and subscribers of multiple identifications.

Disadvantage

This Guideline could lead to the use of EOI information for other purposes, unless the subscriber explicitly consented to allowing an existing identification to be used to satisfy a subsequent CA.

Issues for further discussion

Should a 100-point level of identification be regarded as sufficient for most agencies?
Should an appropriate level be left entirely to each agency assessing their particular business needs?
What precautions and consent procedures should an agency take in respect to any re-use of a single EOI process?

Draft Guideline 4 – Aggregation of Personal Information

Guideline -
Agencies should not engage in aggregation of personal information obtained through PKI applications (including the tracking of transactions undertaken which could be used to build a profile of a subscriber).

Discussion

PKI applications could potentially collect ephemeral data about the subscriber, including transaction data, eligibility and their relationship with agencies. It would be possible to build detailed profiles about the subscriber by using this information.

Advantages

Aggregation of personal information, including information able to be collected using a PKI application, is perhaps the major underlying potential privacy risk for subscribers of agencies.
This Guideline will ensure the protection of agency subscribers who choose to use one certificate for transactions with a number of agencies.

Disadvantage

It may be difficult to define when personal information is aggregated for purposes, which may breach this Guideline. Directories and CRLs must be logged for a number of legitimate reasons (such as ensuring the non-reputability of transactions).

Draft Guideline 5 – Single or Multiple Certificates

Guideline -
Agencies should allow the use of similar certificates issued by agencies other than those it, or its contracted CA has issued. Agencies should not require the use of only their own certificate. Wherever possible, each agency should also allow subscribers to obtain more than one certificate, including where relevant, with differing levels of EOI. This would be subject to the agency’s EOI requirements and Gatekeeper standards.

Discussion

In practice, most subscribers of any one agency might be expected to prefer a single certificate option for applications with that agency for reasons of simplicity and cost. This Guideline would allow agencies to offer a single certificate for a group of PKI applications with similar privacy sensitivities, subject to subscriber’s choice.

This Guideline should prevent any development of a single certificate as a national identifier. The more certificates a subscriber can use, the less the risk that their transactions, habits and movements can be tracked by reference to a single certificate’s properties. However, privacy protections are in place for subscribers who wish to take advantage of the convenience of using one certificate.

Advantages

This would afford subscribers choice as to which certificates to use for transactions.
A multiplicity of Gatekeeper accredited certificates can be used without interoperability difficulties.

Disadvantages

Some agencies may achieve fewer cost savings and efficiency than if they were able to use a single certificate across a range of agencies and applications. A requirement to accept certificates from multiple CAs may prove inefficient and costly for some agencies (and possibly their subscribers, if all or some of these expenses are passed on).
Subscribers may have difficulties in managing the security and use of multiple certificates for different purposes and may opt for the convenience and likely cost savings of a multi-application single certificate.

Issues for further discussion

The Privacy Commissioner is most concerned about how to provide for individuals who wish to use a different certificate for their dealings with different agencies, where the individual does not wish to use one certificate for dealing with any two or more agencies.
If this is not achieved by the proposed draft Guidelines, an additional Guideline requiring each agency that offers PKI based services to have arrangements to issue its own certificates may be appropriate. The Commissioner is very interested in how to provide for these individuals and whether this additional Guideline is needed.
What conditions should govern the use of a single certificate for multiple uses?
Separate certificates will require multiple identification checks, unless subscribers are happy to allow subsequent RAs to have access to existing identification check information (see further draft Guideline 3).
Are the choices proposed in Guidelines 1 and 5 sufficient? Should the Guidelines offer potential subscribers other choices, such as the choice of a CA, certificate and token, even if an immature PKI market may limit real choice at present?

Draft Guideline 6 – Subscriber Generation of Keys

Guideline -
Where possible and appropriate, accredited CAs and RAs should allow a subscriber the option of generating their own keys.

Discussion

To ensure integrity in a PKI, the subscriber’s private key must be in the sole possession of the subscriber. The certificate should meet the minimum EOI or other requirements of the agency for use with the particular PKI application. Gatekeeper requires that this be the case and that any copies of the private key generated by a CA be destroyed when the key is issued to the subscriber. Appropriate software would have to be issued by service providers to subscribers in order to generate their own keys

Gatekeeper policy already supports this option. Gatekeeper policy "requires a PKI design that ensures that the key pair which constitutes the signature will be generated and distributed in such a way that:

the private key is only available to its owner;
it precludes any person other than the owner from ever being in possession of a private authentication key without the owner’s consent; and
the certifying authority can be satisfied that the public key corresponds to the owner’s private key."

An agency may decline to accept a digital signature if the generation process is not compliant with established quality or standards and end-user product key generation accreditation if applicable.

Gatekeeper accreditation ensures that any implementation of a PKI by Gatekeeper accredited CAs and RAs will be secure. These standards are already rigorous and NOIE must ensure that unnecessary additional standards are not imposed on service providers (CAs and RAs) who have already passed through the very rigorous accreditation process. There is currently no product on the Endorsed Products List (EPL) to allow subscriber generation of keys (however, it is recognised a need for such a product exists. All products used under Gatekeeper must be on the EPL).

Advantage

This Guideline would contribute to the integrity of the PKI by giving subscribers control over the generation of their keys.

Disadvantages

Such implementation could shift liability unduly to subscribers.
No Software product on the EPL is available at this point in time.

Draft Guideline 7 – Security Awareness and Education

Guideline -
The storage and use of private keys is vital to the security and integrity of a PKI. Agencies should ensure that subscribers are aware of security risks, including their responsibility for managing private keys. Subscriber agreements should specify who bears the privacy risks.

Discussion

As PKI applications develop, it will be important to promote subscriber ownership and responsibility regarding security. This may be enhanced by providing subscribers with the ability to choose a type of token which they feel confident and comfortable using. The responsibility of individual subscribers for key management is an important part of the security of PKI. There are four methods for addressing this issue:

the Guidelines recommend that agencies take general steps to ensure that subscribers are aware of security risks (this information should be provided to subscribers before the certificate is issued, or if it is not practicable, as soon as possible thereafter.);
CAs should ensure that subscriber agreements detail all the necessary security guidance. This is already recommended under Gatekeeper and adopting this position in these Guidelines will strengthen this position;
agencies will need to ensure that they are not simply transferring risk and liability to subscribers by providing them with security information. The onus should be on the agency to determine whether subscribers are capable of managing their keys in a secure way. If subscribers are not capable, the agency should provide them with a manageable alternative; and/or
The Guidelines recommend that agencies take specific steps to ensure that subscribers are aware of security risks, including subscriber warnings and education campaigns.

Advantage

Security awareness of subscribers should improve the overall security of a PKI. Such awareness may also increase confidence in the system.

Disadvantages

Some subscribers may have difficulties with managing their keys or may not understand PKI sufficiently to manage security issues.
Added expense in providing multiple technology platforms necessary to ‘read’ the certificate from different types of subscriber tokens if a range of tokens are available.
Costs for agencies may be increased.

Draft Guideline 8 – Public Key Directories

Guideline -
Subscribers should be allowed to opt out of having their public keys published on a Public Key Directory. CAs and agencies should also consider whether the publication of a public key directory is necessary to their business.

Discussion

In a PKI the role of the public key directory is to allow general access to public keys for two purposes. The first would be in respect to authentication so that the authentication public key can be accessed in order to authenticate the identity of the subscriber. The second purpose would be to access a subscriber’s confidentiality public key to send them an encrypted message.

Privacy concerns arise from the risk of possible browsing of public directories, downloading bulk data from them or using them in other ways that may be privacy-invasive.

In Commonwealth implementations of PKI it may not be necessary for a public key directory to exist at all. If the relevant agency holds or has access via a commissioned CA to copies of the public keys then it will be able to authenticate messages from a subscriber and also send encrypted messages to them. Agencies should carefully consider whether their PKI applications require the use of a public key directory. If such a directory is considered necessary then individual subscribers should be permitted to opt out of having their public keys listed on the directory.

Advantage

The non-use of public key directories or permitting subscribers to opt out of being listed would limit any risk that any associated personal information could be misused for other purposes.

Disadvantages

Multiple use of a certificate across agencies (some agency subscribers might prefer this) may be disrupted.
In some circumstances, subscribers who opt out would have to forward their certificate to relying parties.

Issues for further discussion

What impact would these requirements have on Gatekeeper accredited CAs/RAs?
Would this requirement impose additional costs on agencies?

Guideline 9 – Directory checks

Guideline -
Agencies should ensure that where directory checks (including CRLs and PKI transactions) are undertaken, no detailed history of such checks is created or recorded by the agency or PKI service provider engaged by the Commonwealth government, except to the extent that logging is required for system maintenance or evidentiary purposes.

Discussion

CA servers hosting public key directories, CRLs and other PKI transactions will normally keep logs of accesses and online transactions. Concerns have been raised about the possibility of using logs to compile profiles of individual subscribers using these services and to track their transactions.

Gatekeeper Privacy Criterion 9 applies to Gatekeeper RAs and CAs. This Privacy Criterion provides in part that:

CAs and RAs shall collect and hold minimal personal information when logging accesses to CRLs or other directory services; and
CAs and RAs should not disclose personal information collected by logging access to CRLs or other directory services, except for designated law enforcement purposes.

If an agency operates as a CA or an RA, the above applies to them. Agency servers hosting PKI transactions with individuals will also log transactional data. This draft Guideline applies Gatekeeper privacy criteria to all agencies.

Profiles of subscribers should not be created, and restrictions should be placed on the ability to browse records or obtain records in batches whether from a CRL, a Directory or an agency’s server.

While directory checks are an integral part of a PKI, it is only necessary to allow single, specific directory inquiries to be possible. There is no need to allow general browsing of directories, downloading of multiple entries or downloading of batches of data. In addition, there should be no need for logs of directory look-ups to be maintained, except that when a relying party may need to show that they took reasonable care to check the validity of a certificate. If logs of directory look-ups were created, maintained and the data was then analysed, this data could form over time a comprehensive picture of an individual user’s transactions and habits, as well as a potential trail of their location and movements (either physical or online).

Advantages

This restriction minimises the opportunity for the tracking of subscribers’ transactions, habits and movements, increasing subscriber confidence.
Given that PKI applications will from their inception maintain most personal information in electronic form, it is appropriate that this restriction be imposed as one of the first restrictions on the use of public register information.

Disadvantage

There may be limited legitimate reasons why logs of directory inquiries should be kept (for example, as evidence to support non-repudiation or to detect and prevent fraud or for law enforcement purposes).

Issues for future discussion

This requirement is basic to ensuring privacy protection in respect of PKI applications, but there may be technical hurdles to overcome before service providers who manage directory services can ensure that histories of directory look-ups will not be created. Any such hurdles (and options for overcoming such hurdles) should be raised in submissions.
What legitimate uses would warrant the keeping of logs when balanced against the surveillance capability that logs enable? For example, for a CA, keeping such logs are vitally important from a liability perspective, as it is the only way to show a relationship with a relying party. What evidentiary or notarial alternatives might be reasonable alternatives to logs?

Draft Guideline 10 – Pseudonymity and Anonymity

Guideline -
Where appropriate, agencies should provide subscribers with pseudonymous or, if appropriate, anonymous means of PKI to deal with agencies. These might include alternative forms of authentication (for example, attribute rather than Gatekeeper identity certificates).

Discussion

The NPPs acknowledge that anonymous methods of conducting transactions should be made available where appropriate (NPP 8) and, while there is no similar requirement in the IPPs, the provision of anonymous alternatives has emerged as best practice in privacy protection.

Although Gatekeeper itself does not at this stage support anonymous certificates in a practical way, it is not the intention of Gatekeeper to restrict agencies to only use identity certificates. Gatekeeper Privacy Compliance requirement 12 – Support of anonymous or pseudonymous certificates, which reads:

The CA shall have the ability to provide anonymous or pseudonymous certificates where appropriate.

Gatekeeper policy requires a PKI design that enables individuals to:

Choose to use any Distinguished Name in a certificate, except where it would be impractical to do so; and
Conduct pseudonymous transactions except where the agency demonstrates that it is impractical to do so.

Advantages

Gatekeeper and the NPPs support this requirement.
This requirement provides a layer of privacy protection for those situations where identification is not required.

Disadvantage

There will be many types of applications where authentication will be important and legitimate for agencies.

Part Two - Background and Resource Material

Chapter 3 - Public Key Technology (PKT) and Gatekeeper

This Chapter contains a description of how PKT works, an explanation of PKI and a summary of the Gatekeeper Strategy, participants and key features.

3.1 Public Key Technology (PKT)

PKT is a form of cryptography that allows two parties to communicate in such a way that a third party is unable to determine the content of the message (confidentiality) or alter the message without detection (integrity). PKT can also provide authentication of identity and non-repudiation in online transactions.

To enable the features offered by PKT (that is, authentication, integrity, non-repudiation and confidentiality), two key pairs are used: a signing key pair and an encryption (or confidentiality) key pair. The term ‘key’ is used to describe a computer file that includes a mathematical value, derived from a prime number, which can be used in conjunction with an algorithm to encrypt or decrypt a message. The subscriber’s signing key pair can authenticate, verify the integrity of and limit opportunities to dispute content and authorship of a message. Use of the encryption key pair of the recipient can preserve the confidentiality of a message sent to the recipient.

Subscribers may publish their public key freely so that other people can use it to communicate with them, but must keep their private key secret. Subscribers of public-key based systems must be confident that when they use a public key (whether to decrypt a ‘signed’ message they receive or to encrypt a confidential message they are sending) the person they are communicating with owns and controls the associated keys.

3.2 Digital Certificates

A digital certificate is an application of PKT employed to make a public key freely available. They associate (or ‘bind’) a particular public key with either:

an identified particular person (an identity certificate);
a person who is not specifically identified in the certificate with certain attributes (an attribute certificate); or
an identified person who has certain attributes (for example, a role within an organization, qualifications, eligibility or entitlements).

To trust the assertion in a digital certificate that the public key in the digital certificate is associated with the person identified a trusted third party known as a CA endorses digital certificates.

3.3 Digital Signatures

A digital signature is an application of PKT with four distinct features:

Authentication – a digital signature can verify who sent the message
Integrity – a digital signature can verify the message content has not been altered in any way between being sent and received; and
Non-repudiation ^[2] – a digital signature can limit opportunities to dispute content and authorship of a message.
Confidentiality- that the message cannot be read in transit.

A digital signature is an encryption technique that encrypts a hash or digest of a message with a subscriber’s private signing key and sends the encrypted hash with the unencrypted message to a recipient. The recipient uses the same technique to the unencrypted message they receive, and compares the output to the hash they have received from the sender (and decrypted using the sender’s public signing key). If the output the recipient has produced and the hash they have received from the sender match, then the recipient would know that the message has not been tampered with en-route (that is, message integrity is verified).

Digital signatures can function with electronic messages, documents or communications in the same way as physical signatures do on paper. Digital signatures can be applied to e-mail, Internet transactions, web pages, online transactions and more.

3.4 Signing and Encryption Key Pairs

Typically, to enjoy all the features offered by PKT (that is, authentication, integrity, non-repudiation and confidentiality), two key pairs are used: a signing key pair and an encryption (or confidentiality) key pair. The subscriber’s signing key pair can authenticate, verify the integrity of and prevent repudiation of a message sent by the subscriber. Use of the encryption key pair of the recipient can preserve the confidentiality of a message sent to the recipient.

The keys operate as inverses:

Only the holder of a private key can decode a message someone else has encrypted with the corresponding public key. The sender of a message who wants the contents to be kept confidential during transit uses the public key (which is freely available) of the recipient’s encryption key pair to encode the message – only the recipient holds the private key so only they can decrypt and read the message.
Conversely, a message, which can only be decrypted using a public key, must have been encrypted using the corresponding private key. The sender of a message who wants to prove to the recipient that they are the sender and verify the integrity of the message uses the private key of their signing key pair to encode the message (or a hash of the message) – the recipient uses the sender’s public key (which is freely available) to decrypt the message and knows that it could only have been sent by the sender.

Following is an illustration of how Alice can use PKT to send a message to Bob that is kept confidential. Bob can verify that the message came from Alice and that the message has not been altered en-route. Alice cannot later repudiate that she sent the message to Bob.

Image Source: Health Insurance Commission

image explaining Safe Electronic Information Transfer

[D]

Subscribers of public-key based systems must be confident that when they use a public key (whether to decrypt a ‘signed’ message they receive or to encrypt a confidential message they are sending) the person they are communicating with owns and controls the associated private key.

3.5 Public Key Infrastructure (PKI)

PKT is supported by an administrative or trust framework with standards and rules that are well known and transparent. This administrative framework – PKI – can support authentication of an individual (or role), the integrity of messages, the confidential transfer of messages, and the non-repudiation of messages and transactions. This administrative framework includes PKT products, service facilities, policies, procedures, agreements and participants.

The main components of PKI are:

Certification Authorities (CAs) – issue and revoke digital certificates;
Registration Authorities (RAs) – conduct the initial verification of a potential subscriber’s identity and/or attributes;
Subscribers – digital certificate holders;
Relying parties –subscribers when relying on the contents of a digital certificate in communicating with subscribers; and
Directories – may store public keys, digital certificates or Certificate Revocation Lists (CRLs).

The main operations and processes of PKI are:

Registration – the process whereby a potential subscriber makes themselves and/or their relevant attributes known to the CA directly (or through an RA);
Key generation – the generation of one or more key pairs by the CA or by the subscriber;
Certification – the issue by a CA of a digital certificate to a subscriber;
Certificate expiry – the allocation of a period for which a digital certificate will remain valid;
ertificate revocation – the revocation of a digital certificate prior to its expiry (eg where the private key has been compromised); and
Certificate Revocation Lists (CRLs) – directories of revoked digital certificates.

3.6 Gatekeeper

Gatekeeper is the Commonwealth Government’s Strategy for the use of PKI, also known as the Government Public Key Infrastructure (GPKI). Gatekeeper includes accreditation of CAs and RAs to ensure that their technologies and practices comply with Government policies, including security and privacy. The accreditation process aims to provide certainty and trust for all parties involved in the use of Gatekeeper digital certificates. Privacy accreditation requirements 1- 12 are set out in Appendix 3. Additional requirements are contained in the Gatekeeper Model Head Agreement (available from www.govonline.gov.au).

Gatekeeper was established administratively rather than by legislation.^[3] Gatekeeper standards are mandated in contracts and policy statements between NOIE and CAs and RAs, and in turn between the CAs and RAs, their subscribers and possible relying parties in various contracts.

3.7 Head agreements and other Gatekeeper-accredited documents

Once a CA or RA satisfies Gatekeeper accreditation requirements, it formally gains Gatekeeper accreditation by signing a Head Agreement with NOIE. This outlines the terms and conditions for accreditation, including privacy and security requirements (as an example, see Appendix 4 for the standard privacy provision in head agreements).

CAs and RAs are also required to have their Certificate Policies, Certification Practice Statements, Subscriber Agreements and other operational documentation accredited under Gatekeeper. These documents set out the terms and conditions upon which CAs and RAs deal with their subscribers and relying parties including privacy and security provisions.

Chapter 4 - Existing Privacy Protections

This chapter examines existing laws and Gatekeeper requirements that serve to protect subscribers’ privacy in PKI applications.

4.1 Privacy Requirements

The Act incorporates the IPPs which apply to the Commonwealth public sector (and ACT Government) and the NPPs, which apply to the private sector.

This Chapter, and this Paper generally, does not consider State based privacy requirements (such as privacy laws in NSW, Victoria and the ACT) or specific industry codes of conduct – many of which will be relevant to privacy issues arising in some PKI applications.

The detailed requirements of existing privacy requirements are set out in the table at Appendix 3 of this paper.

It should be noted that CAs and RAs have their own commercial reasons for protecting the privacy interests of their own subscribers, given that their reputation depends on maintaining public trust and confidence.

4.2 The Information Privacy Principles (IPPs) and the National Privacy Principles (NPPs)

All agencies are bound by the IPPs contained in the Act. The IPPs are general privacy standards that apply to a diverse range of government. They are not specific to any particular technology or type of data processing. The table at Appendix 3 shows the specific instances where the IPPs will apply to steps in a user’s experience of using a PKI application.

Gatekeeper accredited CAs and RAs are bound to observe the IPPs, which is a requirement in their Head Agreements with NOIE. Contractors carrying out services for agencies are also bound by the IPPs. Agencies are required to bind firms by contract to observe the IPPs, in all ‘Commonwealth contract’ situations. These include outsourcing cases where the firm is doing work that the agency itself would otherwise do.

Firms bound by contract to observe the IPPs will also be required by the new law to observe the NPPs from 21 December 2001 unless that would be inconsistent with a Commonwealth contract, which takes precedence. Such contracts are required to provide privacy protection to a level at least equivalent to the IPPs.

4.3 Gatekeeper Privacy Protections

There have been substantial attempts to address privacy concerns within the PKI framework, including privacy aspects within the Gatekeeper compliance process. While these requirements are specifically targeted at CAs and RAs, they also have some value for agencies implementing PKI applications in certain circumstances. The key documents are:

Gatekeeper Criteria for Accreditation of CAs
http://www.govonline.gov.au/publications/CA-AccreditationCriteriaV9.pdf (pdf file)
Gatekeeper Model Head Agreement
http://www.govonline.gov.au/projects/publickey/GK_CA_Head_Agreement_V6_1.pdf (pdf file)
Gatekeeper Criteria for Accreditation of RAs
http://www.govonline.gov.au/publications/RA-AccreditationCriteriaV10.pdf (pdf file)
Gatekeeper Concept of Operations Guide
http://www.govonline.gov.au/publications/ConceptOfOperationsV5.pdf (pdf file)
Gatekeeper Additional Evaluation Information
http://www.govonline.gov.au/projects/publickey/AdditionalEvaluationInformation.doc (word file)
Gatekeeper Dependency Tables
http://www.govonline.gov.au/projects/publickey/GPKAAccreditationCriteriaDependencies.doc (word document)
Gatekeeper Privacy Recommendations to the Chief Executive Officer, NOIE, in relation to the use of Gatekeeper Certificates by Individuals
http://www.govonline.gov.au/projects/publickey/Gatekeeper_privacy_recommendations_May2000.htm

The first six documents above repeat the core Gatekeeper privacy requirements, and are referred to in the table in Appendix 3 as ‘GK’. The numbers (for example, GK 01, GK 02) refer to the privacy criteria set out in the Gatekeeper Accreditation for CAs document.

The final document listed above (Gatekeeper Privacy Recommendations to the CEO, NOIE, in relation to the use of Gatekeeper Certificates by Individuals, see Appendix 5), is a more recent elaboration of privacy protections within the Gatekeeper framework. It is referred to as GK Supplementary in the table. The criteria listed in that document are not numbered or otherwise indexed. They are therefore listed as A, B, C etc. based on their order of appearance in the GK Supplementary document.

All these requirements have substantial implications for organizations seeking to participate in the PKI, as they are requirements of both entry level and full accreditation.

These requirements are specific to PKI applications while still repeating the basic structure of at least the IPPs. Their application will be reviewed by NOIE in the light of this paper and the consultation process.

4.4 Personal Privacy and Security Management

The individual subscriber plays a key role in many PKI applications. They will be responsible for decisions and actions that have a direct impact on their privacy. While the Guidelines (backed up by the Gatekeeper privacy requirements for CAs and RAs) ensure that agencies will have to offer consumers a wide choice of certificate issuers, tokens and certificates, the subscriber will have to exercise that choice. Similarly, agencies may make available anonymous alternatives to identified certificates – again, the consumer will have to explore those alternatives if they wish to enhance their degree of privacy protection.

Individual subscribers may also have to share some responsibility for the security of their personal information. Sensitive information, such as key pairs, may be stored on a PC or a mobile device that could be subject to a wide range of security weaknesses. The computer or device could be stolen, lost or damaged. A co-worker, friend or household member might gain access to the computer or device. The computer or device might be subject to remote attack (hacking).

In many cases the weakest layer of security in the entire PKI application will be the pass phrase or code used by the consumer to access their private key. This could be as simple as a four digit PIN memorized by the consumer and entered into a browser. Others can witness this data entry, or more commonly, the PIN will be stored in the computer or device itself (Microsoft Windows users will be familiar with the regular prompt offering to save passwords to speed up future access).

Consumer education regarding these responsibilities will be a vital step in protecting privacy in PKI applications.

4.5 Biometrics

One method of enhancing security in a PKI application is to develop more robust processes for allowing access to private keys. Current password or PIN security may be seen as weak for a range of reasons:

PINs and passwords may be easily guessed (this is often because subscribers choose birth dates or family names);
PINs and passwords may be easily broken through multiple attempts (although this usually requires software limiting the number of access attempts to be disabled), interception, ‘hacking’ known software vulnerabilities and social engineering; and
PINs and passwords are easily forgotten (often resulting in subscribers keeping a record of the PIN or password in a non-secure location).

These weaknesses may, in some limited circumstances, lead organizations to consider biometric alternatives to access control. There is a wide range of biometric identification and authentication technologies available, based on retina scans, palm prints, voice recognition and the like. They do not require the subscriber to remember anything and they cannot be guessed or broken (no matter how many attempts are made).

However, they are often more privacy intrusive than traditional access control methods (although this depends to a great degree on the actual design of the system) and if they are compromised it is more difficult to repair the damage than losing a PIN or password that can be cancelled and replaced.

Agencies considering the use of biometrics should seek additional advice from the Defence Signals Directorate on the use of this technology as no biometric devices have been evaluated for security use.

PKT is often seen as a stimulus for the wider use of biometrics, because control of access to private keys is so vital and is the obvious weak link in the overall security of PKI applications.

However, the debate about the privacy implications of biometrics is much wider than PKI applications and will require further discussion and resolution. It should be sufficient at this stage to note that biometrics is not essential for the success of PKI, and that the use of biometrics is a factor which might be considered within an overall PIA undertaken by an agency.

4.6 Identification Issues

Another element of PKI, which has an impact on privacy, is the requirement to present an EOI to an RA in order to obtain a Gatekeeper compliant certificate. This is just one small step in the overall PKI process, but raises significant privacy issues.

If the EOI requirements are set too high, some potential subscribers may become excluded from participation. Many people do not have a fixed address or key documents such as passports and drivers licenses. This potential has been reduced through the availability of Centrelink reference letters, which can be used by persons who otherwise cannot reach 100 points of identification (for example, the level required to open a bank account). It is expected that these reference letters (where appropriate) would also be available to present to RAs to ensure that exclusion does not occur.

Within the RA itself, the temptation may arise to keep comprehensive and substantial records of all EOI documentation presented. This can lead to the development of centralized stores of detailed personal information.

In the Gatekeeper document Gatekeeper Privacy Recommendations, item H titled 'Centralised Storage of Identification Details' states that:

"Gatekeeper requires a PKI design that ensures that there is no single centralised storage of PKI distinguished name or identification details… The Gatekeeper strategy has created a framework whereby the storage of personal information needed for identification is diffused between the Registration Authority and the Certification Authority, in order to prevent centralised storage. Both of the bodies are bound to observe the Information Privacy Principles, and there are limitations on information which an RA can pass to a CA."

4.7 PKI Alternatives

Authentication is a term, which describes a vast array of possible processes and technologies. Certificates issued as part of a Gatekeeper style PKI form only a very small subset of the available authentication methods.

Some alternatives are based on models in which there is no single accredited trusted third party at the heart of the system. An example is Pretty Good Privacy (PGP)^[4], which has become a popular method of encrypting the content of e-mail and authenticating the sender. PGP is not authorised for agency use.

A further alternative is the development of attribute certificate systems. These will often sit alongside PKI style authentication systems and involve the same certificate issuers. The term ‘attribute’ denotes a privilege assigned to an individual. Importantly, an attribute refers to a privilege held by an entity rather than that entity’s role within an organization. For example, an individual has the role of manager, while the individual’s attribute is the privilege of signing company cheques.

An attribute certificate is favourable in terms of privacy because an individual’s privilege (for example, their entitlement to view certain information as they are a paying subscriber of a magazine or web site) will be communicated, but their identity will not. However, the availability of standards based attribute certificates is still some time away.

There are also hybrid certificates available (and there appears to be a trend towards developments in this area) which have all the characteristics necessary to provide both full authentication of identity and attributes, but which can allow the subscriber to ‘blind’ the identity when they choose to do so.^[5]

Appendix 1Privacy Impact Assessments (PIA)

As Guideline 2 recommends that agencies undertake a PIA before implementing a PKI application, this chapter discusses the nature and scope of a PIA.

A1.1 Purpose and description of a PIA

A PIA is a tool for use in consciously and systematically identifying and addressing privacy issues.^[6] PIAs may be viewed as feasibility studies from a privacy perspective.

A PIA is a tool to assist in determining whether a system and related business practices meet the requirements of the privacy laws, codes and accepted or desirable practices (including those which are not covered by the existing IPPs), and attempts to gauge consumer acceptance.^[7] It allows for consideration of privacy issues in advance of privacy erosion rather than retrospectively. If the results of the PIA are published, it may facilitate the exercise by individuals of a more informed choice.

The PIA process is not an objective in itself – it should be integrated into decision-making processes surrounding the PKI application under proposal.^[8]

The PIA recommended in Guideline 2 requires agencies, in conjunction with their information technology personnel, to identify and address privacy issues as part of the PKI application’s design and development. The process is a tool to assist agencies to minimize intrusiveness, maximize fairness and satisfy expectations of the individuals dealing with the agency as to confidentiality of their personal information.^[9]

Questions that the PIA report must answer include: What is the business need for the use of digital certificates and the PKI application? What alternatives to the PKI application exist, or are there other ways in which the PKI application can be implemented? For the particular PKI application that is proposed, what negative privacy impacts may arise and how are those negative privacy impacts justified? How can those negative privacy impacts be ameliorated? How will the specific requirements of applicable privacy laws be satisfied by the proposed PKI application? ^[10]

Importantly, the PIA is a process, rather than the generation of a report, although the findings and analysis should be documented to allow sharing of the process experience and for the process to form a useful decision-making tool.

A1.2 Who should conduct the PIA?

It is proposed that the agency (and not the Privacy Commissioner) be responsible for conducting the PIA. Having the agency undertake the PIA means that they can bring to bear past experience and expertise to find solutions or better alternatives that address privacy concerns highlighted by the PIA.

In Alberta, Canada, the privacy regulator has the power to review and ‘accept’ (but not approve or waive any strict legal requirements) of PIAs conducted by agencies.^[11] While it is open for the Guidelines to require agencies to file the PIA report with the Privacy Commissioner, the risk is that the public may mistake the ‘filing’ for approval (implicitly, if not explicitly) of the PIA report.

It should be recognised that those agencies, which have achieved Gatekeeper accreditation as an RA or CA, will have developed an approved privacy plan and are subject to auditing in order to have their accreditation renewed. It is expected that these plans would substantially satisfy the features of a PIA.

People making submissions might like to comment on who should be involved in the conduct of the PIA and whether the Privacy Commissioner should take a greater role than is proposed in this Paper.

A1.3 Publication of the PIA report

Public comment and/or external privacy advocate review is an important feature that should be considered in a PIA process. To the extent that a report on the PIA process or its results is made public, it can generate confidence amongst the public that their privacy has been considered in the development of PKI applications. Further, the publication of the report gives the public the opportunity to express concerns, in effect generating public reaction to the proposal prior to its implementation.

Agencies should consider whether a formal public consultation process, a selective consultation process, market research or other proactive steps should be taken to obtain feedback on the privacy implications in light of the expected benefits of the proposed solutions.

Even where the report is not publicised, the PIA still helps the agency to anticipate public reaction to the privacy implications of a given proposal by seeking to identify in advance any potential privacy issues that may have to be addressed prior to launching the PKI application.^[12]

People making submissions might like to comment on whether and in what circumstances a PIA should be published, at what stage during the design and build of an application it should be published, and what (if any) public consultation process agencies should undertake.

A1.4 Sample PIA checklist

While the PIA checklist [see Table 2] is framed as a series of questions, most of which are capable of being answered either "yes" and "no", in practice the explanation and analysis that underpin those answers must be documented in order for the report to be a useful decision-making tool.

Table 1

PIA 1 - USE OF DIGITAL CERTIFICATES

PIA 2 - Description Of Application And Digital Certificates

PIA 3 - Personal Information To Be Collected

PIA 4 - Method Of Collection

PIA 5 - Purpose, Use And Disclosure

A) Limits on collection
B) Purpose
C) Secondary use
D) Consent
E) Disclosure

PIA 6 - Choice

A) Issuer, token, certificate
B) Anonymous/pseudonymous

PIA 7 - Storage

A) Security
B) Retention and destruction

PIA 8 - Data Quality

PIA 9 - Access And Correction

PIA 10 - National Id Potential

PIA 11 - Public Register Information

A) Certificate Revocation Lists (CRLs)
B) Public key directories

The checklist covers privacy issues raised by both:

The establishment and use of digital certificates within the Gatekeeper PKI; and
The broader application with which the individual will use their digital certificate.

The purpose of this broader scope for the PIA is that:

The nature of the privacy concerns raised by the application will be an element in determining whether a digital certificate is the appropriate technology to be used; and
To determine, in light of the privacy concerns that digital certificates raise, whether the use of digital certificates is still justified.
The checklist is a sample only. It is by no means exhaustive and is intended as a starting point to stimulate discussion of the process and analysis that agencies may undertake to assess privacy risks. In the following sample checklist, the questions are phrased to clearly identify areas of privacy concern. If the answer to a question is "no", the PIA report should document:
The reasons, and any legal exceptions or logical exceptions that justify the PKI application not meeting the privacy concern expressed in the question;
What could be done to make the answer "yes"; and
If the answer is to remain "no", what procedures are in place to mitigate the possible effects of the identified risk.
Where there are no legal exceptions permitting deviation from the privacy requirements imposed by law or by binding policy (eg Gatekeeper privacy requirements), steps must be taken to amend the PKI application or surrounding process so that the answer becomes "yes".

Table 2

PIA 1 - Use of digital certificates

Yes

Are all four features offered by digital certificates in a PKI (authentication, integrity, non-repudiation, and confidentiality) being utilised by the application? If not, what alternative technology options could be utilized to provide the necessary features without requiring individuals to procure and use digital certificates?

PIA 2 - Description of application and digital certificates

Describe the important features of the application, including:

List the project name for the proposed application, the name of the agency responsible and any agencies involved in the project;
Describe the use of digital certificates in plain, non-technical language; and
Describe the drivers for the development of the application and the use of digital certificates, including any new needs the application will address and any public benefits the application will provide.

PIA 3 - Personal information to be collected

List and describe the personal information (information about an identifiable individual) to be collected in the use of the digital certificate or in the application including:

Identifying information such as the individual’s name or any identifying number assigned to the individual;
Attribute or eligibility information such as the educational, medical, criminal, employment or financial history of the individual;
Evidence of Identity (EOI) information;
Sensitive information;^[13]
Biometric information;
Categories of individuals or groups the personal information will concern – and the classes of personal information collected for each category; and
Any third party personal information that may be collected.

PIA 4 - Method of collection

Yes

Will personal information be collected in the use of the digital certificate or in the application only from the individual to whom the information relates? If no:

Why can the personal information not be collected from the individual concerned? Why must it be collected from alternate sources?
Is the personal information being collected by lawful and fair means?
Is the personal information to be collected on one occasion only (ie not ongoing)? If no:

PIA 5 - Purpose, use and disclosure

Limits on collection

Yes

Is the personal information relevant and necessary for the use of the digital certificate or for the application?
Is there a statutory power, authority or requirement for the agency to collect and use the personal information?
Will the information collected not intrude to an unreasonable extent on the personal affairs of the individual (especially EOI information)?
Can information be collected in a de-identified (anonymous) or pseudonymous manner?
Are individuals given the option of acquiring the services without having to provide some or all of the personal information sought?

Purpose

Yes

Is personal information obtained in the use of the digital certificate or in the application used exclusively for the purposes made known to and consented to by the individual?

Secondary use

Yes

If the agency finds a secondary use that can be made of data already collected, is the use consistent with uses notified to or consented by the individual? If no:
Can an individual opt not to consent to the secondary use and still be entitled to receive the services offered utilising the original application?

Consent

Yes

Will notice of the following information be given to the individual at or prior to collection:
The purpose for which the personal information is being collected?
Whether the collection of the personal information is authorised or required by or under law?
The people, bodies or agencies to which the collecting agency usually discloses personal information of the kind being collected?
Is the individual asked at or prior to collection to consent to the collection and use of the personal information?
Are uses that the agency considers ‘consistent’ with the primary purpose (eg audit trails of transactions) also made known to the individual?

Disclosure

Yes

Is personal information involved in the use of the digital certificate or in the application disclosed to any third party other than those of whom the individual has been notified as potential recipients of the personal information? If no, does some exception under law apply?
Is the recipient’s use of the personal information limited to the purpose for which it was collected? Will the recipient disclose the personal information to third parties?
Will personal information disclosed to third parties be protected from privacy risks to the standard proposed to protect it?

PIA 6 Choice

Using PKI, use in personal information, multiple certificates

Yes

Do agency customers have a choice about whether to use PKI?
Can subscribers choose what use is made of their personal information?
Do subscribers have a choice regarding whether they can hold multiple certificates?
Are suitable protections in place if a subscriber only wishes to use one certificate?

Anonymous/pseudonymous

Yes

Are anonymous and pseudonymous options made available to subscribers involved in the application, where appropriate? ^[14]
Can subscribers use substitute services via other means (ie without using the application) and thereby reduce (or eliminate) the personal information they are required to supply?

PIA 7 – Storage

Security

Yes

Does the level of security provided in the use of the digital certificate or in the application match the potential harm caused by breaches of privacy?
Is the individual able to generate their own key pair?
Are individuals given information about the importance and available means of maintaining key security?
Will security measures to be reviewed over time to address new potential security hazards (eg changes to technology)?

Retention and destruction

Yes

Will a retention policy / destruction schedule be developed which requires retention of personal information only for the period required for use?
Is personal information de-identified as soon as possible?

PIA 8 - Data quality

Yes

For the purpose for which it is used, will the personal information collected in the use of the digital certificate or in the application be up-to-date at all stages and on all occasions that it is used, relevant, accurate and complete.
Will records be maintained of the date of the last update of the personal information held be maintained and used by the Agency and the source of updates to personal information?
Will updates and modifications to personal information be disseminated to all third parties to whom personal information has been disclosed?

PIA 9 - Access and correction

Yes

Can the individual ascertain whether the Agency has records that contain personal information, the nature of that information and the steps that the individual should take to access their record?
Will the costs incurred in accessing personal information be reasonable?
Can the data or records about an individual be updated as a result of an individual seeking correction of personal information?
Will corrections and annotations be disseminated to third parties to whom personal information has previously been disclosed?

PIA 10 – Potential for aggregation of personal data

Yes

Does the manner in which digital certificates are issued, managed and used for the application prevent the use of an individual’s public key as an identifier to link, match or cross-reference personal information about that individual held in different databases?

PIA 11 - Public register information

Certificate Revocation Lists (CRLs)

Yes

Can a subscriber revoke their own certificate? ^[15]
Will steps be taken to ensure that no comprehensive log of CRL lookups is kept? Prefer - "not used, except for evidencing the relying party’s checking of the CRL"

Public key directories

Yes

Does the Agency ensure that detailed histories of directory checks are not created by the application or by the directory manager?
Will steps be taken to restrict directory searches to single specific searches only?

Appendix 2 Current Use of PKI in the Australian Public and Private Sectors

This chapter looks at the current use of PKI in the public and private sector in Australia, and includes a case study.

A2.1 An overview of agency consultations

As noted above, the OFPC held informal discussions with key agencies to gain an understanding of agencies’ plans in relation to the use of PKI, their current approaches to the privacy implications and constraints or issues that they had identified to date. A list of agencies consulted is at Appendix 6.

A2.2 Trends arising from agency consultations

Trends and themes that have emerged from these discussions include:

few agencies yet have clear, well developed plans to use Gatekeeper certificates with individual clients;
the business case for having individual certificates issued to individuals may be difficult to make, given the likely costs and complexities for agencies in setting up PKI systems and applications, and the question of whether agencies really need all the features which PKI offers;
while PKI appears to be the only approach which can offer all four benefits of authentication, message integrity, confidentiality and non-repudiation, agencies are questioning whether all these features are actually needed or desirable for their business needs;
useability is a factor in that some agency subscribers may not be capable of using PKI interfaces. Limited agency experience with PKT to date has been slowness of uptake for reasons including bandwidth, age of subscribers and their dislike of technology, subscriber resistance (unless there is something in it for them) and problems with availability and quality of subscriber facilities;
a common application being considered in several agencies is the issue of certificates to staff in order to manage network access, particularly remote access;
an interest by some agencies in using attribute certificates, either in combination with identity certificates or possibly without the need for authenticated identity;
agencies are concerned about vulnerability of existing EOI processes to a range of fraudulent practices and errors. Some agencies question whether such vulnerability might extend to PKI-based identification;
It is likely that most agencies will favour the re-use of EOI (which would require an agency to obtain approval from the individual to have their original EOI shared with one or more subsequent RAs); and
There appeared to be some confusion about the differences between PKI and Secure Sockets Layer (SSL) including when it may be appropriate to use SSL (or a similar technology) and when it may be appropriate to use PKI.

A2.3 Current PKI applications

A2.3.1 ATO

The ATO has been using PKI keys and certificates issued by the ATO CA since July 2000. Currently the ATO uses keys and certificates for business Activity Statements (BAS), Superannuation, and soon Diesel and Alternate Fuels Grants Scheme (DAFGS) transactions. Planned projects include the Corporate E-mail Project and redevelopment of the ABR (Australian Business Register). e-tax and Mobile Computing also use PKT and the ATO plans to bring these applications under the umbrella of the ATO CA and Gatekeeper.

e-tax is a free software package developed by the Australian Taxation Office. e-tax uses public key encryption technology to ensure that the taxpayers’ tax return data is secure for transmission over the Internet. As part of the e-tax security system the subscriber must verify their identity before they can download the security software. The security software contains their digital signature and encryption software, which secures their tax return data against unauthorised access during transmission over the Internet.

The e-tax system requires the subscriber to use their TFN to verify their identity before it can package the security software for download. By law, the subscriber is not required to provide their TFN, however, if they decide not to do so, they will not be able to use e-tax. Once the subscriber has verified their identity, they will be given a unique password and directed to download their security software.

The subscriber is responsible for maintaining the security of their password and of the environment in which e-tax is stored and used and the integrity of the private key file used with e-tax. The digital certificate in e-tax is designed to protect the integrity of the subscriber’s taxation information and it is provided as part of e-tax specifically and cannot be used for any other purpose other than the lodgement of their tax returns.

Excise is making arrangements to allow individuals and other business entities to report to its grants schemes using the Electronic Commerce Interface. While moving towards self-assessment, ATO Excise is looking to reduce the information collected by various areas for registration and claims against these schemes. Excise is piloting the use of PKI keys and certificates for the DAFGS with a small group of subscribers. In the year 2001, the use of PKI is expected to extend to all DAFGS subscribers, plus the Product Stewardship (oil) Scheme and Fuel Sales Grant Scheme.

The Corporate Email Project considers PKI a worthwhile option for a secure e-mail solution to provide subscribers with an alternative and confidential means of communicating with the ATO. The impacts of this change on the current business are expected to be large. The advantages and disadvantages of various options are being evaluated. A report containing recommendations is expected to be available in June 2001. A number of other business areas within ATO are also considering the use of secure e-mail for subscriber correspondence.

The ATO is establishing a Mobile Computing environment to provide flexibility for staff in regard to their work location, especially for field staff. Internal systems for mobile computing are already in production with extensive use of smart card and PKT. Internal guidelines have been developed and are constantly being updated to keep them in line with the ATO policies and procedures, especially in regard to privacy issues.

The current Mobile Computing environment uses Netscape Certificate Server which does not have Gatekeeper accreditation. The use of the ATO CA would enable the establishment of a single certificate issuing authority for certificates that are used by ATO staff, as well as those certificates that are used by ATO clients for taxation purposes. The longer term plan is to migrate the Mobile Computing application to keys and certificates issued by the ATO CA and obtain Gatekeeper accreditation for this application.

In the long term, ATO anticipate an on-going increase in the use of PKI in the dealings with taxpayers. There will be a gradual increase in the use of e-tax by individuals and a migration from paper based BAS returns to e-BAS returns. The ATO ELS (Electronic Lodgement System) will merge with the Electronic Commerce Interface (ECI) to become PKI enabled so that ELS transactions will occur via the Internet.

A2.3.2 Health Insurance Commission (HIC)

The HIC has established the Health eSignature Authority Pty Ltd (HeSA) as a separate company under Corporations Law to undertake the activities of a PKI registration authority. These activities are specifically directed towards the support of a whole of sector approach for the implementation of public key infrastructure within the healthcare sector.

HeSA receives applications from organisations and individual professionals within the Australian healthcare sector, authenticates the identity of the prospective Healthcare Location or Healthcare Individual User and submits requests to its Certification Authority - Baltimore Certificates Australia Pty Limited (BCAPL) - for certificate issue. HeSA then distributes the Digital Key pairs and Digital Certificates to approved Healthcare Locations and Individual Users by registered post. HeSA are working on innovative ways for professionals within the health sector to communicate online in a secure environment.

HeSA received Gatekeeper accreditation on 19 January 2001 as an Extended Services RA. The use of this Gatekeeper accredited process will ensure electronic transactions using digital certificates and PKI technology will provide a high level of security for all subscribers.

The HIC has made a strong commitment to PKI and has:

commenced a national series of PKI information sessions for health software vendors;
provided PKI software to health software vendors, at no cost, to assist with the development of practice management systems;
developed Health Care Location and Health Care Individual policies detailing the terms Developed an extensive suite of support privacy policies;
established a PKI registration process to provide electronic digital certificates to health care locations;
commenced testing PKI with a series of health related projects such as simplified billing and Medicare easyclaim from doctors’ surgeries;
contracted with BCAPL to provide PKI certification authority services; and
established HeSA to provide PKI registration authority services.

A2.4 Consumer Awareness and education

Agencies were aware of the need to for consumers to be aware of the privacy and security risks associated with PKI. Governments, consumers, privacy advocates and others have prepared guides and information materials to assist consumers to protect their privacy, as well as to encourage online businesses to be aware of such privacy and security issues. Australia’s whole-of-government approach to the online economy has also resulted in the development of privacy related information products such as Building Consumer Sovereignty in Electronic Commerce – A Best Practice Model for Business launched by the Minister for Financial Services and Regulation in May 2000.

However, agencies were conscious of the need to develop particular strategies for their own subscriber groups.

A2.5 Difficulties/issues in implementing PKI

In dealing with business entities electronically, some agencies such as the ATO have encountered difficulties in establishing the PKI infrastructure at the subscriber end. The difficulties are related to relatively low levels of computer literacy of some clients, the limited capacity of some subscriber computing hardware and software, and the complexity of processes needed to ensure security and integrity. The ATO is addressing these difficulties by providing a comprehensive Help Desk facility, improving their processes, and providing information through traditional means and on the ATO web site.

A2.6 State government agency PKI applications

States and Territories through the Online Council of relevant Commonwealth, State and Territory ministers, have, in principle, adopted Gatekeeper’s framework, and are consulting with Commonwealth authorities in designing their own PKI-supported systems.

The Victorian Government in alliance with several local councils and utilities was an early mover, establishing the Maxi service [16]. Maxi began as a trial of Internet and information kiosk technology providing a ‘one stop shop’ for multiple government and utility uses in 1997. Maxi has been rolled out gradually and performed its one-millionth customer transaction in late 2000.

Maxi does not rely entirely on PKI to authenticate customers. Customers may also use other identification methods (such as a driver’s license number) or specific transaction identification numbers (such as a council rates invoice number or utility bill number). However, use of a digital certificate – issued by a commercial CA – is available for all Maxi clients for a $55 fee, and provides greater efficiency when using Maxi from a PC.

Maxi is a good example of a "life event" PKI application, where an individual can authenticate himself or herself and then provide information about the change in their circumstances to just one contact point or service provider, and the relevant data is passed to (and updates made by) a range of affiliated agencies without the need to contact each individually.

Other developments at the State level include plans by the Australian Capital Territory to implement a multi-agency smart card based authentication service.

Case study – Life event/Multi-agency application [17]

Lucy has recently changed address, and would like to inform her local council plus her gas and electricity providers of her new details. She has also received a renewal notice for her driver’s license.

Lucy has heard about a new ‘one stop shop’ service for these purposes, available on the Internet or at an electronic kiosk in her local shopping center. She visits the web site, and after reading the material about security decides that she would like to use the authentication service on offer. She is advised to apply for a digital signature certificate, and follows a link to the web site of a Certification Authority.

She completes a short application form and is given a receipt number. She takes this to Australia Post where she presents her passport and other identification documentation. She is given a choice of carrying the certificate on a disk or a smart card, a choice as to how long the certificate will remain valid, and a choice as to whether or not she would like an anonymous certificate.

She decides on a one year identified certificate carried on a disk. The disk stores information, which can be converted into a key pair back at her PC. She receives a separate password via mail and uses the disk and the password to generate her own key pair and create her unique digital signature certificate. She decides to store it on her PC and protect it by another password.

She visits the ‘one stop shop’ web site, and uses the certificate to authenticate herself. The service updates her new address for several agencies (even suggesting other relevant agencies who she had forgotten about, such as her water utility), then renews her driver’s licence, all in the one session.

A2.7 Private sector PKI applications

Although there are numerous PKI applications in the private sector for business-to-business and professional services, there are no mass-market private sector PKI applications for individuals in place in Australia at this time. However, this trend will eventually roll out applications for business to consumer services.

Until recently, the private sector appeared to be waiting for leadership from the public sector. However, with the advent of Identrus, this is no longer so. Identrus – the emerging global PKI scheme for banking and finance. Digital certificates issued by participating institutions will offer customers the certainty they require to conduct negotiations, forge an agreement and arrange for payment in a trusted and secure manner, merging these traditionally separate processes.

The Identrus Solution is designed to:

enable legally enforceable e-commerce transactions within a framework where all the participants can manage risk;
establish a uniform global system of participating rules and operating procedures that will bind both sides of any transaction (signing and relying); and
provide a well-defined dispute resolution process and recourse mechanism.

Significantly, the Australian banks that are Identrus members, jointly announced with the Government in April 2001 that they expected to be issuing Identrus certificates that would be Gatekeeper compliant, and therefore interoperable with agencies. This exemplifies an effective combination of business initiative on a governmental basis.

Appendix 3 Current Privacy Requirements

Digital Certificate Application – Subscriber Steps	Information Privacy Principles (Agencies and outsourced contracts)	National Privacy Principles (Private Sector)	Gatekeeper Related Requirements
Step 1 – Choice of Issuer The subscriber will choose an issuer of a certificate (or issuers of certificates)			GK 10 – Multiple certificates
Step 2 – Choice of Token The subscriber will choose a method of storing and carrying the certificate or certificates.			GK Supplementary C – Personal Choice as to Issuers of Certificates and Tokens
Step 3 – Accept Terms and Conditions The subscriber will consider and agree to the terms and conditions of use of a certificate or certificates.			GK Supplementary I – Freedom from Appropriation and Cancellation of Identity
Step 4 – Present Identification The subscriber will present proof of identification documents (where appropriate) in order to obtain a certificate or certificates.	IPP 1 – Manner and purpose of collection of personal information	NPP 1 – Collection	GK Supplementary H – Centralised Storage of Identification Details
Step 5 – Generate Key Pair The subscriber will generate a key pair.			GK Supplementary B – Key-Pair Generation
*Note 1* None of the above process should result in the same unique identifier being used as one already allocated by a Cth Agency.		NPP 7 – Identifiers
Step 6 – Obtain Certificate The subscriber will then obtain a certificate and an appropriate token for a certificate or certificates.			GK Supplementary D – Personal Possession and Control of Tokens
Step 7 – Choose Certificate The subscriber will then consider an application and choose an appropriate certificate.			GK Supplementary A – Multiple Use of Key-Pairs or Certificates
Step 8 – Provide Information The subscriber will provide information to the Agency (or relying party). This information may include the public key, although in some circumstances the public key will be obtained from a register. The amount of other information provided will depend on the application.	IPP 1 – Manner and purpose of collection of personal information IPP 2 – Solicitation of personal information from individual concerned IPP 3 – Solicitation of personal information generally	NPP 1 – Collection	GK 01 – Manner and extent of collection of personal information GK Supplementary G – Non-Intrusive Identification Processes
*Note 2* The Agency or relying party should not attach a unique identifier to any personal information which is already a unique identifier issued by a Cth Agency.		NPP 7 – Identifiers
*Note 3* At or before this stage, where appropriate, anonymous or pseudonymous options for subscribers should be made available.		NPP 8 – Anonymity	GK 12 – Support of anonymous or pseudonymous certificates GK Supplementary E – Pseudonymity
Step 9 – Directory Check A directory check may now take place to obtain the public key, or to confirm the authentication, or to confirm some particular attribute.			GK 09 – Privacy protection is provided for personal information published in publicly accessible lists / registers
Step 10 – CRL Check A check may now be made against a Certificate Revocation List (CRL)			GK 09 – Privacy protection is provided for personal information published in publicly accessible lists / registers
Step 11 – Application to Proceed The application will now proceed. Depending on the application some personal information may now be used or disclosed. This may be for the primary purpose or a limited range of secondary purposes in some circumstances.	IPP 9 – Personal information to be used only for relevant purposes IPP 10 – Limits on use of personal information IPP 11 – Limits on disclosure of personal information	NPP 2 – Use and disclosure	GK 06 – Personal information is used only for relevant purposes GK 07 – Limits placed on the use of personal information GK 08 – Limits placed on disclosure of personal information
*Note 4* In some cases sensitive information may be included in the personal information collected, used or disclosed above.		NPP 10 – Sensitive information
*Note 5* In some applications personal information may be exported to another jurisdiction.		NPP 9 – Transborder data flows	GK NOIE Contract with Accredited Service Providers 32.6
*Note 6* In some applications the Agency or relying party will now have a record of personal information, leading to some additional requirements regarding quality and storage.	IPP 8 – Record-keeper to check accuracy etc of personal information before use	NPP 3 – Data quality	GK 05 – Accuracy of personal information
Step 12 – Information to be Secured Any personal information now held by the Agency or relying party will be held securely.	IPP 4 – Storage and security of personal information	NPP 4 – Data security	GK 02 – Security safeguards in relation to personal information
Step 13 – Consider Management of Information The subscriber may wish to ascertain what sort of information is held by the Agency or relying party, and how they deal with this information.	IPP 5 – Information relating to records kept by record-keeper	NPP 5 – Openness	GK 03 – Openness about the types of personal information held and information handling policies
Step 14 – Access The subscriber may at some stage wish to gain access to personal information held by the Agency or relying party, and in some circumstances to correct such information.	IPP 6 – Access to records containing personal information IPP 7 – Alteration of records containing personal information	NPP 6 – Access and correction	GK 04 – Availability of procedures to allow subjects of personal information to access and correct the information
Step 15 – Certificate Revocation In certain circumstances the subscriber may wish to revoke their certificate. Alternatively the certificate may be revoked by a third party.			GK Supplementary F – Certificate Revocation
Step 16 – Inquiry or Complaint In some circumstances the subscriber may wish to learn about their options for complaining about a privacy breach or inquiring about the application of privacy rules to any of the above steps.	Section 36 of the Act		GK 11 – Notification procedure

Appendix 4 - Selected Documents on Gatekeeper Privacy Protection

The following is an excerpt from the Model Head Agreement between NOIE and Accredited Certification Authorities.

32.1 The Contractor:

(a) acknowledges that it has agreed, in the Accredited Documents, to abide by the Information Privacy Principles as if it were a Commonwealth agency; and

(b) will, in the course of providing the Certification Services to Customers, comply with the obligations set out in this clause 32 in the light of its obligation described in clause 32.1(a).

32.2 The Contractor shall take all reasonable measures to ensure that Personal Information held in connection with this Head Agreement or a Contract is protected against loss, and against unauthorised access, use, modification, disclosure or other misuse in accordance with the procedures set out in the Accredited Documents and that only authorised personnel have access to the Personal Information.

32.3 The Contactor may only vary the security procedures set out in the Accredited Documents insofar as they impact on the protection of Personal Information if it does so in accordance with clause 13 of the Gatekeeper Head Agreement.

32.4 The Contractor shall use any Personal Information held in connection with this Head Agreement or a Contract only for the purposes of fulfilling its obligations under this Head Agreement or the Contract, as the case requires.

32.5 The Contractor shall not disclose any Personal Information obtained in connection with this Head Agreement or a Contract without the prior written approval of NOIE. The Contractor shall immediately notify NOIE where it becomes aware that a disclosure of Personal Information may be required by law.

32.6 The Contractor shall not transfer Personal Information held in connection with this Head Agreement or a Contract outside Australia, or allow parties outside Australia to have access to it, without the prior written approval of NOIE or the Customer, as the case requires.

32.7 The Contractor shall ensure that any of its employees or any sub-contractor, requiring access to any Personal Information held in connection with this Head Agreement or a Contract, before accessing that Personal Information, must:

(a) give a written undertaking not to access, use, disclose or retain Personal Information except in performing their duties of employment or as a sub-contractor; and

(b) be informed that failure to comply with the written undertaking may be a criminal offence and may also lead the Contractor to take disciplinary action against the employee and legal action against the sub-contractor.

32.7A Clause 32.7 shall not be read so as to prevent an employee or sub-contractor from using, for their own purposes, any information that it acquires independently of its employment or work for the Contractor.

32.8 The Contractor shall, in respect of any Personal Information held in connection with this Head Agreement or a Contract, immediately notify NOIE where the Contractor becomes aware of a breach of clauses 32.2, 32.3, 32.4, 32.5, 32.6 or 32.7.

32.9 The Contractor acknowledges that:

(a) any unauthorised and intentional access, destruction, alteration, addition or impediment to access or usefulness of Personal Information stored in any computer in the course of performing its obligations under this Head Agreement or a Contract is an offence under Part VIA of the Crimes Act 1914 (Cth) for which there are a range of penalties, including a maximum of ten years imprisonment; and

(b) the publication or communication of any fact or document by a person which has come to their knowledge or into their possession or custody by virtue of the performance of any of their obligations under this Head Agreement or a Contract (other than to a person to whom the Contractor is authorised to publish or disclose the fact or document) may be an offence under section 70 of the Crimes Act 1914 (Cth), the maximum penalty for which is two years imprisonment.

32.10 The Contractor shall in respect of any Personal Information held in connection with this Head Agreement or a Contract co-operate with any reasonable requests or directions of NOIE arising directly from, or in connection with the exercise of the functions of the Privacy Commissioner under the Privacy Act 1988 (Cth) or otherwise, including, but not limited to, the issuing of any guideline concerning the handling of Personal Information.

32.11 The Contractor shall indemnify the Commonwealth in respect of any liability, loss or expense which is incurred and which arises out of or in connection with a breach of the obligations of the Contractor or any sub-contractor of this clause 32 or for a breach of an obligation of confidence arising under the Privacy Act 1988 (Cth) except to the extent that the liability, loss or expense was caused by an act or omission of NOIE.

32.12 In clause 32.11 ‘liability, loss or expense’ includes any amount paid by NOIE on behalf of the Commonwealth for an interference with the privacy of an individual being a reasonable amount as compensation for loss or damage for which the Commonwealth would have been liable under the Privacy Act 1988 (Cth) if such breach had been that of a Commonwealth Agency.

32.13 A complaint alleging an interference with the privacy of an individual in respect of any services performed under this Head Agreement or a Contract shall be handled by NOIE and in accordance with the following procedures:

(a) where NOIE receives a complaint alleging an interference with the privacy of an individual by the Contractor or any sub-contractor, it shall immediately notify the Contractor of only those details of the complaint necessary to minimise any breach or prevent further breaches of the above clauses;

(b) where the Contractor receives a complaint alleging an interference with the privacy of an individual by the Contractor or any sub-contractor, it shall immediately notify NOIE of the nature of the complaint but shall only release to NOIE Personal Information concerning the complainant with that person’s consent;

(c) after NOIE has given or been given notice in accordance with clause 32.13(a) or clause 32.13(b), it shall keep the Contractor informed of all progress with the complaint as relates to the actions of the Contractor in connection with the allegation of an interference with the privacy of an individual; and

(d) NOIE shall give the Contractor 10 Business Days written notice of an intention to assume a liability, loss or expense in accordance with this clause 32 including in that notice an explanation of how that liability loss or expense was assessed and the Contractor’s proposed share of that liability.

32.14 This clause 32 shall continue to have effect after the termination or completion of this Head Agreement or a Contract.

32.15 The operation of this clause 32, in relation to a particular Customer, is to be read in conjunction with the terms of the Contract with that Customer.

Appendix 5 - Privacy Recommendations to the CEO, NOIE, regarding the use of Gatekeeper Certificates by Individuals

The Government Public Key Authority (GPKA) made the following recommendations to the Chief Executive Officer of the then Office for Government Online (OGO) (now NOIE) in May 2000. The recommendations were accepted and have been incorporated into Gatekeeper policy and form part of the accreditation requirements for subsequent Gatekeeper service and service provider accreditations.

The GPKA (now GPAC) provides advice on Gatekeeper policy including privacy, and includes a specialist privacy member who is able to reflect community and consumer interests. NOIE has accepted the advice of GPAC in relation to situations where an individual subscriber (the ‘user’ or ‘end user’) of a Commonwealth agency is using a Gatekeeper accredited digital signature certificate to support online transactions with the Commonwealth agency.

A5.1 Multiple Use of Key-Pairs or Certificates

Gatekeeper requires a PKI design that embodies subscriber choice:

to enable use of the same certificate pairs for multiple purposes or multiple certificate pairs for separate purposes, provided separate key-pairs are used for digital signature (authenticity) and confidentiality;
so that in cases where subscribers have multiple certificates and where relying parties may accept one or more of these, a subscriber may choose which certificate he or she will provide to the relying party.

A5.2 Key-Pair Generation

Gatekeeper requires a PKI design that ensures that the key-pair which constitutes the signature will be generated and distributed in such a way that:

the private key is only available to its owner
precludes (in the case of a subscriber operating as a private person) any person other than the owner from ever being in possession of a private authentication key without the owner’s consent; and
the certifying authority can be satisfied that the public key corresponds to the owner’s private key.

This would normally allow a subscriber the option of generating his or her own private key. An agency may decline to accept a digital signature if the generation process is not compliant with established quality or standards and end-user product key generation accreditation if applicable.

A5.3 Personal Choice as to Issuers of Certificates and Tokens

Gatekeeper requires a PKI design that embodies subscriber choice in relation to both the accredited issuer of certificates and the private key and certificate storage, or contains other forms of safeguard that provides equivalent subscriber protections.

Note: The Gatekeeper strategy expects, over time, to accredit a mature market of PKI service providers from which end subscribers and relying parties may select a service provider based upon individual privacy and business concerns. The strategy will provide subscriber choice also in terms of private key and certificate storage between physical tokens, storage on their hard disk or other means made available by evolving technology.

A5.4 Personal Possession and Control of Tokens

Gatekeeper requires a PKI design that incorporates subscriber possession and control of tokens, such that the issuer may cancel the validity of a token it has issued but may not compulsorily repossess the private key.

A5.5 Pseudonymity

Gatekeeper requires a PKI design that enables individuals to:

choose to use any distinguished name in a certificate, except where it would be impractical to do so.
conduct pseudonymous transactions except where the agency demonstrates that it is impractical to do so.

Note: Gatekeeper does not generally support anonymous transactions, because it is an authentication framework, and authentication is not possible in the conduct of anonymous transactions. EOI is required to obtain a Gatekeeper certificate. There may, however, be technologies and processes other than PKI that agencies may consider using to allow individual subscribers to deal securely and anonymously with them.

A5.6 Key Revocation

Gatekeeper requires a PKI design that incorporates effective privacy controls over the information contained in CRLs and how CRLs are accessed and searched.

Note: This means for example that, while revocation of a certificate must be published in a CRL, the reasons for revocation or suspension must not be disclosed. Also, access to a Certificate Directory or CRL will generally be limited to single searches.

A5.7 Non-Intrusive Identification Processes

Gatekeeper requires a PKI design that ensures that individuals are only subjected to appropriate identification procedures to meet agency authentication requirements or to satisfy applicable law and that intrusive procedures are minimised to the greatest extent possible.

A5.8 Centralised Storage of Identification Details

Gatekeeper requires a PKI design that ensures that there is no single centralised storage of PKI distinguished name or identification details.

Note: The Gatekeeper strategy has created a framework whereby the storage of personal information needed for identification is diffused between the RA and the CA, in order to prevent centralised storage. Both of the bodies are bound to observe the Information Privacy Principles, and there are limitations on information that an RA can pass to a CA.

A5.9 Freedom from Appropriation and Cancellation of Identity

Gatekeeper requires a PKI design that ensures a person’s identity cannot be appropriated, cancelled or compromised within the PKI structure.

Note: The Gatekeeper accreditation process requires that service providers bind end subscribers to a subscriber agreement obligating them to adequately protect their private key. Also, Gatekeeper expects CAs to prescribe minimum authentication requirements for the lodgement of certificate revocation requests.

A5.10 Status

These recommendations have been accepted by the CEO, NOIE and now have the force of Gatekeeper policy. They have been incorporated into the appropriate Gatekeeper accreditation requirements.

Appendix 6 - List of Consulted agencies

The following agencies, including ACT Government, were consulted during the development of this draft Paper.

Health Insurance Commission
Australian Taxation Office
Centrelink
Department of Employment, Workplace Relations and Small Business
Department of Education and Youth Affairs
Australian Customs Service
ACT Local Government

Appendix 7 - List of Reference Group Members

Below is a list of public and private agencies who are members of the Reference Group.

Health Insurance Commission
Health e Signature Authority
Australian Taxation Office
Centrelink
Certification Forum of Australasia
Australian Retailers Association
Mr Tim Dixon
Australian Consumers’ Association
Internet Society of Australia

Appendix 8 - Glossary

TERM	DEFINITION
Certificate	An electronic document signed by the CA which: (1) identifies a Key-holder and the Organisation he or she represents; (2) binds the Key-holder to a Key Pair by specifying the Public Key of that Key Pair; and (3) should contain the other information required by the Certificate Profile
Certification Authority (CA)	A body that signs and issues digital certificates which bind subscribers to their private keys.
Certificate Directory	The published directory listing Certificates currently in force.
Certificate Policy (CP)	The document which describes the PKI and the roles, functions and obligations of PKI Service Providers and End Entities (with reference to other Accredited Documents where appropriate)
Certificate Profile	The specification of the fields to be included in a Certificate and the contents of each, as set out in section 7.1 of the CP.
Certificate Revocation List (CRL)	The published directory which lists revoked and/or suspended Certificates. The CRL may form part of the Certificate Directory or may be published separately.
Certification Practice Statement (CPS)	The document that describes the operational practices of the CA in relation to its Certification Services.
Certification Services	Issue of Certificates and other functions performed by the CA under the CP.
Commonwealth	The Commonwealth of Australia.
Compromise	A situation in which the secrecy of a Private Key cannot be relied on, e.g. if there has been unauthorised access to the cryptographic module in which the Private Key is stored or used, or unauthorised access to or loss or theft of media on which the Private Key is stored.
Digital signature	An electronic signature created using a Private Signature Key.
Distinguished Name	A unique identifier assigned to each Key-holder, having the structure required by the Certificate Profile.
Electronic signature	A data element associated with a message that identifies a person and indicates their approval of the contents of the message.
End Entity	An entity, which uses Keys and Certificates for creating or verifying digital signatures or for confidentiality. End Entities are Key-holders, Organizations or Relying Parties.
EOI	Evidence of Identity
EPL	Endorsed Products List
Gatekeeper Accreditation	Accreditation by NOIE, granted on the basis that the CA meet the criteria set out in the Gatekeeper Report.
GPAC	Gatekeeper Policy Advisory Committee
Gatekeeper Report	Gatekeeper: A strategy for public key technology use in Government published by the National Office for the Information Economy. Also available at www.govonline.gov.au.
IPP	Information Privacy Principles
Key	A data element used to encrypt or decrypt a message - includes both Public Keys and Private Keys.
Key-holder	An individual who holds and uses Keys and Certificates on behalf of an Organization, including an Authorised Officer.
Key Pair	A pair of asymmetric cryptographic Keys (i.e. one decrypts messages which have been encrypted using the other) consisting of a Public Key and a Private Key.
NEAC	National Electronic Authentication Council
NOIE	National Office for the Information Economy
NPP	National Privacy Principles
OFPC	Office of the Federal Privacy Commissioner
PGP	Pretty Good Privacy
PKI Service Provider	Any entity, which has roles, functions, obligations or rights under the CP, other than an End Entity. PKI Service Providers include the RCA, Specification Administration Organizations, the CA and Subordinate Entities.
Private Key	The half of a Key Pair that must be kept secret to ensure confidentiality, integrity, authenticity and non-repudiation of messages.
Public Key	The half of a Key Pair, which may be made public.
Public Key Infrastructure (PKI)	The particular implementation of Public Key Technology described in the CP and other Accredited Documents, under which Keys and Certificates are issued and used.
Public Key Technology (PKT)	An encryption scheme, introduced by Diffie and Hellman in 1976, where each person gets a pair of keys, called the public key and the private key. Each person’s public key is published while the private key is kept secret. Messages are encrypted using the intended recipient’s public key and can only be decrypted using their private key. This is often used in conjunction with a digital signature.
Registration Authority (RA)	An Entity which registers applicants for Keys and Certificates (see Registration). RAs may have other functions or obligations specified in the CP.
Relying Party	An individual or entity that receives a digitally signed message and wishes to rely on the contents of that message as binding the signer.
TFN	Tax File Number

Appendix 9 - Reading and Reference Sources

Primary Sources

Privacy Act 198

Electronic Transaction Act 1999

Privacy Amendment (Private Sector) Act 2000

Secondary Sources

Austin, T	PKI – A Wiley Tech Brief, Wiley Computer Publishing, United States 2001
Brands, S	Rethinking Public Key Infrastructures and Digital Certificates: Building in Privacy , MIT Press 2000.
Boufford, J	'I.S.P., President of e-Privacy Management Systems' , at* http://www3.sympatico.ca/john.boufford/about.htm.*
Clarke, R	http://www.anu.edu.au/people/Roger.Clarke/DV/PIA.html
Stewart, B	‘Privacy impact assessment: towards a better informed process for evaluating privacy issues arising from new technologies’ in Privacy Law & Policy Reporter 5, 8 (February 1999) Office of the Privacy Commissioner New Zealand, 3 Privacy Law & Policy Reporter (1996) http://www.austlii.edu.au/au/other/plpr/vol3/vol3No04/v03n04a.html
US IRS News Releases	‘IRS PIA Endorsed as Government-Wide Best Practice’ at http://taxboard.com/Tax-News/2000/nr00-29.html
	‘PIAs – an early warning system’, (1996) 3 PLRP 134, http://www.austlii.edu.au/au/other/plpr/vol3/vol3No07/v03n07f.html
	‘Introduction, Information and Privacy Commissioner’, Alberta, Canada, http://ipc.developersedge.com/privacy_impact/welcome.htm
	‘Instructions and Annotated Questionnaire, Office of the Information and Privacy Commissioner’, Alberta, Canada, http://www.oipc.ab.ca/

Web sites

http://www.pgpi.org/

http://www.media-awareness.ca/eng/issues/priv/resource/forumrpt.htm#National

http://www.maxi.com.au

http://www.ilpf.org/digsig/analysis_IEDSII.htm

http://www.unites.uqam.ca/cirst/Documents/Notes_recherche/b_godin.html

http://www.ik.sote.hu/oktatas/related/p418_2.htm

http://www.centc251.org/WItems/PT/37/PT37INR1.doc

http://www.uspto.gov/ebc/

[1] For definition of ‘personal information’, see section 6 of the Privacy Act 1988

[2] It is open to the holder of a private key to show that as a matter of fact they did not send the message encrypted with their private key (for example, by showing that the private key was copied, ‘stolen’ or used without authority). However, as with a document that has purportedly been signed with a person’s handwritten signature, it will be up to the subscriber to show that their ‘signature’ was ‘forged’.

[3] However, the Electronic Transaction Act 1999 (which comes into operation on 1 July 2001) allows for a digital signature to be treated as equivalent to a hand-written signature.

[4] http://www.pgpi.org/

[5] For a detailed discussion of blinded certificates see Stefan Brands, Rethinking Public Key Infrastructures and Digital Certificates: Building in Privacy, MIT Press 2000.

[6] PIAs, Blair Stewart, Office of the Privacy Commissioner New Zealand, 3 Privacy Law and Policy Reporter (1996) 61, http://www.austlii.edu.au/au/other/plpr/vol3/vol3No04/v03n04a.html. "...even if the future requires a trade off in privacy in favour of some other material benefit a PIA allows us to make such choices rationally and with our eyes open as to their privacy ‘downside’": PIAs – an early warning system, Blair Stewart, (1996) 3 PLRP 134, http://www.austlii.edu.au/au/other/plpr/vol3/vol3No07/v03n07f.html.

[7] John Boufford, I.S.P., President of e-Privacy Management Systems, http://www3.sympatico.ca/john.boufford/about.htm. See also A2.7 below.

[8] PIAs, Stewart (1996), op cit.

[9] IRS PIA Endorsed as Government-Wide Best Practice, US IRS News Releases, http://taxboard.com/Tax-News/2000/nr00-29.html

[10] PIAs, Roger Clarke, 1999, http://www.anu.edu.au/people/Roger.Clarke/DV/PIA.html

[11] PIA: Introduction, Information and Privacy Commissioner, Alberta, Canada, http://ipc.developersedge.com/privacy_impact/welcome.htm; PIA: Instructions and Annotated Questionnaire, Office of the Information and Privacy Commissioner, Alberta, Canada, http://www.oipc.ab.ca/

[12] "Eighty percent of respondents agreed with the statement that companies developing new information technologies should be required to assess their impact on privacy before the new technologies are made available to the public." Privacy Forum online survey (266 people responded to the online survey), http://www.media-awareness.ca/eng/issues/priv/resource/forumrpt.htm#National

[13] If a definition is required one is included in >the Privacy Amendment (Private Sector) Act 2000

[14] GK 12 and GK Supplementary E – see section 6.4.

[15] See GK Supplementary F.

[16] http://www.maxi.com.au

[17] This case study is loosely based on the Maxi system in Victoria.