Search the Archive

The Australian Government Information Management Office Archive

Gatekeeper® Type 3 Certificate - Broad Specification

1 Introduction

The Government seeks to utilise its position as a leading edge user of information technology and telecommunications systems to support the take-up of online technologies across the Australian economy.

The Government continues to address specific impediments to broad Internet use. Measures to date include:

• the Electronic Transaction Act 1999 (Cth) which recognises the validity of online transactions; and
• the implementation of the Gatekeeper Strategy to ensure a whole-of-government framework to facilitate authentication, non-repudiation, confidentiality and security for online transactions.

Gatekeeper® is the Commonwealth Government's Public Key Infrastructure (PKI) strategy. It was set up to provide a mechanism for the implementation of Public Key technology by Agencies and enables them to choose from a panel of accredited service providers. The Gatekeeper® evaluation and Interoperability (Recognition) processes ensure that the products of, and methods of delivery used by Certification Authorities (CAs) and Registration Authorities (RAs) comply with appropriate Commonwealth policies and meet prescribed government standards for integrity and trust.

1.1 Gatekeeper® Certificates

Maintenance of the Commonwealth's requirements for administrative control of cryptographic products was one of the early issues to be addressed in introducing PKI for government use.

These requirements were referenced in the Commonwealth's Protective Security Manual (PSM) and a number of Defence Signals Directorate (DSD) related Australian Communications-Electronic Security Instructions (ACSI) documents. The international standards released by the Internet Engineering Task Force (IETF) through Request For Comment (RFC) 2527 required a process for administrative control of Certificates that the Commonwealth could implement and at the same time satisfy PSM requirements.

The PSM guidelines require that cryptographic products be appropriately controlled. The evidence of identity (EOI) process carried out by an RA, the naming of the individual in a Certificate and proof of possession requirements, all ensure that responsibility for control of the cryptographic product (through the Certificate) is appropriately implemented for Commonwealth purposes.

Type 1 (Individual) Certificates satisfy this requirement.

The original concept for a Type 2 Certificate was based on the need for a class of non-individual Certificates for users who require that their digital signature identify them as an Organisational entity. These Certificates are used where identifying the person as an agent of an Organisation is more appropriate than identifying the individual filling the role.

A need was subsequently expressed for increased flexibility to enable Certificates to be issued for use by multiple Key Holders within any Organisation. This resulted in implementation of the Australian Business Number-Digital Signature Certificate (ABN-DSC) which complements the continued use of the "non-individual" Type 2 Certificates.

PSM requirements necessitate that an individual undertake responsibility for administrative control of ABN-DSC Certificates on behalf of an Organisation. In the case of the ABN-DSC, the Authorised Officer is given responsibility o act on behalf of the Organisation and to vouch for the identity of all representatives within the Organisation for whom applications to hold ABN-DSCs are made. Each individual named in the Certificate accepts responsibility for administrative control of each Certificate, thereby meeting Commonwealth PSM requirements.

1.2 Electronic applications

Gatekeeper® to date has focussed on the issuance of Certificates to human entities. However it is evident that this strategy needs to be modified to cater for those electronic transactions that take place with no human involvement. Increasingly, electronic applications require Certificates to ensure authentication, integrity (hence non-repudiation) and confidentiality. Examples of common use applications include web servers and Virtual Private Networks (VPNs). Additionally, the use of Certificates in applications is extending to include authenticated and non-repudiable automated responses, eg. automatic issuance of electronic receipts. NOIE has identified a market need for the development of a Certificate to be used in transactions that do not require human intervention, to be called the Gatekeeper® Type 3 Certificate.

1.3 This document

This document provides a Broad Specification for Type 3 Certificates that may be adopted by Organisations wishing to issue or use Type 3 Certificates. It is recognised that the model may need to be varied to suit different applications and circumstances. It is envisaged that in time there will be Gatekeeper® Type 3 Certificates in the market meeting the minimum requirements of this specification, but varying in other features.

This document outlines the benchmark for those seeking Gatekeeper® evaluation of their Type 3 Certificate Policies (CPs). Each CP will be compared against the minimum specifications set out in this document and evaluated on a case-by-case basis.

Devices or applications belonging to Organisations of any kind may use Type 3 Certificates. For the purpose of this Broad Specification, the term Organisation will be used to refer to government, business and not for profit entities, whether or not they have an ABN.

Terms used in this document are defined in the glossary at Attachment A.

2 What is the Type 3 Certificate?

2.1 Policy Objective

The concept for the Type 3 Certificate originates from the Prime Minister's 1997 Investing for Growth statement in which the government sought to use its position as a leading edge user of IT to help get Australia online. The required policy objectives are to:

• foster trust in electronic transactions between business and government (B2G) and between business and business (B2B); and
• facilitate growth of the information economy.

2.2 Policy Specification

The Type 3 Certificate specification defines a class of Certificate that:

• will be used by Organisations to identify applications and/or devices;
• an Organisation can use to interact electronically with other Organisations;
• will be based on the X.509 standard; and
• will be able to be issued by any Gatekeeper® fully accredited Certification Authority (CA) or Gatekeeper® recognised PKI Service Provider.

2.3 Concept

The Type 3 Certificate broad specification sets the minimum requirements for a Certificate to be used within electronic applications. Ensuring trust and confidence in the use of the Gatekeeper® Type 3 Certificates is the paramount objective of this Broad Specification.

The Type 3 Certificate has been developed in response to a need expressed by industry. It is a class of Certificates suitable for use where an Organisation requires a Certificate for:

• an application or process; and/or
• its device or server to invoke a protocol for use by applications, eg. IPSec or SSL.

Existing Gatekeeper® Certificates are available in two separate types: Type 1 (Individual) and Type 2 Certificates (Non-Individual), each having three grades. These Certificates are based on the manner by which the holder of the Certificate is to be identified. The grades relate to the extent to which the status of the holder is verified (and can therefore be trusted).

• Type 1 (Individual) Certificates are available for users who require that their digital signature identifies or authenticates them personally. Typically, individual Certificates will be used for personal transactions involving the delivery of government services such as claiming benefits, enrolling to vote, lodging a tax return or applying for a job.
• Type 2 (Non-Individual) Certificates are available for users who require that their digital signature identify them as an Organisational entity.
  Non-individual Certificates would, for example, be used when transactions are to be signed on behalf of an Organisation by people filling certain roles, or holding particular authorisations or delegations. Examples include a purchasing officer, a managing director, or a branch head, where the identification of the Organisation is more important than identifying the individual filling the role.

The ABN-DSC (a variation of the Type 2 Grade 2 Certificate) is intended for use by government agencies to authenticate and conduct electronic transactions with business entities that have an ABN (including sole traders) and will also be used by Agencies for Government to Government (G2G) transactions. This enables a range of regulatory and commercial transactions to be undertaken online, however, the ABN-DSC will not be used for transacting online business with individuals.

In contrast to current Gatekeeper® Certificates, the Type 3 Certificate will not authenticate human entities. Type 3 Certificates will enable authentication of applications or devices including processes and services, PCs, servers and routers by other devices or applications. This obviously requires changes in current Gatekeeper® Evidence of Identity (EOI) requirements and RA processes.

2.4 Features

The Type 3 Certificate will be a Gatekeeper® compliant Certificate used to identify an application or devices including a process or service that is owned and/or operated by an Organisation.

All CAs wishing to issue Type 3 Certificates must be Gatekeeper® accredited to do so. Accredited CAs are listed on the NOIE website at http://www.noie.gov.au/projects/confidence/Securing/GatekeeperAccreditation.htm

Type 3 Certificate Policies (CP) developed by CAs must be evaluated prior to the Type 3 Certificate being issued. The same rigour that is applied to the Type 1 and Type 2 Gatekeeper® Certificates will be applied to the Type 3 Certificate. Type 3 CPs are expected to meet the standards of other Gatekeeper® CPs.

This Broad Specification satisfies both the need for the Type 3 to be a device/application Certificate and the PSM requirement for an individual to take responsibility for it. The individual responsible for the Certificate will not be evident (ie. he/she will not be named in the Certificates). Accordingly, a management process has been developed to ensure that an individual "manages" the Certificate on behalf of the Organisation, and that the individual is linked to the Organisation by the authorisation process described in section 3 - Process for Confirmation of Organisation and Authorised Officer.

3 Process for appointing and authorised officer

Before a CA will issue Type 3 Certificates to an Organisation, it needs to be confident that the person who is requesting the issue of Certificates is an agent of the Organisation and that the Organisation will be responsible for all aspects of the Certificates. In order for the CA to achieve this level of confidence, and before a CA will issue a Type 3 Certificates for installation into an application or a device within an Organisation, the following must be confirmed:

• the existence of the Organisation;
• the identity of the person authorised to install and manage the Certificate on behalf of the Organisation (the Authorised Officer); and,
• the authority of the Authorised Officer to request, accept, install and manage Certificates on behalf of the Organisation.

The process below describes how this can be achieved.

3.1 Aim

The aim of the process is to bind:

• the registered business name to the Organisation;
• the Authoriser to the Organisation;
• the identity of the Authorised Officer to a physical person; and
• the Authorised Officer to the Organisation.

3.2 Authoriser

3.2.1 Role

The Authoriser is a person within an Organisation that provides the Authorised Officer with the authority to fulfil their role (refer 3.3).

Persons filling the role of Authoriser must be able to demonstrate a clear capacity to commit the Organisation, and to empower an Authorised Officer on behalf of the Organisation.

Persons who are members of this class include:

• Chief Executive Officer
• Company Director
• Trustee
• Partner
• Company Owner

3.2.2 Eligibility

The Authoriser's association with the Organisation must be able to be evidenced by reference to:

• an authoritative public register; or
• appropriate legal, or regulatory documents issued by a government Agency (see section 3.4.3 sub paragraph 5).

3.2.3 Function

The Authoriser will appoint an Authorised Officer to act on behalf of an Organisation for the purpose of:

• identifying and locating devices/applications upon which Certificates are installed;
• requesting issuance of Certificates as required;
• accepting Type 3 Certificates on behalf of the Organisation;
• ensuring that Type 3 Certificates are initially installed on the appropriately identified Applications; and,
• managing Type 3 Certificates on devices/applications within the Organisation.

3.3 Authorised Officer

3.3.1 Role

The Authorised Officer is an individual who has been given responsibility for requesting, accepting, installing and managing Type 3 Certificates on behalf of an Organisation.

3.3.2 Eligibility

An Organisation may have one or more Authorised Officers. A small Organisation may have only one Authorised Officer while a large or decentralised Organisation may choose to appoint additional Authorised Officers for practical operational purposes. Given the critical role played by the Authorised Officer in the installation and management of Type 3 Certificates for an Organisation, the allocation of such positions must be strictly managed by the Organisation.

The Authorised Officer as described above and the person providing the Authorised Officer with that authority (the Authoriser) may be one and the same person, particularly in a small Organisation.

A person appointed by the Organisation as an Authorised Officer cannot appoint other Authorised Officers unless the person is also an Authoriser.

3.3.3 Function

The person fulfilling the role of Authorised Officer (this would normally be an officer or employee of the Organisation) will be duly authorised by the Organisation, or by law to:

(a) Identify devices / applications
- Accurately identify and locate devices/applications upon which Certificates are to be installed

(b) Request issuance of Certificates as required
- submit an application for a Type 3 Certificate
- request additional Type 3 Certificates as required for use by the Organisation

(c) Accepting Type 3 Certificates
- Accept Type 3 Keys and Certificates on behalf of the Organisation

(d) Manage Installation of Certificates, and
- Ensure that Keys and Certificates are installed on the identified device/application.

(e) Manage devices / applications
- Manage Type 3 Certificates on devices/applications within the Organisation, and
- Maintain the security of Type 3 Keys and Certificates within their Organisation

The Authorised Officer must be able to show evidence of such authorisation by reference to one or more documents, which permit or instruct the Authorised Officer to perform all the activities listed above and which are signed by an Authoriser. Section 3.4.3, sub-paragraph 3 describes documentation acceptable for this purpose.

3.3.4 Security Clearance of Authorised Officer

Depending on the particular Certificate Policy, a Type 3 Certificate can be used to identify essential communications equipment, protect applications or ensure the security of information routed through the devices upon which it resides.

Users may utilise a number of different Certificates on the same desktop for the transmission of information with varying levels of security classification. Classified information sent from desktops may be routed through devices upon which Type 3 Certificates reside. Accordingly, there is a likelihood that information to the Protected level (eg. transfer of Cabinet-In-Confidence material) may, at times, be passed through devices / applications holding Type 3 Certificates.

Accordingly, agencies with a requirement to transmit information with a high security classification may wish to ensure that the Authorised Officer responsible for installation and management of their Type 3 Certificates is cleared to at least the Protected level.

3.4 The Authorisation Process

3.4.1 Registration Authority

Before responding to an Authorised Officer's request for a Type 3 Certificate, a CA must satisfy itself that the person claiming to have been nominated by an Organisation as an Authorised Officer has the full backing of that Organisation.

To achieve this the CA relies upon an RA acting as its agent to carry out the non-individual 100 point EOI checks described in section 3. The EOI process enables the CA to be confident that it is dealing with an authorised agent of the Organisation. The RA also assists the CA by processing subsequent requests for the Type 3 Certificates submitted by the Authorised Officer.

3.4.2 Evidence of Identity Requirements

A non-individual EOI check to the value of at least 100 points is required to ensure that:

• the identity of the Organisation is verified;
• the identity of the Authorised Officer is verified;
• the relationship of the Authoriser to the Organisation is verified; and,
• the person nominated by an Organisation to fulfil the role of Authorised Officer is empowered by the Organisation to undertake this role.

This requirement recognises the pivotal role of the Type 3 as well as the need for it to be tightly bound to an Authorised Officer with appropriate security clearance.

This non-individual 100 point EOI requirement is similar to the EOI required for the Authorised Officer in relation to an ABN-DSC. However, the Type 3 process is not undertaken for the purpose of the CA issuing Keys and Certificates to the Authorised Officer.

If the Authorised Officer is already in possession of a Gatekeeper® Type 2 Grade 2 Certificate, the Authorised Officer can use it to send a signed and encrypted e-mail to the CA containing all relevant information requesting issuance of the Type 3 Certificate. In this instance the use of the Gatekeeper® Type 2 Grade 2 Certificate will satisfy EOI requirements. However, documentation confirming the Authorised Officers authority to perform this particular role on behalf of the Organisation will still be required.

3.4.3 Indicative Procedure for the Non-Individual 100 Point EOI Check

1 The Organisation applies to the CA (or directly to an RA depending on the business model adopted by the CA) for a Certificate. The Organisation should indicate in its application (mail, email, or online) as much information about itself as possible to allow preliminary non-individual 100 point EOI check to begin.

For example:

• Provide the registered business name for the Organisation;
• Provide the Organisation ABN (if applicable);
• Provide both postal and street addresses; and
• Provide both phone and facsimile numbers.

2 The CA/RA would provide, or in an online environment allow the completion of, an application, individually identified with a unique serial number or other such individually recognisable indicator.

3 The Organisation would provide a hardcopy signed letter, or an email signed with a Gatekeeper® Certificate from an Authoriser stating the name of the Authorised Officer (that is the person authorised to apply for Type 3 Certificates on behalf of the Organisation and to whom responsibility for the management and installation of the Type 3 Certificates will be given).

4 The Authorised Officer will bring this letter, together with the completed application and relevant documentation to the RA for a formal face-to-face EOI check to enable the non-individual 100 point EOI requirement to be satisfied.

Relevant documentation that the Authorised Officer must provide includes the following:

(a) A Letter from the Authoriser addressed to the Authorised Officer, stating the name of the Authorised Officer and permitting or instructing the individual to perform all custodial activities associated with the Type 3 Certificate (binds the Authorised Officer to the Organisation); and

(b) A legal or regulatory document binding the Authoriser to the Organisation, and binding the Authoriser to a clear capacity to nominate an Authorised Officer on behalf of the Organisation (binds the Authoriser to that Organisation); or

(c) An original or certified copy of the notice issued by the Registrar of the Australian Business Register (ABR) bearing the Organisation's name and the Australian Business Number (ABN). This document alone will satisfy points a). and b). above if the Authoriser is named in the document (confirms the existence of the Organisation)

5 The RA would check the documentation binding:

• the Authoriser to the Organisation;
• the Authorised Officer to the Organisation; and
• the physical person of the Authorised Officer to the name provided by the Authoriser.

Note: The non-individual 100 Point identification check required for the Authorised Officer is obtained using the Financial Transaction Reports Act 1998 (Cth) Identification Record for a Signatory to an Account. Annex P to the Gatekeeper® strategy contains a list of documentation recognised by Gatekeeper®. These documents are appropriate for use with the Type 3 non-individual 100 point EOI process for Authorised Officers.

The RA may also choose to utilise online facilities or third party services to provide additional checks on legal or regulatory records/documents.

6 Once the RA (on behalf of the CA) has completed the non-individual 100 point EOI check, the RA will notify the CA (or the CA's Organisational representative) of the outcome of the process. If the Authorised Officer is 'verified', the CA records the fact that it is able to accept requests for Type 3 Certificates from a particular Authorised Officer. The Authorised Officer can then begin to lodge Certificate requests and commence carrying out the roles described in section 3.3.3 on behalf of the Organisation.

4 Requesting and issuing Type 3 Certificates

A Type 3 Certificate may be issued to any Organisation that wishes to conduct electronic transactions via an automated or device-based process.

Due to the nature of Type 3 Certificates it is envisaged that the Organisation will have had a number of discussions with the CA prior to Certificate requests taking place.

The Organisation will accept full responsibility for these Certificates and will be expected to put in place appropriate procedures for ensuring a full documentary trail is maintained for the issue of these Certificates.

CAs may choose to initiate specific arrangements with the Organisation in regard to responsibility and liability for these Certificates.

Only CAs that have been granted full accreditation under the Gatekeeper® strategy can issue Type 3 Certificates. Gatekeeper® accredited CAs granted full accreditation prior to the Type 3 Certificate Broad Specification being released on 16 July 2002 will have to undergo evaluation in relation to the Type 3 Certificate if they wish to issue them.

4.1 Management of Certificates

An Organisation takes full responsibility and liability for the installation, management and use of its Type 3 Certificates. Appropriate Certificate management processes need to be in place to:

• manage how Certificates are requested;
• ensure that Certificates are allocated to the correct application;
• manage what restrictions are placed on the use of Certificates; and,
• manage the issue of new Certificates and revocation of existing Certificates.

4.2 How might a Type 3 Certificate be issued?

The issue of Certificates to Organisations that wish to conduct electronic transactions with agencies can take place in a number of ways, including:

• Agencies may commission a Gatekeeper® Accredited CA(s) to issue Type 3 Certificates to their devices/users to meet a particular business need;
• Agencies, if they are fully Gatekeeper® accredited, may issue Type 3 Certificates directly to clients;
• Agencies may approach clients/business customers requesting that they acquire Type 3 Certificates from an accredited service provider;
• An Organisation may approach an Agency and/or a Gatekeeper® Accredited CA for a Certificate to be used with agencies.

4.3 Indicative process for requesting and issuing Type 3 Certificates

A Type 3 Certificate may be issued to any Organisation that wishes to conduct electronic transactions using an automated or device-based process. The following outlines a model that may be adopted by Organisations wishing to use Type 3 Certificates. It will be used as the benchmark for Gatekeeper® Type 3 evaluation.

Step 1

Prior to requesting a Type 3 Certificate, the Authorised Officer will need to have successfully completed the process outlined in section 3.

Step 2

The CA/RA will provide - or in an online environment allow the completion of - an application that is individually identified with a unique serial number or other such individually recognisable indicator.

The application method and information required is dependent on the type of device/application into which the Certificate will be installed (ie. automated secure email, IPSec, web server Certificate). The type of device/application may also restrict how much information can be supplied; for example the Organisation may wish to use the SCEP to enrol for IPSec Certificates. It is envisaged that the following enrolment methods will cater for the majority of cases:

• Submission of a CSR in PKCS #10 format (refer http://www.rsasecurity.com/rsalabs/pkcs/pkcs-10/index.html)
• Submission via a standard enrolment session

Step 3

A formal application for a Type 3 Certificate containing only that information necessary for the creation of a Type 3 Certificate is forwarded to the CA. The RA will retain the non-individual 100 point EOI documentation.

If the Authorised Officer has a Type 2 Grade 2 Certificate (minimum), the Authorised Officer will send a signed and encrypted e-mail to the CA containing all relevant information, requesting issuance of the Type 3 Certificate. This information should include:

• Unique Certificate subject identifying information eg. router serial number;
• Details of the Certificate subject (eg. router model and make);
• Purpose for which the Certificate will be used (eg. IPsec device, Organisational e-mail at gateway);
• Organisational name and ABN in Certificate (if applicable); and,
• Name and contact details of the Authorised Officer.

Once the CA has checked and approved the application the Type 3 Certificate can be issued.

Step 4

Secure delivery of the Type 3 Certificate is then achieved in accordance with the evaluated process for that particular CA.

5 TYPE 3 Certificate policy and profile

This specification does not prescribe a specific Certificate Policy (CP) or Certificate Profile for the Type 3 Certificate. The Gatekeeper® model CP was developed for the Gatekeeper® Type 2 Grade 2 Certificate and as such it does not contain the type of Authorised Officer described in this specification. The Type 3 Certificate Profile must comply with the X.509 standard.

5.1 Type 3 Certificate Policy

Due to the range of applications in which a Type 3 Certificate may be used, it is not possible to define a common CP. However, CAs should maintain the maximum possible degree of consistency with the Gatekeeper® model when issuing their own versions of the Type 3 Certificate.

Gatekeeper® evaluation of CA's Type 3 CPs must be finalised prior to Certificates being issued. The differences in products being offered by CAs should be readily identifiable from the CPs.

This approach has been taken to provide Subscribers and Relying Parties with a high level of certainty regarding the benefits and obligations inherent with the use of the Type 3 Certificate while allowing a degree of flexibility for service providers.

5.2 Type 3 Certificate Profile

The Type 3 Certificate is a standard Certificate. It must comply with the broad international X.509 (see glossary) standard and the draft Australian standard AS 4539 (see glossary) for Certificates.

It will not be possible for CAs to maintain absolute consistency with the existing Gatekeeper® Certificate Profile as it has been designed to identify individuals. As with CPs, CAs' Type 3 Certificate Profiles must be evaluated under Gatekeeper® prior to Certificates being issued.

5.3 Use of the Private Certificate Extension

Latitude exists for Organisations to request additional information be included within the private Certificate extension (for example, the Organisation's ABN).

However, if the additional information is included, it should be noted that this extension should be marked non-critical so as to maximise the interoperability with other applications.

5.4 Examples of Type 3 Certificates

The following applications are expected to be the most common uses for Type 3 Certificates. It is important to note that Type 3 Certificates will not be limited to installation and use within these environments:

• Web server Certificates;
• Virtual Private Networks (VPN); and
• Automated email.

There will be significant differences between the policies and profiles for the Certificates used in each of these applications. These differences include, but are not limited to:

• Web server and email are typically issued from a public hierarchy while VPNs, by their very nature, must be issued from a private hierarchy.
• Web server Certificates and email applications will contain an Internet domain name that can be verified by a 3rd party provider (InterNIC). VPN's do not necessarily relate to a registered domain (an example being Fedlink).
• Technical restrictions on Certificate content based on the application or enrolment process, ie. a Certificate Signing Request (CSR) is automatically generated and submitted by a device for enrolment utilising Simple Certificate Enrolment Protocol (SCEP), with no opportunity to include additional identifying information.
• Technical restrictions on CA configuration i.e. Cisco Internet Protocol Security (IPSec) device Certificates must be issued from a single root (eg. cannot chain Certificates)
• The subject type identified within the Certificate will be different. For example a web server Type 3 Certificate subject will identify an Internet domain name, an automated email Type 3 Certificate will identify a specific application and email address whereas an IPSec Type 3 Certificate will identify the fully qualified domain name of the device.

5.5 Sample Type 3 Certificate (IPSEC Device Certificate)

The following is an example of a Type 3 Certificate:

EXTENSION	VALUE
Subject DN	C = AU S = NSW L = Sydney O = Engineering POC OU = PreProdIPSec CN = 48.212.144.36
Issuer DN	CN = eSign POC Test Root CA OU = eSign Proof of Concept Root OU = For Test Purposes Only O = eSign Australia Limited
Version	3
Serial Number	Serial number value
Signature Algorithm	Md5 RSA
Public Key	RSA 1024 bit key
Valid From	dd/mm/yy hh/mm/ss
Valid To	dd/mm/yy hh/mm/ss
Subject Alt Name	DNS Name=nwynvpn1.domainname.com.au
Basic Constraints	CA:FALSE MAX Path Len:N/A
CRL Distribution Point	URL=http://onsitecrl-test.esign.com.au/EngineeringPOCPreProdIPSec/LatestCRLIPSec.crl
Key Usage	Digital Signature Key Encipherment
Thumbprint Algorithm	Sha1
Thumbprint	Thumbprint value

6 Fees

Payment arrangements for the issue of Type 3 Certificates will vary depending upon the business application being addressed and the nature of the relationship between the Organisation and the Gatekeeper® accredited service provider.

This document does not specify a particular fee arrangement. This will need to be negotiated between an Organisation and the selected service provider.

7 Privacy

 

Privacy issues in regard to the Type 3 Certificate will be managed in a number of ways, including:

• Type 3 Certificates will only be issued by Gatekeeper® fully accredited CAs. The Gatekeeper® evaluation criteria requires strict adherence to the Privacy Act 1988 (Cth) including, as appropriate, the Information Privacy Principles and the National Privacy Principles;
• Gatekeeper® evaluation criteria also requires there to be no release by Ras of any personal information; and
• The Type 3 Certificate itself, developed under this specification, will contain no personal information.

8 Certification Revocation

Certificate Revocation Lists (CRLs) are the means by which Relying Parties confirm the status of a Certificate in order to decide whether to trust/accept that particular Certificate. Under Gatekeeper® evaluation criteria, CAs must maintain a complete and readily available CRL updated at regular intervals to enable Relying Parties to check the revocation status or validity of Certificates. It is recommended that Certificate status be checked on each occasion that a Relying Party receives a transmission or transaction.

8.1 Circumstances for revocation

Certificates should be revoked where any one of the following circumstances arise:

• a Private Key is compromised;
• media holding a Private Key is compromised or lost;
• the Key Holder ceases to represent the Organisation. The Key Holder in this instance is the device or application that holds the key on behalf of the Organisation;
• there has been improper or faulty issuance of the Keys and Certificates;
• the Certificate information becomes inaccurate;
• the relevant CA ceases to operate;
• the Organisation ceases to exist; or
• the CA receives a revocation request from an Authoriser or an Authorised Officer.

8.2 Who can request revocation

Type 3 Certificate revocation may be initiated by:

• the Authorised Officer;
• the Authoriser;
• authorised third parties such as third party service providers operating systems on behalf of the Organisation; or
• the relevant CA if it believes circumstances for revocation exist.

Organisations cannot initiate revocation action when acting as Relying Parties. This is because a Type 3 Certificate that is no longer recognised by one Organisation may be quite valid with others.

Organisations may initiate revocation of their own Certificates when acting as a Subscriber.

8.3 Revocation Process

A CA:

• publishes a notice of the revoked Certificate in the Certificate Revocation List (CRL);
• issues a notice to the subscriber confirming the revocation of the Keys and Certificate and the date and time that the Certificate is revoked. The notice need not include the reason for revocation;
• archives the revoked Certificate in accordance with the CP before removing the Certificate from the CRL; and
• provides access to Certificate status information via an approved X.509 compliant protocol (eg. DAP, LDAP or OCSP). CAs are not confined to using a single protocol for the distribution of Certificate information. It is the CA's responsibility to ensure information in Directories is synchronised.

The above arrangements are to be reflected in Subscriber Agreements between the CA and the Subscriber and in other documentation evaluated in accordance with the Gatekeeper® strategy and the CA's implementation of the Type 3 Certificate.

8.4 Certificate suspension

Suspension of a Type 3 Certificate will only be supported where the issuing CA supports this functionality.

8.5 Certificate renewal

Organisations holding Type 3 Certificates will be expected to manage the Certificate renewal cycle.

It is expected that Type 3 Certificates will have a default life of one year. However this may be modified depending on the application in which the Certificate resides and subject to the terms of the associated Certificate Policy. Only an Authorised Officer will be able to request Certificate renewal.

9 Record Archival

Type 3 Certificate private keys will not be held by the issuing Gatekeeper® accredited CAs.

Certificates shall be archived for a minimum period of seven years from the date they expire, unless an Organisation specifically requires a longer period.

Audit trail information shall be kept for a minimum period of seven years from the date of generation, unless the Organisation specifically requires a longer period Agency.

Archive media shall be protected either by physical security or a combination of physical security and cryptographic protection. It shall also be protected from environmental factors such as temperature, humidity, and magnetism.

Notwithstanding the above, archival of Certificate information may be subject to jurisdictional legislation and other legal constraints which may override the conditions described above.

10 Operation of Directories

Where appropriate, Gatekeeper® accredited CAs that issue Type 3 Certificates will be required to operate a directory structure that supports the issued Certificates. Because of the nature of Type 3 Certificates, the CA or Organisation may choose not to make the directory publicly accessible. As a minimum, CAs will operate standard X.500 directory services in accordance with ITU X.509 V3.

11 Interoperability

Interoperability issues will be addressed under the Gatekeeper® Strategy by Gatekeeper® evaluation processes, by adoption of the international X.509.V3 standard for the Type 3 Certificate and by implementation of the Gatekeeper® Accreditation Certificate (GAC).

The primary purpose of the Gatekeeper® strategy is to provide the trust hierarchy for X.509 Certificates within the Australian Government's domain.

12 Liability

This section sets out proposed legal liability positions appropriate for agencies using Type 3 Certificates. These positions seek to encourage service providers to avoid imposing onerous liability risks on Subscribers.

Liability will be determined under the relevant law in Australia that would be applied by the High Court of Australia.

The Commonwealth will not accept any liability for losses resulting from the use of a Type 3 Certificate where an Agency was not a party to the supported transaction.

Further, the Commonwealth makes no representation and offers no warranties or conditions, express or implied, in relation to:

• the activities or performance of any government PKI; or
• if relevant, the services or products of a particular PKI Entity.

Gatekeeper® accredited Service Providers, will be expected to fulfil their responsibilities as set out in Gatekeeper® evaluated CPs or Subscriber Agreements. They should therefore expect to be liable to their Subscribers or other Relying Parties for losses clearly due to their breach of those responsibilities, within any agreed liability limits.

Gatekeeper® evaluated CPs will also set out responsibilities for Subscribers and Relying Parties, notably to ensure private key security and to exercise due diligence in checking the validity of Certificates. Liability for losses incurred due to breaches of those responsibilities will generally be expected to lie with the party at fault.

More information on the Commonwealth's position with respect to liability can be found in Annex A - Legal and Privacy Issues with PKI of Online Authentication: A Guide for Government Managers at /publications/gol/onlineguidefinal.pdf (released 16 July 2002) and in the Gatekeeper® Strategy Update 2/2002.