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.

[Index | Chapter 1 index | Chapter 2 index | Chapter 3 index |