AUSkey terms and conditions

On this page

• AUSkey Certification Practice Statement
• Certificate Policy – AUSkey
• Certificate Policy – Device AUSkey
• Conditions of use – AUSkey
• Conditions of use – Device AUSkey
• AUSkey Terms and Conditions Glossary

AUSkey Certification Practice Statement

1 Introduction

1.1 Overview

This document is the GKP002 Certification Practice Statement. A Certification Practice Statement (CPS) is a statement of the practices that a Certification Authority (CA) employs in issuing, managing and revoking Digital Certificates.

This CPS describes the practices followed by the ABR CA in relation to AUSkey Certificates, known as “AUSkeys”. The Community of Interest (COI) for AUSkey Certificates is restricted to:

• government Agencies who are part of the Standard Business Reporting Program (SBR), and
• Business Entities who have an Australian Business Number (ABN).

AUSkeys are only designed for Business Entities to authenticate themselves to, and carry out electronic transactions with, AUSkey COI member Relying Parties – see sections 1.1.3 and 4.4.

This CPS provides AUSkey COI members with a description of the practices followed in order to indicate the level of trust that may be placed in AUSkey Certificates. However, some security practices are too sensitive to be described in this CPS and are described in classified documents instead.

Other parties who may be expected to read this CPS include:

• the AUSkey Policy Management Authority (AUSkey PMA) or their delegates
• regulators and accreditors, such as Australian Signals Directorate (ASD) and Digital Transformation Agency (DTA)
• auditors
• AUSkey Operations personnel (AUSkey Operators).

This CPS is complemented by a number of Certificate Policies (CPs) which serve a policy function – each CP promulgates the rules applying to a particular type of AUSkey Certificate.

This introductory section identifies and introduces the set of CPS provisions, and indicates the types of entities and applications this CPS applies to.

1.1.1 Standard Business Reporting (SBR) program

SBR is a multi-agency initiative that will simplify business to government reporting by:

• making forms easier to understand
• using accounting/record keeping software to automatically pre-fill government forms
• introducing a single secure way to interact on-line with participating government agencies.

Government agencies participating in the SBR program include the Australian Treasury, Australian Prudential Regulation Authority, Australian Securities and Investments Commission, Australian Taxation Office (ATO), and all State and Territory government revenue offices.

SBR is focusing on financial reporting first, since this set of forms affects most businesses. An example of a form is the ATO’s Business Activity Statement.

1.1.2 AUSkey system

The Australian Business Register (ABR) Registrar has established the AUSkey System as Public Key Infrastructure (PKI) to facilitate internet-based electronic transactions between Business Entities and Agencies within the AUSkey COI. The AUSkey System supports the SBR program by providing Business Entities with a simple but secure means of conducting electronic transactions with SBR Agencies using a single multi-agency credential. The ABR Registrar manages the AUSkey System’s operational Certification Authority (the ABR CA) and Registration Authority (the ABR RA).

ABR Services will be used as a single registration point for AUSkey Certificates. An AUSkey Certificate is actually a Digital Certificate based on public key cryptographic technology. However, the system has been designed to make the underlying technology invisible to users, in order to maximise usability whilst preserving security. For example:

• it minimises the documentary Evidence of Identity (EOI) that applicants for AUSkey Certificates have to provide through its capacity to perform a strong “behind the scenes” identity check based on a Business Entity’s existing ABR information – see sections 3.1.2 and 4.1.2
• the Certificate Revocation List (CRL) is provided to a Trust Broker, who provides AUSkey Certificate validation and assertion services to Relying Parties – see sections 1.3.11 and 2.1.2.

1.1.3 Community of Interest

The AUSkey COI consists of Relying Parties (who accept AUSkeys) and Business Entities (who have AUSkeys). For the purposes of the AUSkey COI:

• the relying parties are Agencies in the SBR program (SBR Agencies) that accept electronic lodgments made for Business Entities by AUSkey Holders, where “Agency” means:
  • a Department of State, or a Department of the Parliament, of the Commonwealth, a State or a Territory,
  • a body corporate or an unincorporated body established or constituted for a public purpose by Commonwealth, State or Territory legislation, or an instrument made under that legislation (including a local authority),
  • a body established by the Governor General, a State Governor, or by a Minister of State of the Commonwealth, a State or a Territory, or
  • an incorporated company over which the Commonwealth, a State or a Territory has a controlling interest, and
• the business entities are entities:
  • entitled to have an ABN within the meaning of s8 of A New Tax System (Australian Business Number) Act 1999, and
  • seeking to use any of the online services provided by the SBR Agencies, including through the SBR channel itself.

Note: the SBR channel refers to the lodgment of forms using SBR-enabled business software. An example is when an end entity lodges a form from within an accounting or similar software package (like MYOB or Quicken) that is SBR-enabled.

Participation in the AUSkey COI:

• for Relying Parties – is (at the commencement of the AUSkey System) initially restricted to those SBR Agencies that engage electronically with business for lodgment of financial reports, and
• for Business Entities – is always restricted to Business Entities that are registered in the ABR as having an ABN (as the Business Entity is identified in its AUSkey Certificate by way of its ABN).

1.1.4 The Certification Practice Statement and related Certificate policies

If there is any inconsistency between any of the documents forming part of an applicable contract, those documents will be interpreted in the following order of priority to the extent of any inconsistency:

• The applicable contract, excluding the GKP003 Standard Certificate Policy and the GKP003 Device Certificate Policy (the CPs) and the GKP002 Certification Practice Statement (the CPS).
• The CPs.
• The CPS.

If the applicable contract is silent on any issue then the terms of the relevant CP will apply in relation to that issue and if that CP is silent on any issue then the terms of the CPS will apply in relation to that issue.

The headings in the CPS follow the framework set out in the Internet Engineering Task Force Request for Comment 3647 (RFC3647). Each CP also follows the headings and framework of RFC3647.

The division of content between the CPS and a CP is on a common industry approach:

• the CPS is a predominantly technical document which concentrates on technological, procedural, physical and personnel aspects of the back-end Public Key Infrastructure (PKI) operations
• a CP is predominantly business oriented and focuses on end entity and application related aspects of the front-end of the PKI.

Accordingly, the CPS emphasises sections 5, 6 and 8 on Physical and Logical Security, and PKI Compliance and Audit, while a CP contains more detail in sections 3 and 4 on Identification, Authentication, and the Certificate Life Cycle. Specific end entity Certificate Profiles are included in section 7 of each CP.

1.2 Document name and identification

This document is known as the GKP002 Certification Practice Statement. It does not require an object identifier (OID). This CPS can be accessed online on this AUSkey Terms and Conditions page.

1.2.1 Attribution

The use of the following in the preparation of this document is gratefully acknowledged:

1. Chokhani and Ford, RFC3647: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, 2003 (© The Internet Society 2003).
2. Gatekeeper documentation published by the DTA (© Commonwealth of Australia).

1.3 AUSkey participants

1.3.1 ABR Root Certification Authority (ABR RCA)

The ABR RCA is the self-signed trust point of the AUSkey Certificate hierarchy. The ABR RCA only signs and renews the ABR CA’s Certificate, and renews its own Key and Certificate. The ABR RCA’s system is therefore kept offline most of the time and is secured as described in sections 5 and 6.

The ABR RCA’s system software is a commercial off the shelf (COTS) product. Its system consists of several components, including a:

• Hardware Security Module (HSM) – a physically secure, tamper-resistant hardware/firmware device used for cryptographic functions such as Key generation, encryption and decryption
• database – a COTS Oracle database used to store data such as Certificates issued by the ABR RCA and their status, and audit logs.

1.3.2 ABR Certification Authority (ABR CA)

The ABR CA is the single operational Certification Authority in the AUSkey Certificate hierarchy. The ABR CA is responsible for generating AUSkey Certificates and CRLs.

Note: although the ABR CA generates AUSkey Certificates, the end user’s Private Keys are generated by the end user – the AUSkey Holder. The ABR CA’s own Certificate is signed by the ABR RCA.

The ABR CA receives AUSkey Certificate signing and revocation requests over HTTP from (and digitally signed by) the ABR RA. The ABR CA’s system processes all of the signed requests it receives from the ABR RA’s system via HTTP with no further checks. All the business logic and security controls confirming which requests are valid are provided by the ABR RA’s system.

The ABR CA’s software system is a commercial off the shelf (COTS) product. It operates online to support a real-time certificate management process, and consequently needs to be highly available, with low latency, for processing Certificate signing and revocation requests.

The ABR CA’s system must be kept highly secure, since its Key material is used to protect the integrity of all AUSkey Certificates. The ABR CA’s Private Key material is stored in a dedicated Hardware Security Module (HSM) to provide this security assurance. The ABR CA’s system also includes the ABR CA database, which is used to store data such as information on Certificates issued by the ABR CA and their status, and audit logs.

1.3.3 ABR Registration Authority (ABR RA)

The ABR RA provides registration services for AUSkey Certificates, and is responsible for ensuring the accurate recording and secure transmission of AUSkey signing and revocation requests to the ABR CA, and for taking all reasonable actions to verify the accuracy and sufficiency of EOI information provided to it in relation to those requests.

The ABR RA’s system is a combination of COTS and custom built software modules which accept AUSkey requests from the AUSkey Manager and perform EOI checks by calling on verification subsystems, and is integrated with ATO and ABR services for near real-time EOI checking.

Most certificate management tasks are performed by the ABR RA. In particular, the ABR RA performs all the business logic and security controls for certificate management requests. It then forwards any requests for issuing or revoking AUSkey Certificates to the ABR CA for actioning. The ABR CA only actions requests signed by the ABR RA’s signing Certificate.

There is no direct end-user interface with the ABR RA. Instead, users interact with the AUSkey website, which provides online certificate management functions. This promotes usability and disguises the complexities of the underlying systems, whilst preserving the strong security of public key technology.

The AUSkey website includes the AUSkey Manager, which is a software module developed specifically for the AUSkey System and assists in masking the complexity of the underlying technology. This component provides self-service functions for end users, for example requesting and managing AUSkey Certificates. Other components of the ABR RA’s system include the following:

• The base COTS RA component, which provides registration services for the ABR CA. It has a Key, which is stored in software, and a Certificate that is signed by the ABR CA. The ABR RA receives Certificate signing and revocation requests via the RA Exchange. The ABR RA verifies each request before digitally signing and sending it to the ABR CA.
• The RA Exchange (RAX), which acts as a gateway for Certificate signing and revocation requests to the ABR RA. The RAX receives requests via the web and writes them to the ABR RA database. The RAX has a Key, which is stored in software, and a Certificate that is signed by the ABR CA. The RAX uses this Key to sign any records that it writes in the ABR RA database.
• The ABR RA database which is used to store ABR RA data such as registration information and audit logs.

1.3.4 Business entities

Business entities are described in section 1.1.3. Business entities must be issued with an ABN through the ABR and intend to use AUSkeys to transact with relying parties within the AUSkey COI.

A business entity’s AUSkey Certificate identifies that business entity by reference to its ABN. That AUSkey is issued to an individual who can act on behalf of that business entity. That individual – the AUSkey Holder – is responsible for managing the use of that AUSkey on behalf of that business entity.

1.3.5 Business associates

A business associate is an individual who can exercise the powers of a business entity to (and to authorise others to) carry out electronic transactions with SBR Agencies, including providing that Business Entity’s information to, and receiving that business entity’s information from, those Agencies. These individuals are commonly, where the business entity is:

• an incorporated company – its directors
• a partnership – its partners
• a sole trader – that person, or
• a trust – its trustees (and if a corporate trustee, its directors)

A business associate of a business entity:

• must approve the AUSkey Holder for that Business Entity’s first AUSkey Standard Certificate
• may have an AUSkey Standard Certificate issued to them as the AUSkey Holder (and may be a User or Administrator as these roles are described below).

1.3.6 Users

A user is the AUSkey Holder of an AUSkey Standard Certificate who does not have administrator level privileges in relation to that certificate.

Individuals acting for Agencies within the AUSkey COI may also be issued with AUSkey Standard Certificates in situations where the Agency also acts as a business entity. Details on how users are appointed and issued with their AUSkeys are described in the GKP003 Standard Certificate Policy.

1.3.7 Administrators

An administrator is the AUSkey Holder of an AUSkey Standard Certificate who has undertaken an EOI check and been granted administrator level privileges in relation to that certificate. Only an administrator may appoint themselves or another AUSkey Holder to the role of Device Custodian.

Note: the grant of Administrator status is a separate authorisation process that is not inherent in the grant of an AUSkey Certificate.

In order to obtain administrator level privileges, an individual must be nominated by either a validated business associate of the relevant business entity, or another individual within that business entity who is already in possession of a valid AUSkey Standard Certificate with administrator privileges (that is, an administrator may appoint an administrator).

Details on how administrators are appointed are described in the GKP003 Standard Certificate Policy.

1.3.8 Device Custodians

A Device Custodian is the individual responsible for managing the use of a given AUSkey Device Certificate on behalf of the business entity identified in that certificate, and is responsible for safeguarding that certificate throughout its lifetime. While the Device Custodian is the AUSkey Holder of that certificate, it is the device name that appears in that AUSkey Device Certificate – not the name of the Device Custodian.

A Device Custodian must:

• possess a valid AUSkey Standard Certificate
• be appointed by an administrator
• accept the Conditions of Use setting out the responsibilities of the Device Custodian.

Details on how Device Custodians are appointed are described in the GKP003 Device Certificate Policy.

1.3.9 Devices

Devices are computer hardware such as servers within organisations that Device Certificates may be installed on. The device is the subject of the certificate, meaning that the certificate is issued in the name of the device, usually an IP address or domain name.

1.3.10 Relying parties

Relying parties are described in section 1.1.3 above. A Relying party acts in reliance on the Trust broker’s validation and assertion information as to an AUSkey Certificate, and is responsible for:

• verifying the AUSkey and Trust broker certificates are being used within relevant limits (see sections 1.3.11, 4.4, 4.9 and 6.1.4)
• checking the Trust broker trust chain and correctly processing the Security Assertion Mark-up Language (SAML) assertion.

1.3.11 Trust broker

A Trust broker supports the management of trust relationships by providing credential validation and assertion information to relying parties. The Trust broker is responsible for checking an AUSkey and providing information about the AUSkey and the AUSkey Holder to the relying party.

The Trust broker’s system receives information about SBR clients from the ABR RA’s system, and the AUSkey Manager uploads a range of Certificate Information, AUSkey Holder information and the latest ABR CA CRL to the Trust Broker’s system every 90 minutes to allow the Trust Broker to identify an AUSkey Certificate’s:

• validity status
• first and last name
• ABN
• Person ID
• email address
• Administrator status (yes/no).

The Trust broker’s system uses this information to verify AUSkeys and provide AUSkey Certificate validation and assertion information to AUSkey COI member Relying Parties.

The Trust broker is responsible for:

• protection of its own key material
• providing Trust broker certificates to AUSkey COI member Relying Parties
• checking the AUSkey revocation status and trust chain
• creating an accurate SAML assertion.

1.4 Certificate usage

See section 4.4 and the applicable CP for appropriate usage of each AUSkey Certificate type.

1.5 Policy administration

This document is administered by the AUSkey PMA\. The AUSkey PMA contact details are:

Postal Address: AUSkey PMA, Australian Business Register, PO Box 9977, Civic Square, ACT, 2608

The AUSkey PMA is also responsible for determining if the CPS is suitable for each associated CP.

1.6 Definitions and acronyms

See the AUSKey Terms and Conditions – Glossary. Capitalised terms are defined in this glossary, and acronyms are cross-referenced and defined in it where necessary.

1.7 Gatekeeper core obligations

The Gatekeeper Core Obligations Policy (PDF, 1.84MB)  is published by the DTA . That Policy:

• sets out what the Gatekeeper Competent Authority has determined as core obligations for participants in PKI deployments
• identifies specific core obligations for CAs and Registration Authorities (RA)
• requires that a “CA must ensure that any CPS it publishes incorporates the core obligations in relation to subscribers, relying parties, known customer organisations and threat and risk organisations as set out in this policy”.

Note: for Gatekeeper Accreditation purposes, ABR Services is a relationship organisation, and AUSkeys are certificates in the special category.

2 Publications and repository responsibilities

2.1 Repositories and publication information

The AUSkey system includes several repositories to support its operation. These are described below.

2.1.1 Publications

The documents published online are:

• GKP002 Certification Practice Statement
• GKP003 Standard Certificate Policy
• GKP003 Device Certificate Policy
• AUSkey Standard Certificate Conditions of Use
• AUSkey Device Certificate Conditions of Use
• AUSkey Terms and Conditions – Glossary
• Privacy Statement

These documents are published by ABR Services and are only updated as required. Their location (and the AUSkey website) is protected by a series of firewalls and security frameworks.

2.1.2 The CRL

The ABR CA publishes the CRL every 90 minutes. Those CRLs are distributed via file copy to the AUSkey Manager server. The Trust Broker then downloads the CRL from the AUSkey Manager server. Only the AUSkey and Trust broker operated repositories hold authoritative AUSkey related information (for example, certificate information, CRLs). The CRL is not directly available to the public or to relying parties. The Trust Bboker provides a SAML assertion to the relying party as to whether a particular AUSkey Certificate is valid (or not). See also section 4.9.

2.1.3 Internal data repositories

The following repositories support the AUSkey System:

• A confidential repository of classified documents that are not made publicly available for security reasons, for example the Security Plan or Key Management Plan (see section 5.3.7). – all AUSkey Operators are cleared to Secret level and must have access to the documents listed in section 5.3.7.
• A Trust broker system providing certificate validation and assertion information to relying parties. The Trust broker is responsible for authenticating AUSkeys. The AUSkey Manager uploads a range of certificate information, AUSkey Holder information and the latest ABR CA CRL to the Trust broker every 90 minutes – see also sections 1.3.11 and 4.9.
• The ABR CA database, which is used by the ABR CA for managing the list of issued AUSkeys and their revocation status. The ABR CA database does not store detailed information about AUSkey Holders or the Business Entities that these AUSkey Holders represent. This information is managed by the ABR RA.
• The ABR RA database, which stores all the required information for AUSkey Certificate management. The ABR RA database includes information about the following
  • AUSkeys that have been requested but not yet approved
  • AUSkeys that have been approved but not yet activated
  • AUSkeys that have been issued, including:
    • the AUSkey Holder to whom the AUSkey has been issued
    • the administrator in the business entity who approved the request
    • revoked AUSkeys.
  • AUSkey Holders that have been issued an AUSkey, including
    • the business entities that they represent
    • contact details
    • whether or not the AUSkey Holder is an administrator
    • individuals who have not been issued an AUSkey but are involved in certificate management operations.

Note: the only individual who falls into this category is a Business Associate, who may request and authorise an AUSkey for someone else, despite not personally holding an AUSkey.

Business entities that have been issued AUSkeys; this information includes the ABN of those Business Entities

Previous certificate management operations that have been performed - for internal audit and logging purposes.

All these repositories (other than the Trust broker system) are operated by ABR Services. The Trust broker system is operated by the Trust broker.

There is no public directory.

3 Identification and authentication

3.1 Overview

See the applicable CP for identification and naming procedures for a particular AUSkey Certificate type. Section 3 of the CP will contain specific information in relation to each Certificate type as to:

• naming
• initial identity validation
• identification and authentication for revocation requests.

In general, the principles set out below apply to all AUSkey Certificates.

3.1.1 Naming

The AUSkey System uses X.500 Distinguished Names. Subject names in AUSkey Certificates must be unique, unambiguous, and sufficiently detailed to provide a definitive mapping between the certificate and its end entity (i.e. a Ddvice or an administrator or user). Names must also enable identification of the relevant end entity. Anonymous or pseudonymous names are not allowed for any AUSkey Holder (any exception to this must be set out in the relevant CP).

3.1.2 Initial identity validation

In most cases, the AUSkey Systems registration process does not require applicants to supply documentary EOI, as identity details are usually entered and then validated (to a previous EOI process) online. In certain cases (such as where insufficient or incorrect details have been entered) applicants:

• via telephone – must provide sufficient information that allows the AUSkey Operator to locate and verify to a previous EOI process that confirms their identity, and in some cases
• via post – may be required to provide sufficient documentary evidence to the AUSkey operator to confirm their identity.

Note: documentary evidence generally involves a combination of primary documents (for example, passports, citizenship certificates) and secondary documents (for example, driver’s licences, bank statements), while combinations of information specific to the individual concerned (for example, date of birth, address, bank account details, reference numbers on relevant statements) are used to validate to a previous documentary evidence based EOI process.

Where the ABR RA retains a copy of EOI documentation submitted by applicants, it must ensure the secure storage of that information in accordance with the requirements of this CPS.

The ABR RA must, in respect of an AUSkey signing request, ensure that its knowledge of, and history of its dealings with, the relevant applicant is sufficient, to an internally defined risk level and for internally determined purposes, to authorise the issuance of a Gatekeeper compliant Digital Certificate to that applicant. Accordingly, the rules for AUSkey operator verification of applicants, including EOI status, conform to existing ABR processes on identity verification.

Note: The existing ABR processes on identity verification arise principally because the ABR Registrar must, under the A New Tax System (Australian Business Number) Act 1999, be satisfied that an individual’s identity has been established before including their name in a Business Entity’s ABR entry (e.g. as an ‘associate’ or ‘nominated representative’ of that Business Entity).

For applications for Standard AUSkeys with Administrator level privileges, existing ABR processes are applied to verify the identity of the proposed AUSkey holder (and the applicant, if a different person):

• To validate to a previous documentary evidence based EOI process – see proving your identity or Contact us.
• For documents to initially establish identity – see proving your identity

Applications for Standard AUSkeys with user level privileges, and device AUSkeys, to be held for a business entity must be made or approved by an administrator (for that same business entity) whose identity has been verified as above and who verifies the identity of the proposed AUSkey holder.

If an error is identified in the EOIor validation information or process that gives rise to uncertainty as to the authentication of an AUSkey holder, the ABR RA must promptly notify the ABR CA of that error and request the Revocation of that AUSkey.

See the applicable CP for more details.

3.1.3 AUSkey operators

AUSkey perators are vetted at the Secret level. The AUSkey Security Manager supervises the creation of secure logins for all AUSkey Operators who require system access. Certificates and passwords identify every AUSkey operator so that any actions can be audited.

The AUSkey Security Manager will revoke or cancel certificates and passwords of staff who leave the data centre or will be absent for more than six weeks. If an AUSkey Operator is taking extended leave (longer than six weeks) or leaving their position permanently, the AUSkey Security Manager must oversee the revocation of the certificate within 24 hours of the operator’s last shift. Further sensitive details are contained in relevant classified documents such as the Key Management Plan.

3.1.4 Identification and authentication for renewal requests

Not supported.

3.1.5 ABR CA and ABR RA operator certificate renewal

When AUSkey operator certificates are nearing their expiry date, the AUSkey Security Manager must supervise the renewal process through which the operator receives his or her replacement certificate. AUSkey operators are all vetted toSecret. Further confidential details are contained in classified documents, primarily the Key Management Plan.

3.1.6 Identification and authentication for revocation requests

The methods for requesting a revocation of an AUSkey include the following:

• A user or administrator authenticates to the AUSkey Manager using, and requests the revocation of, their own AUSkey Standard Certificate.
• The Device Custodian for an AUSkey Device Certificate authenticates to the AUSkey Manager using their AUSkey Standard Certificate and requests the revocation of that AUSkey Device Certificate.
• An administrator for a business entity authenticates to the AUSkey Manager using their AUSkey Standard Certificate and requests the revocation of another AUSkey (Standard or Device) certificate issued for (and identifying) that business entity.
• A business associate of or an administrator for a business entity telephones the Help Desk, provides identity details (sufficient to allow the AUSkey operator, in accordance with existing ABR processes, to validate their identity and their status as a business associate of or an administrator for that business entity) and requests that the AUSkey operator revoke an AUSkey (Standard or Device) ertificate issued for (and identifying) that business entity.
• The ABR Registrar approves the revocation of an AUSkey (Standard or Device) Certificate, and the AUSkey Operator performs the revocation at the explicit request of the ABR Registrar.

Any exceptions or variations to the above must be set out in the applicable CP.

3.1.7 ABR CA or ABR RA operator revocation

If an AUSkey operator suspects that their certificate has become compromised, they must promptly inform the AUSkey Security Manager who will oversee the revocation of the certificate. Further details are sensitive and are contained in relevant classified documents such as the Disaster Recovery and Business Continuity Plan (DRBCP). See also section .3.1.3

4 Certificate life cycle policy definition

This section contains a generalised summary of the life-cycle operational requirements for AUSkey Certificates. More specific details for particular types of AUSkey Certificates may be found in the applicable CP. The processes are described at a high-level, from the perspective of human end users.

Note: all AUSkey life-cycle event requests must come through a valid ABR RA communication, using standards based formats such as Public Key Cryptography Standards (PKCS) payloads. At a technical level, a request will only succeed if the ABR CA is able to successfully validate the request by verifying the ABR RA’s signing Certificate.

4.1 Certificate application

The ABR RCA, ABR CA and ABR RA Certificates are created at a formal key signing ceremony. Rather than being applied for, these Certificates are commissioned as an integral step in implementing the AUSkey System.

4.1.1 Who can submit an application for an AUSkey Certificate?

An application for an AUSkey Certificate (to be held for a Business Entity), in the case of an:

• AUSkey Standard Certificate – must be made or authorised by an administrator for, or a business associate of, that same business entity
• AUSkey Device Certificate – can only be made by an administrator for that same business entity.

For details, please see the applicable CP.

4.1.2 Certificate application processing

The AUSkey System provides automated certificate application and processing. AUSkey certificate applications can be made online through the AUSkey Manager and AUSkey website, which are processed and, where accepted, actioned by the ABR RA’s and ABR CA’s systems in near real time. The typical application process for an AUSkey certificate is as follows:

An application for an AUSkey is created using the AUSkey website, which interfaces with the ABR RA. If the application is from a business associate, the business associate must provide EOI information and the AUSkey System confirms that he or she is listed in the ABR as a business associate for the business entity. If the application is for an AUSkey Standard Certificate to be held by an Administrator for the business entity, that person must provide EOI information. The AUSkey System confirms that an application for an AUSkey is approved by an administrator for (or recognised business associate of) the business entity.

The ABR RA receives and approves a request to issue an AUSkey Standard or Device Certificate. The ABR RA also sends the proposed AUSkey Holder an email confirming that their AUSkey certificate request has been approved.

The proposed AUSkey holder clicks on a link in the email and the AUSkey generation process is initiated. The AUSkey software installed on the end entity’s computer generates a new Key Pair and the associated PKCS#10 requests. The PKCS#10 requests are sent to the AUSkey Manager and then onwards to the ABR RA.

The ABR RA validates and checks the contents of the PKCS#10 data received from the end entity. The ABR RA validates the signature on the PKCS#10 by using the end entity’s Public Key. (This process allows the ABR RA to confirm that the PKCS#10 request came directly from the end entity who generated the Private Key, as only that end entity has access to that Private Key. It avoids a “man in the middle” attack where an attacking individual could change details contained in the PKCS#10, for example the end entity’s name).

The ABR RA signs the AUSkey Certificate request using its own Certificate.

The ABR RA stores the signed request in the local ABR RA database.

The ABR RA sends the request to the ABR CA.

The ABR CA issues and returns a certificate chain containing the end entity’s AUSkey Certificate, the ABR CA Certificate and the ABR RCA Certificate.

The AUSkey holder must ensure that all information provided and each representation made in the application for their AUSkey is accurate and complete, and must promptly notify the ABR RA if they consider that any of that information or representations is or may be incorrect.

For additional details and requirements by specific certificate type, and a user-centred view of the process, see the relevant CP.

4.2 Certificate issuance

The typical issuance of an AUSkey Certificate includes these steps:

The AUSkey system prompts the proposed AUSkey holder to accept the Conditions of Use associated with that AUSkey Certificate.

The proposed AUSkey holder accepts those Conditions of Use.

The AUSkey is generated and stored, either on a local hard drive or a portable USB device.

The AUSkey holder creates a password in order to protect their AUSkey.

The AUSkey system generates and stores a confirmation message that the certificate has been activated successfully.

For details by specific AUSkey certificate type, please see the relevant CP.

The ABR CA must, when generating an AUSkey or the ABR RA’s Digital Certificate (and the ABR RCA must, when generating the ABR CA’s Digital Certificate) ensure that:

• the certificate Information provided to it has been accurately transcribed into the certificate
• all other certificate information it generates itself for the Certificate is accurate
• the certificate operates with functional Key Pairs
• the certificate contains all the elements required by the relevant certificate profile.

4.3 Certificate acceptance

An AUSkey Certificate is provided to the AUSkey Holder by way of the AUSkey System generating and downloading the AUSkey Certificate to the store file selected by the AUSkey Holder. Relevant Certificate Information is provided to the ABR RAs system via the returned certificate chain (see section 4.1.2) and to the Trust Broker via the AUSkey Manager (see sections 1.3.11 and 2.1.3).

The general principle is that use constitutes acceptance. Acceptance of a Certificate is also indicated by acceptance of the Conditions of Use associated with that Certificate. See the relevant CP.

4.4 Key Pair and certificate Usage

AUSkey certificates are designed for use by business entities (who are registered in the ABR as having an ABN) to authenticate themselves to, and carry out electronic transactions with, participating SBR Agencies. The AUSkey cystem does not support use of AUSkeys by or with any other relying parties.

Use of an AUSkey certificate and associated keys may be further limited by this CPS, the applicable CP and the applicable contract associated with that AUSkey certificate. The AUSkey holder is responsible for ensuring that AUSkey certificate is only used by the AUSkey holder and by the business entity within all such limits, and for performing any additional requirements as specified in the CP under which that AUSkey certificate was issued.

Note: the X.509 key usage field in the certificate itself does not convey any express or implied permission to use any AUSkey Certificate in any way, unless such use is explicitly permitted in the applicable contract.

The use of an AUSkey certificate and associated keys by a relying party may also be further limited by any relevant contractual or other arrangement between the ABR Registrar and that relying party. The relying party is responsible for ensuring that AUSkey certificate is only used by it within all such limits.

4.5 Certificate renewal

Not supported.

A revoked AUSkey certificate will not be renewed. Instead, a new certificate must be issued, following the identification and authentication procedures described in the applicable CP. See the applicable CP.

4.6 Certificate re-key

Not supported.

4.7 Certificate modification

Certificate modification is supported for CA certificates only.

Certificate modification is initiated by the ABR Registrar.

Certificate modification is carried out in a formal key signing ceremony. A new key pair is not generated during the ceremony and a formal record is included of what attributes are being modified.

A modified CA certificate will be published to the Authority Information Access (AIA) location specified in issued end entity certificates. See the applicaple CP.

4.8 Certificate revocation and suspension

4.8.1 Circumstances for revocation

Circumstances for revocation include, but are not limited to, the following:

• A Private Key, or media holding a Private Key, is compromised or lost.
• There has been improper or faulty issuance or use of the certificate.
• The certificate information becomes, or is found to be, inaccurate.
• A change in the registration information occurs.
• The certificate holder ceases to exist or ceases to have the requisite authority to act for the business entity identified in the certificate.
• The business entity identified in the certificate ceases to exist or ceases to hold the ABN by which it is identified in that certificate.
• The relevant CA (the ABR CA or ABR RCA) ceases to operate.
• The ABR CA receives a valid revocation request from the ABR RA or through the ABR RA from a certificate holder, administrator or business associate.
• In order to protect the integrity of the AUSkey System, the ABR CA reserves the right (and ABR RA and the ABR Registrar reserve the right to request the ABR CA) to revoke any certificate at any time.

4.8.2 Who may request revocation

See sections 3.1.2, 3.1.6, 4.8.1 and the applicable CP.

4.8.3 Procedure for revocation request

Access to revocation information will be through a standards compliant and approved X.509 protocol such as LDAP. For all other details including procedural steps, see Section3.1.6 of the applicable CP.

The ABR CA is responsible for ensuring the prompt revocation of an AUSkey in accordance with the requirements of this CPS and the applicable CP. The ABR RA’s and ABR CA’s systems accept, process and action revocation requests in near real time (there is no grace period). The status of a revoked AUSkey issued to a business entity is immediately available, online via the AUSkey Manager, to any administrator for that business entity.

The issuance and frequency of the CRL that contains AUSkey revocation information is discussed in section 4.9 below. The Trust broker is responsible for downloading the CRL, using it to check the validity and status of AUSkeys, and providing Certificate validation and assertion information to relying parties seeking that information from it (see sections 1.3.11 and 2.1.3).

A relying party is responsible for checking the validity and status of an AUSkey presented to it with the Trust Broker, and for correctly processing the Trust broker’s SAML assertion (see section 1.3.10). Any other form of revocation advertisement to a relying party must be set out in the applicable contract between it and the ABR Registrar.

Revocation of AUSkey operator certificates or elements of the AUSkey System infrastructure are contained in classified documents, primarily the Key Management Plan.

4.8.4 Suspension of certificates

Suspension is not supported for any AUSkey Certificates. AUSkeys can only be revoked.

4.9 Certificate status services

The ABR CA periodically generates a CRL that contains AUSkey revocation information. The CRL is downloaded by the Trust broker’s system and used to check the validity and status of AUSkeys.

A new CRL is generated every 90 minutes, is digitally signed by the ABR CA, and has a validity period of seven hours. When an AUSkey is revoked, there will be a period of time until that revocation is identified in the next CRL downloaded by the Trust broker (and during which that AUSkey could be used to access a relying party service). In contrast, the revocation will take immediate effect in the AUSkey website as the AUSkey Manager obtains an AUSkey’s status directly from the ABR CA database.

The SAML assertion issued by the Trust broker is signed by the Trust broker’s Private Key and is valid for 20 minutes. Therefore, the trust model for the SAML assertion differs from that of the ABR CA.

An email notification of an AUSkey’s revocation is sent to the AUSkey holder, but not to potential relying parties or to the Trust broker. Notification is provided to the Trust broker when the next CRL is issued.

4.10 End of subscription

A subscription for an AUSkey ends when the certificate is revoked or expires. In the event of revocation, the system processes the revocation request, removes the revoked AUSkey from the Credential Manager, adds the revoked AUSkey to the CRL, and sends an email to the AUSkey Holder notifying them of the revocation. The AUSkey holder is still viewable on the AUSkey website, but their status is displayed as “inactive” (rather than “active”).

The AUSkey system follows a ‘revoke one, revoke all’ rule where multiple AUSkeys are held by the same certificate holder for the same business entity (for example, one on their desktop system and another on a Universal Serial Bus (USB) device for laptop computing). If any of those AUSkeys are revoked, all other AUSkeys held by that certificate holder for that business entity are also cancelled.

An expired AUSkey cannot be renewed and the application process will be treated as a new application.

4.11 Key escrow and recovery

Private Key escrow is the placing of a Private Key into the custody of a third party. Its purpose is to provide a means by which a Private Key can be obtained, in certain circumstances, when the certificate holder is unable or unwilling to cooperate. The AUSkey System does not support AUSkey certificate Private Key escrow.

5 Facility, management and operational controls

5.1 Physical cecurity controls

5.1.1 Site location and construction

The primary site location of the ABR RCA and ABR CA shall be in a secure area at the ATO’s computer centre. The AUSkey System operates within a secure environment that meets the standards set out in the Australian Government Information Security Manual (ISM). Precise security specifications are confidential and are described in more detail in GKP001 Security Profile.

5.1.2 Physical access

Access control systems apply to all entry and egress points of the ATO’s computer centre, and to the building in which it is located, to restrict physical access to the ABR RCA’s and ABR CA’s systems to only authorised personnel. On building entry personnel must produce a form of identification, and only those with pre-arranged approval are provided the means to access the area in which the ABR RCA’s and ABR CA’s systems are located.

Unauthorised entry (and tailgating) is not permitted, and all physical access is logged and subject to audit.

5.1.3 Power and air conditioning

The relevant secure operating areas are connected to a standard power supply. All critical components are connected to uninterrupted power supply (UPS) units, to prevent abnormal shutdown in the event of a power failure. The area has an air conditioning system to control the heat and humidity that is independent of the building air conditioning system.

5.1.4 Water exposures

The relevant secure operating area is protected against water exposure by being located on an above ground floor of an office building that is not in a flood zone and has a built-in raised floor.

5.1.5 Fire prevention and protection

Fire extinguishers and smoke alarms are located within the relevant secure operating areas.

5.1.6 Media storage

All magnetic media containing AUSkey information, including backup media, is stored in containers, cabinets or safes with fire protection capabilities and are located either within the relevant service operations area or in a secure off-site storage area.

5.1.7 Waste disposal

Paper documents and magnetic media containing Private Key or commercially sensitive or confidential information are securely disposed of by:

• physical damage to or complete destruction of the asset if on magnetic media or the use of an approved utility to wipe or overwrite magnetic media
• shredding or destruction by an approved service for paper-based material.

5.1.8 Off-site backup

ASIO-T4 certified off-site storage agents are used for the storage and retention of backup software and data.

AUSkey operators back up all database servers onto digital linear tape (DLT) and retain multiple copies for data resilience. They store tapes from a five week cycle both onsite and offsite. All tapes which are to be removed from the data centre must have their contents encrypted with a DSD approved algorithm.

The off-site storage:

• is available to authorised personnel 24 hours per day seven days per week for the purpose of retrieving software and data
• has appropriate levels of physical security in place with staff holding on appropriate level of clearance.

5.2 Procedural controls

5.2.1 Trusted roles

Separate individuals fill each of the trusted roles in order to provide the maximum security and afford the opportunity for the greatest degree of checks and balances over system operation. Each of the operations that require dual control by two personnel within the AUSkey system shall not be carried out by one person. Each person in a dual control shall be responsible for the integrity of the process they are performing. They will not disclose to the other person any parts of a password. Detailed descriptions of procedural and personnel controls are sensitive and are only specified in classified documents.

5.2.2 Identification and authentication for each role

The AUSkey Security Manager supervises the creation of logins and P12 files for all AUSkey Operators who require system access. The certificates and passwords identify the AUSkey Operator so that any actions can be audited. The AUSkey Security Manager must revoke certificates and passwords of AUSkey Operators who leave the data centre or will be absent for more than six weeks (see section 3.1.3).

Persons filling trusted roles must undergo a formal vetting process conducted by an authorised vetting service (see section 5.3.1).

5.2.3 Roles requiring separation of duties

This CPS prohibits personnel responsible for the auditing of a task to carry responsibility for the performance of that task.

The same person cannot hold the roles of AUSkey Operations Manager and AUSkey Security Manager.

5.3 Personnel controls

The AUSkey Operations Manager must report any unexplained staff absences which exceed 72 hours to the system owner via the Facility Manager. The AUSkey Operations Manager must also report the details and circumstances leading to the termination or transfer of any person assigned to duties for the AUSkey System. Within 24 hours the AUSkey Operations Manager must audit the integrity of AUSkey System elements worked on by the departed person and report the results to the AUSkey Security Manager and record them in the DSOT and/or Operations Log.

The AUSkey Operations Manager is to maintain a register of personnel assigned to the site and a roster of when they are assigned to duty. AUSkey Operators assigned to duties are to log on and log off in the Operations Log when commencing or ceasing any period of duty. Contractors at any time, staff (permanent or temporary) outside any period of assigned duty, other persons whether they have been granted building access or not (for instance gardeners) must record their visit in the Visitors’ Log. The AUSkey Security Manager is to audit the Visitors’ Log.

5.3.1 Qualifications, experience, and clearance requirements

The recruitment and selection practices for AUSkey System personnel take into account the background, qualifications, experiences and clearance requirements of each position, which are compared against the profiles of potential candidates.

The ABR has designated that all positions supporting the AUSkey System are positions of trust and it requires that all staff working on the AUSkey System have Secret clearance via a vetting agency. The Facility Manager must ensure those personnel have Negative Vetting 1, Secretd clearances.

5.3.2 Training requirements

All AUSkey System personnel shall be trained in the following:

• basic PKI concepts
• the use and operation of the ABR CA and ABR RA software
• AUSkey System procedures such as those described in
  • GKP001 Security Profile
  • GKP004 Business Continuity and Disaster and Recovery Plan
  • GKP005 CA Operations Manual
  • GKP006 RA Operations Manual.
• applicable privacy legislation and practices, including the Privacy Statement
• confidentiality requirements for the protection of information, including the requirements of tax law secrecy provisions and the Criminal Code Act 1995 (Cth)
• computer security awareness and procedures
• the meaning and effect of this CPS and the CPs.

5.3.3 Retraining frequency and requirements

AUSkey System personnel receive a security briefing update at least once a year.

Training in the use and operation of the ABR CA and ABR RA’s software is provided when new versions of the software are installed.

Remedial training is completed as required or when recommended by audit comments.

5.3.4 Job rotation frequency and sequence

The ABR may implement formal job rotation practices (for example through formal schedules) for AUSkey System personnel. Where formal job rotation is not implemented, cross-training activities are conducted to ensure operations continuity.

5.3.5 Sanctions for unauthorised actions

Unauthorised actions by AUSkey System personnel are investigated and where appropriate disciplined by the proper authorities. The response to unauthorised actions is to take into account whether the misuse was an accident, omission, or malicious act. Where a staff member has been found to have seriously misused the resources to which they have been granted access, these actions are to be documented and passed to senior ABR and ATO personnel, who may wish to take disciplinary action. Sanctions against contract employees are to be in accordance with the terms and conditions of their contract. Depending on the nature of the actions, sanctions will comply with Commonwealth policy for disciplinary action and may range from counselling and/or suspension of access rights, through to dismissal and/or legal action.

5.3.6 Independent contractor requirements

AUSkey System personnel (management or operational) may be independent contractors who are appointed in writing and given written notification of the terms and conditions of their position. They are normally assigned full-time to their responsibilities and have all the same duties and obligations of permanent staff in relation to AUSkey System security.

All contractors with physical or logical administrative access to the AUSkey System facilities must have either, appropriate clauses in their contract or sign a Confidentiality/Non-disclosure Agreement before they are allowed access to secure systems. Casual staff and third party access which is not already covered by an existing contract (containing the Confidentiality Agreement) may be required to sign a Confidentiality Agreement before being granted limited access to the facilities.

5.3.7 Documentation supplied to personnel

All AUSkey Operators must sign a confidentiality and non-disclosure agreement. These staff (all of whom have HP clearance) have access to:

• relevant hardware and software technical manuals and user guides for COTS products
• policy documents, including this CPS and all applicable CPs
• GKP001 Security Profile
• GKP004 Business Continuity and Disaster and Recovery Plan
• Privacy Statement
• GKP005 CA Operations Manual
• GKP006 RA Operations Manual
• Standard Operating Procedures (SOPs)
• any other documents deemed necessary for effective performance of duties.

5.3.8 Termination of AUSkey system personnel

Within one working day the AUSkey Operations Manager must cancel the access rights for AUSkey System personnel who are dismissed, resign or who are reassigned and no longer require access. Within one working day the AUSkey Operations Manager must conduct an audit of the AUSkey elements the separating AUSkey System personnel had worked on.

5.4 Audit logging procedures

5.4.1 Types of events recorded

The minimum audit records to be retained include all for the following:

• registration records
• key generation requests
• certificate generation requests
• certificate issuance records, including CRLs
• audit records, including security related events
• revocation records
• successive versions of this CPS and all the CPs.

5.4.2 Frequency of processing log

Audit logs are processed on a daily, weekly, monthly and annual basis.

5.4.3 Retention period for audit log

AUSkey operators archive the audit logs and keep them at least seven years from the date of archiving or otherwise required by law - including under the Archives Act 1983 (Cth).

5.4.4 Protection of audit log

The ABR CA and RA Databases store audit logs and other data. Access is protected with username and password. The COTS CA and RA software signs all logs to prevent undetected alteration. It is technically very difficult for an AUSkey operator to delete a log entry without detection because the COTS software logs record all operator actions and record any delete actions.

5.4.5 Audit log backup procedures

Audit logs are backed-up daily.

5.4.6 Audit collection system

The AUSkey audit collection system is an internal system comprising a combination of automated and manual processes performed by the ABR CA or ABR RA operating systems, applications and operational personnel.

5.4.7 Notification to event-causing subject

The AUSkey Security Manager has the discretion of whether to inform any individual AUSkey System personnel that their actions are being audited through the logs.

5.4.8 Vulnerability assessments

A Threat and Risk Assessment (TRA) and iterative security reviews have been completed for the entire AUSkey System and the findings of these are reflected in the protective measures set out in the GKP001 Security Profile.

5.5 Records archival

5.5.1 Types of records archived

The ABR CA produces and stores the following data:

• copies of issued Certificates
• certificate status (active or revoked)
• copies of each issued CRL
• event logs.

The ABR RA produces and stores the following data:

• certificate applications requested but not yet approved
• certificate applications approved but not yet activated
• certificates issued and who approved them
• end user personal details.

The following audit information is archived:

• audit logs
• certificate request information
• certificates, including CRLs generated
• complete back up records
• copies of e-mail logs
• formal correspondence
• successive versions of this CPS and any CP.

All records archived as part of an entity's or person's interaction with the AUSkey System will be dealt with in accordance with the requirements of the Archives Act 1983 (Cth).

5.5.2 Retention period for archive

AUSkey operators archive the audit logs and keep them at least seven years from the date of archiving or otherwise required by law - including under the Archives Act 1983 (Cth).

5.5.3 Protection of archive

Archive media is protected either by physical security or a combination of physical security and cryptographic protection. It is also protected from environmental factors such as temperature, humidity and magnetism. Further, the archive is protected against modification and unauthorised deletion.

The archive is integrated with the backup processes that apply across ATO (including ABR Services) deployed systems. In that context, the archive data:

• is securely stored on write-once media, and cannot be deleted during their retention period
• can only be viewed by a system administrator after obtaining specific approval to do so (on a case by case basis) under a change control process
• is protected against deterioration through a scheduled backup verification process.

The archive and backup hardware, software, media and operating systems are protected against obsolescence through scheduled system reviews and accompanying formal change planning and management processes.

5.5.4 Archive backup procedures

The AUSkey Operators have the following responsibilities:

• Backup the ABR CA and ABR RA databases every working day using the system utility with backup copies to be registered and their location recorded in an operations log.
• Store tapes from a five week cycle both onsite and offsite with daily differential stored on-site in a B class safe.
• Store a copy of the most recent backup in an approved offsite storage location once a week.
• Keep all paper logs and registers at least seven years from the date of archiving or otherwise required by law (including under the Archives Act 1983 (Cth)).
• Test that they can restore the databases from the archive media as part of the Disaster Recovery and Business Continuity annual test with further confidential details to be contained in the DRBCP.

The databases contain all the records which the ARB CA and ABR RA have ever generated. Thus although it is not possible to restore the AUSkey System to a point older than five weeks, it is possible for the AUSkey operators to retrieve certificate and user information from any time in the past.

5.5.5 Requirements for time-stamping of records

Individual events shall be time stamped with the timing of the event. Audit logs shall also be time stamped with the time of archival, and if via a backup process a timestamp of the relevant backup.

5.5.6 Archive collection system (internal or external)

No stipulation.

5.5.7 Procedures to obtain and verify archive information

To provide authentication and integrity confirmation of the archive records digital signatures are applied. To maintain the assurance of that authentication and integrity, additional archive authority signatures throughout the retention period are applied.

The integrity of the AUSkey Systems archives is verified:

• annually at the time of a programmed audit
• at any other time when a full audit is required
• at the time the archive is prepared.

5.6 Key changeover

The AUSkey System ensures that the Key changeover process and procedures will provide for uninterrupted operation of the ABR CA, and will also ensure that subordinate certificates do not become invalid as a result of ABR CA Key changeover. Key changeover periods will be in accordance with the Key Management Plan contained within GKP001 Security Profile and prior to normal Certificate/Key expiry.

5.7 Compromise and disaster recovery

Complete details of the disaster recovery process are set out in the DRBCP. Currently no Disaster Recovery site is in place. This risk has formally been acknowledged and accepted by the AUSkey System owners. Further details are contained in GKP001 Security Profile.

Disaster recovery exercises must be conducted at least every 12 months. The actions to be taken in the event of a disaster are as follows:

• Ensure the safety of staff, visitors and the general public and if staff must leave the secure site because of an emergency such as fire or flooding, they must not put their lives or the lives of others at risk to secure data or equipment.

 

• Control any cryptographic key compromise and if an evacuation of the secure site occurs in a sufficiently controlled manner the staff should ensure that confidential material is locked away.

The National Disaster Recovery Manager is authorised to perform a desktop disaster recovery exercise.

The design of the AUSkey System is robust. All the subsystems use standard COTS hardware which the relevant service provider can readily source in the event of a failure. The ABR CA and ABR RA are physically duplicated for load balancing and redundancy.

Data storage uses RAID disk arrays where no data is lost in the event of a disk failure. The system test environment and the system development environment, which are both housed at a secure site, provide further hardware in the event of a major failure (for example a fire which destroys several cabinets).

5.7.1 Incident and compromise handling procedures

All security incidents are to be logged as per GKP001 Security Profile, and an investigation of the incident is to be undertaken to determine if:

• Key compromise has occurred, is suspected, or cannot be discounted
• the incident was deliberate or accidental
• procedures should be modified to address the circumstances that enabled the incident to occur
• any further action is required.

If it is possible that a Key compromise has occurred, the certificate requires revocation. Certificates subordinate to the revoked certificate must also be revoked. Where the ABR RCA certificate is revoked, the ABR CA certificate is revoked, as are all subordinate AUSkeys.

The AUSkey PMA receives notification of all incidents where the continued integrity of service is impacted, and will provide a formal notice to accrediting bodies, indicating the proposed corrective action and the estimated schedule for implementation.

The DRBCP contains a link to a document titled ‘AUSkey Agencies- Contact List’ so that agencies can be notified in the event of an ABR RCA or ABR CA failure.

5.7.2 Computing resources, software, and/or data are corrupted

The AUSkey System at all times maintains a configuration baseline plan and a comprehensive back-up, archiving and response plan to provide data for identifying component failure and subsequent service restoration.

5.7.3 Entity Private Key compromise procedures

The AUSkey Holder must promptly:

• notify the ABR RA in the event that they consider the EOI information provided by them is or may be incorrect
• request the revocation of an AUSkey (see section ) if he or she considers or suspects its Private Key has been compromised.3.1.7

If an AUSkey Private Key is compromised it is revoked and the AUSkey holder must re-apply for a new AUSkey certificate.

5.7.4 Business continuity capabilities after a disaster

The AUSkey System maintains backup, archive and offsite storage in accordance with GKP005 CA Operations Manual and the GKP004 Business Continuity and Disaster and Recovery Plan. Priorities for Business Continuity are in the following order:

• Physical investigation of disaster and collection of necessary evidence to complete investigation.
• Re-establishment of secure environment for AUSkey operations.
• Reconstitute the ability to issue CRLs and process revocation requests – this includes audit functionality.
• Reconstitute the ability to receive, process and issue AUSkeys.
• Return to stable operating conditions.
• Update documentation to reflect any changes as a result of recovery – including to processes, procedures and configuration.
• Provide an incident closure report to all relevant authorities, including the Gatekeeper Competent Authority if requested.

5.8 ABR CA or ABR RCA termination

Termination of a CA would be a non-trivial event requiring formal documented procedures. If the operation of the ABR RCA or ABR CA is terminated for any reason, the ABR will endeavour to give Certificate Holders and Relying Parties as much prior notice as possible and must put in place alternative arrangements. In the event of an ABR CA or ABR RCA termination, or either CA ceasing operation, its Certificate requires revocation. Self-signed CAs shall follow notification procedures equivalent to Key compromise.

In the event of ABR CA or ABR RCA termination:

• all parties must co-operate with each other (and the Gatekeeper Competent Authority) in minimising any disruption that may be caused to the AUSkey COI
• the ABR and relevant service providers will workshop a mutually agreed detailed procedure for the termination
• any relevant provisions in the Gatekeeper Head Agreement or service provider contracts will be invoked.

5.8.1 ABR CA or ABR RCA termination obligations

In the event of a CA (the ABR CA or ABR RCA) termination, the CA must not:

• issue any new certificates

and all certificates that have been issued and are otherwise still in effect will remain in force until they expire in accordance with this CPS and the applicable CP.

The obligations set out in any individual contracts with the ABR in relation to AUSkeys must be undertaken by:

• the AUSkey System service providers
• business entities and AUSkey holders
• relying parties
• the ABR
• the AUSkey PMA.

5.8.2 ABR CA or ABR RCA programmed termination

A programmed termination will arise where there is termination by the ABR CA or ABR RCA for default or for convenience.

Insofar as it is required, that CA shall affect a transfer of keys and certificates to another CA service provider. The alternate service provider must also be Gatekeeper accredited. The transfer must be performed in a manner agreed to by the AUSkey PMA and Gatekeeper Competent Authority. For the purposes of this and the next section, keys and certificates can be taken to mean any set of keys and certificates within that CA’s span of control.

Note: this section only attempts to list the high level actions of cessation of the ABR CA or ABR RCA service. On Cessation of such a CA Service a “CA Transition-Out Plan” will be formulated and released by the AUSkey PMA.

If programmed termination is required by the ABR CA or the ABR RCA, then the AUSkey PMA will:

• give to the affected organisations prior written notice
• transfer the Private Keys of that CA to the replacement CA in a manner approved by the AUSkey PMA
• transfer the CRL and other directories of certificates issued by that CA to the replacement CA, in a manner approved by the AUSkey PMA
• destroy all copies of that CA’s Private Keys immediately after their transfer to the replacement CA
• document a declaration concerning the destruction of that CA’s Private Keys by the AUSkey PMA
• circulate the AUSkey PMA’s declaration to members of the AUSkey COI and the Gatekeeper Competent Authority.

5.8.3 ABR CA or ABR RCA non-programmed termination

If the ABR CA or ABR RCA is required to implement a non-programmed termination of its business operations, then a representative of that CA will immediately advise the AUSkey COI in writing, or if writing is inappropriate the representative may advise by telephone, that the CA will be immediately terminating its business operations.

In this case:

• all affected members of the PKI hierarchy will, with the assistance of that CA, co-ordinate and use all reasonable endeavours to facilitate the transfer of the CRL and other directories of Certificates issued by that CA, and the transfer of that CA’s Private Keys to a replacement CA
• the AUSkey PMA will
  • assist to the highest degree possible in the transfer of the Private Keys of that CA to the replacement CA, in a highly secure and trustworthy manner, the manner of which will be approved by the AUSkey PMA
  • assist to the highest degree possible in the transfer of the CRL and other directories ofcCertificates issued by that CA to the replacement CA, in a highly secure and trustworthy manner, the manner of which will be approved by the AUSkey PMA
  • immediately after the transfer of that CA’s Private Keys to the replacement CA, permanently destroy all copies of that CA’s Private Keys in that CA’s possession so that the only copy of that CA’s Private Keys that are used to digitally sign that CA’s Public Key Certificates are held by the replacement CA
  • provide a formal declaration concerning the destruction of that CA’s Private Keys to the AUSkey COI and the Gatekeeper Competent Authority
  • use its reasonable endeavours to cause the replacement CA within a reasonable time after the date on which the transfer is affected to re-issue new Certificates for each entity within the PKI hierarchy that has been transferred.

5.8.4 Transfer of ABR RCA data

The transfer of the ABR RCA Private Keys and Certificates to a replacement RCA is dependent upon the Gatekeeper Competent Authority giving approval for the transfer of the Keys and Certificates to proceed.

5.8.5 Termination of this CPS

In the event of the ABR CA termination:

• Where an AUSkey is transferred to another CA service provider, to be subject to that other CA’s CPS and applicable CP, then in relation to this CPS and the applicable CP, that AUSkey will expire.
• The GKP003 Standard Certificate Policy and the GKP003 Device Certificate Policy will respectively terminate when all remaining AUSkeys to which that relevant CP applies have been revoked or have otherwise expired in accordance with this CPS and that applicable CP.
• This CPS will terminate when all AUSkeys that have been issued and are otherwise still in effect have been revoked or have otherwise expired in accordance with this CPS and the applicable CP.

however, sections 5.5.2, 9.1, 9.2, 9.3, 9.4 and 9.12 (and comparative provisions in an applicable CP) will survive such termination.

6 Technical security controls

6.1 Key Pair generation and installation

All AUSkeys operate with single Key Pairs.

6.1.1 Key Pair generation

The ABR RCA and ABR CA Keys are generated and stored in a Hardware Security Module (HSM). Access to the ABR RCA database is protected with username and password credentials.

End user keys are generated and stored in software, with password and encryption protection. The end user generates the Private and Public Key pair in the browser on their computer. They retain the Private Key in a key store either on disk or a USB memory stick, which is encrypted with their password. The Private Key must not leave the end user’s control. The end user must take all reasonable measures to protect the Private Key from compromise, and all necessary precautions to prevent the loss or unauthorised disclosure, modification or use of the Private Key.

Where a CA (the ABR CA or ABR RCA) generates a Key Pair, it must ensure that the Key Pair can work as an operable pair of cryptographic Keys.

6.1.2 Private Key delivery to AUSkey holder

End users generate their own Private Keys so no delivery by the ABR CA is necessary.

6.1.3 Public Key delivery to certificate issuer

The backend of the AUSkey website includes an “AUSkey Manager” subsystem which delivers the end user generated Public Key to the ABR CA, via the ABR RA.

After the end entity generates an RSA (Public and Private) Key Pair, the AUSkey software creates a secure and standards compliant PKCS#10 which contains the certificate details and the Public Key, and signs it with the end entity Private Key, and sends it to the ABR RA. The ABR RA validates the PKCS#10 and then sends it to the ABR CA’s system. This process allows the ABR RA to confirm that the PKCS#10 request came directly from the end entity to whom the Private Key was issued as only that end entity has access to that Private Key. It avoids a ‘man in the middle’ attack where an attacking individual could change details contained in the PKCS#10, for example the end entity’s name.

6.1.4 ABR CA Public Key delivery to relying parties

Relying Parties do not directly obtain a user’s Public Key. The process is as follows:

• When an end user goes to an agency web site to submit a form, the Agency will redirect the user to the Trust broker (the user will not be aware of this) and add its own context in hidden form fields.
• The Trust broker authenticates the agency and presents an authentication web page to the user prompting them to login.
• The Trust broker’s system will send back a security token signed by the end user with their Private Key.
• The Trust broker provides a SAML assertion to the Agency which contains user information and Certificate validity.

If the Trust broker or a relying party suspects an AUSkey holder’s Private Key has been compromised, it must promptly notify the ABR CA (see sections 4.8.3 and 5.7.3).

6.1.5 Key sizes

Root CA key size = 4096 RSA (generated in HSM).

CA key size = 2048 RSA (generated in HSM).

RA key size = 2048 RSA (generated in software).

End entity key size = 1024 RSA (Generated in user’s browser).

6.1.6 Public Key parameters generation and quality checking

Keys used within the AUSkey System generated using the RSA algorithm. The RSA algorithm does not require the generation of parameters.

6.1.7 Key usage purposes (as per X.509 v3 key usage field)

AUSkeys must only be used in compliance with the applicable CP, and all restrictions described in the applicable CP must be observed. The Key Usage extension field provides an indication of acceptable usage, regardless of whether this field is technically utilised by an application. This extension is marked as “critical” in AUSkey Certificates.

The correct values for key usage are set in these fields in accordance with the X.509v3 standard but the AUSkey System cannot control how third-party software applications interpret or act upon these. Reliance on key usage extension fields is dependent on correct software implementations of the X.509v3 standard and is outside of the control of the AUSkey System. (Examples of third party software include the Trust Broker software and any other software used to check AUSkey signatures or the chain of trust).

6.2 Private Key protection

6.2.1 Cryptographic module standards and controls

The ABR RCA and ABR CA use tamper resistant, tamper evident HSMs which are Common Criteria EAL 4+ certified, and FIPS 140-1, Level 3 validated.

End user Private Keys are kept in the key store which is a platform independent, XML text file that includes password protected Private Keys (PKCS#8 format, encrypted using PKCS#5) and X.509 Certificates. The key store includes metadata for each Key and Certificate entry to make it more efficient when used to store large numbers of Keys and Certificates.

6.2.2 Private Key (n out of m) multi-person control

For ABR CA Keys, M of N is not implemented in the HSM, however cloning of the device and tokens requires two iKeys which are allocated to ATO trusted personnel. Further confidential details are contained in the Key Management Plan.

M out of N is not applicable for end user Keys as these are not generated at the ABR CA or ABR RA.

6.2.3 Private Key backup

During the key signing ceremony the AUSkey Operations Manager backs up the ABR RCA and ABR CA Private Keys to two sets of backup tokens. The trusted elements include the Secret Key material and passphrases for the HSM, including the USB Keys for the key signing ceremony and HSM backup material. These trusted elements always remain under ABR Services’ control. Further confidential details concerning the ownership and custody of trusted elements are contained in the Key Management Plan.

Currently no Disaster Recovery site is in place, and that risk has formally been acknowledged and accepted by the AUSkey System owners. Further details are contained in the GKP001 Security Profile. Therefore all back-up Private Keys are sent to an off-site location (ATO premises where ATO trusted personnel are the key holders and storage is in a B class safe), via safe hand.

Other AUSkey component Keys are generated in the COTS software. The AUSkey Operations Manager backs them up to removable media and sends them and their passwords to a secondary site (via separate safe hands).

Backup of ABR CA and ABR RCA Private Keys is sensitive information and specific details are set out in the GKP001 Security Profile and the GKP004 Business Continuity and Disaster and Recovery Plan.

End user Private Keys are not generated by the ABR CA or ABR RA and thus cannot be backed up. If an end user loses their key store or forgets the password they must perform the registration process again and thus generate new Key(s).

6.2.4 Private Key archival

There is no end user Private Key backup or archival.

Only ABR CA and ABR RCA encryption (confidentiality) Private Keys are archived. Further confidential details are contained in the Key Management Plan.

6.2.5 Private Key storage on cryptographic module

The HSMs generate the ABR CA and ABR RCA Private Keys directly on the HSM token. It is only possible to transfer the Keys to another HSM token. Further confidential details are contained in the Key Management Plan.

For end users this is not applicable as the Private Key is generated in software and is not loaded into a cryptographic token.

6.2.6 Method of activating Private Key

The ABR RCA and ABR CA Keys are activated through the presence of the HSM and use of a user name, password and Key token.

End entity Private Keys are activated through use of a memorised password.

6.2.7 Method of deactivating Private Key

Private Keys are deactivated by removal of the token or HSM (where used) or by logging out.

6.2.8 Method of destroying Private Key

The ABR RCA and ABR CA Private Keys may be destroyed by reinitialising the HSM(s).

The software supplied for use by end entities is designed to ensure that the Private Keys are destroyed in memory by overwriting it when the software shuts down.

6.2.9 Cryptographic Module Rating

See section 6.2.1.

6.3 Other Aspects of Key Pair Management

6.3.1 Public Key archival

The ABR CA archives all Certificates it generates. ABR CA archival is part of the archival process which requires the storage of software and hardware to allow the reconstitution of the ABR CA if required.

For the purposes of the Internet X.509 Public Key Infrastructure CP and CPS Framework, the ATO is the archive agent. The Public Keys of AUSkey Certificates are archived in accordance with section 5.5.

6.3.2 Certificate operational periods and Key Pair usage periods

In general, AUSkey certificates issued to end users have an operational period of two years, and the key usage period is also two years. For more details please see the relevant CP.

The ABR CA has a certificate operational period and a key usage period of 10 years.

Note: AUSkey System Certificate lifetimes are nested and the Key lifetime depends on the Certificate life. That is, an issued Certificate (of an end entity or a CA) expires before the Certificate of the CA that issued it. Otherwise, after the ABR CA Certificate’s expiration, the issued Certificate becomes invalid, even if it hasn’t expired itself.

Key lifetimes are set as a matter of policy and will depend on a number of factors, with shorter Key lengths usually having shorter usage periods.

6.4 Activation data

Activation data refers to data values other than Private Keys that are required to operate Private Keys or cryptographic modules containing Private Keys, such as a PIN or passphrase.

6.4.1 Activation data generation and installation

Generally critical PKI infrastructure passwords are generated during key ceremony events. The first of these is the Key Signing Ceremony, where most of the PKI system passwords are created. Subsequent to this, are the Key SigningCeremonies, where passwords are updated. Between these key ceremony events the majority of the passwords are not changed. The main exception to this is in response to any suspected password compromise, which may require the updating of one or more passwords as part of the recovery process.

End entity passwords for AUSkeys are created by the AUSkey Holders themselves according to strong password rules recommended by DSD. The system guides the end user through the process of strong password creation. The policy itself is confidential and only detailed in GKP001 Security Profile.

6.4.2 Activation data protection

This is sensitive information and is detailed in the confidential GKP001 Security Profile.

6.4.3 Other aspects of activation data

No stipulation.

6.5 Computer security controls

6.5.1 Specific computer security technical requirements

Controls in place include:

• a configuration baseline and a configuration change control process
• performance of regular and frequent systems operability tests to prove the correct operation of critical PKI components
• strong authentication required for core PKI system access
• role segregation and No Lone Zone procedures
• restrictions and controls on the use of system utilities
• the use of monitoring and alarm systems to detect and warn of unauthorised access to computer system resources
• logging of all system access and use.

6.5.2 Computer security rating

Hardware in use meets standards including Common Criteria EAL4 and FIPS 140-1.

6.6 Life cycle security controls

6.6.1 System development controls

AUSkey Operators do not have access to the source code of AUSkey System software; either the COTS or AUSkey application components. ABR staff or contractors do not carry out any development on the COTS application source code. Development of the AUSkey application components is only carried out in a development environment by AUSkey developer personnel authorised to do so through formal change planning and management processes and in accordance with:

• those change planning and management processes (which include, for example, security personnel separately assessing what security measures are required, such as penetration testing and additional threat risk assessments), and
• information systems delivery and software development methodologies that apply to ATO application developments (for example AUSkey application source code is protected by a server version control check-in check-out system, where code can only be checked out with prior authorisation, is version controlled, and can only be checked in following a peer review process).

Further information can be found in the Security Plan.

6.6.2 Development environment security

Test and production data is strictly segregated and developers never have access to the production environment. This is achieved by locating the Test CA infrastructure in separate server cabinets from that of AUSkey System production environments. The AUSkey System uses the same evaluated products in the Test CA infrastructure as in the Production CA environments. The test environments use test Keys not production Keys.

Further information relating to development facility security can be found in the Security Plan.

6.6.3 Change control

The AUSkey Operations Manager categorises changes depending on the approval level required, which is determined by the type of change and the level of difficulty and risk involved in executing it.

Changes are categorised as:

• Pre-Approved
• Standard
• Emergency.

Further information surrounding this subject can be found in the Security Plan.

6.6.4 Software integrity and security management controls

Maintaining the security and integrity of the ABR CA is essential, and is the paramount operational objective. The AUSkey Operators must conduct a virus scan on any software or media prior to loading it onto any ABR CA or ABR RA component. More details surrounding the requirements of connecting media to AUSkey System components can be found in the following documents:

• GKP001 Security Profile (classified)
• Australian Cyber Security Centre Information Security Manual (ISM), 2020 Release
• Attorney General’s Department Protective Security Policy Framework (2019) and associated policies, protocols and guidelines.

Security management controls for the AUSkey System include intrusion detection management systems, site protection management servers, and business availability monitoring systems. Further information on tools and procedures to ensure the correct operation and security configuration of the AUSkey System can be found in the Security Plan.

6.7 Network security controls

The network security controls include:

• firewalls
• strong authentication
• physical access controls
• mechanisms to prevent denial-of-service attacks
• password and other logical access controls.

The network security controls were developed after conducting a comprehensive threat and risk assessment.

The AUSkey System environment:

• is located within a secure physical environments which has been rated by ASIO T4 to SCEC standards
• is logically located behind a ASD Certified Gateway environment
• automatically generates time-stamped logs using the system clock of the computer on which they were generated
• requires all persons responsible for logging information to have appropriate access in accordance with the AUSkey Services Systems Access Register.

All successful and unsuccessful attempts to communicate with the ABR CA are logged in the ABR CA component system logs.

AUSkey Operation staff do not have any specific network security tasks. If they suspect a network security incident (such as a partial firewall failure) they must report it to the AUSKey Security Manager and the IT Service Desk.

6.8 Time-stamping

All audit log entries and transactions must be time-stamped and the asserted times shall be accurate to within +/- 5 seconds.

7 Certificate, CRL and OCSP profiles

7.1 Root CA Certificate Profile

Certificate Fields
Attribute	Value
version	“3” to indicate X.509 version 2 certificates.
issuer	Distinguished Name of the issuing CA: Common Name = Australian Business Register Root CA OU = Certification Authority Organisation = Australian Business Register Country = AU.
validity	20 years maximum (expressed as “From” and “To” dates)
subject	Distinguished Name of the certificate subject, in this case the device associated with the private key: Common Name = Australian Business Register Root CA OU = Certification Authority Organisation = Australian Business Register Country = AU.
subjectPublicKeyInfo	The public key and the public key algorithm (RSA 4096 with a SHA-512).
Certificate Extensions
Attribute	Value
Key size	4096.
keyUsage	Defines valid purposes, in this case: crlSigning, keyCertSigning.
certificatePolicies	CP information such as the OID and the URL where the CPS is available: Policy Identifier OID = 1.2.36.1.3001.1.1.1 Certificate Practice Statement available on this AUSkey Terms and Conditions page User Notice = This certificate may only be used for the purpose permitted in the applicable Certificate Policy. Limited liability applies - refer to the Certificate Policy.
basicConstraints	Indicates if the subject may act as a CA and should be set to “Yes”.
Subject Key Identifier	160-bit SHA-1 hash of the value of the BIT STRING of the subjectPublicKey (Method 1 described in RFC5280).
Authority Key Identifier	Same value as Subject Key Identifier.

7.2 CA Certificate profile

Certificate Fields
Attribute	Value
version	“3” to indicate X.509 version 2 certificates.
Issuer	Distinguished - Name of the issuing CA Common Name = Australian Business Register Root CA OU= Certification Authority Organisation = Australian Business Register Country= AU
validity	10 years maximum (expressed as “From” and “To” dates).
subject	Distinguished Name of the certificate subject, in this case the device associated with the private key. Common Name = Australian Business Register CA OU = Certification Authority Organisation = Australian Business Register Country = AU.
subjectPublicKeyInfo	The public key and the public key algorithm (RSA 2048 with a SHA-256 digest).
Certificate Extensions
Attribute	Value
Key size	2048.
keyUsage	Defines valid purposes, in this case: crlSigning, keyCertSigning.
certificatePolicies	CP information such as the OID and the URL where the CPS is available: Policy Identifier OID = 1.2.36.1.3001.1.1.1.1 Certificate Practice Statement available on this AUSkey Terms and Conditions page User Notice = This certificate may only be used for the purpose permitted in the applicable Certificate Policy. Limited liability applies - refer to the Certificate Policy.
basicConstraints	Indicates if the subject may act as a CA and should be set to “Yes”.
Subject Key Identifier	160-bit SHA-1 hash of the value of the BIT STRING of the subjectPublicKey (Method 1 described in RFC5280).
Authority Key Identifier	Same value as Australian Business Register Root CA Subject Key Identifier.

7.3 RA Certificates profile

Certificate Fields
Attribute	Value
version	“3” to indicate X.509 version 2 certificates.
issuer	Distinguished Name of the issuing CA: Common Name = Australian Business Register CA OU = Certification Authority Organisation = Australian Business Register Country = AU.
validity	10 years maximum (expressed as “From” and “To” dates).
subject	Distinguished Name of the certificate subject, in this case the device associated with the private key. Common Name = Australian Business Register RA OU = Certification Authority Organisation = Australian Business Register Country = AU.
subjectPublicKeyInfo	The public key and the public key algorithm (RSA 2048 with a SHA-256).
Certificate extensions
Attribute	Value
Key size	2048.
keyUsage	Defines valid purposes, in this case: Digital Signature, Non-Repudiation.
certificatePolicies	CP information such as the OID and the URL where the CPS is available: Policy Identifier OID = 1.2.36.1.3001.1.1.4.1 Certificate Practice Statement available on this AUSkey Terms and Conditions page User notice = This certificate may only be used for the purpose permitted in the applicable Certificate Policy. Limited liability applies - refer to the Certificate Policy.
Basic constraints	Indicates if the subject may act as a CA and should be set to “False”.
Subject key identifier	160-bit SHA-1 hash of the value of the BIT STRING of the RA’s subjectPublicKey (Method 1 described in RFC5280).
Authority key identifier	Same value as Australian Business Register CA Subject Key Identifier.

7.4 Entity certificate profiles

For end entity certificate profiles, for example for AUSkey Standard or device certificates, please see the relevant CP.

7.5 Root CA profile

CRL attributes
Attribute	Value
CRL issue period	A new CRL is issued each time the Root CA is brought online to renew the Australian Business Register CA.
CRL validity	8 years.
CRL signature digest	SHA-256

7.6 CA CRL Profile

CRL attributes
Attribute	Value
CRL issue period	90 minutes.
CRL validity	7 hours.
CRL signature digest	SHA-256
revokedCertificates	List of revoked certificates by serial number.
reasonCode	Not included in the CRL.
invalidityDate	Date at which it is known or suspected that the private key was compromised or that the certificate should otherwise be considered invalid.

8 Compliance audits and other assessments

The infrastructure of the AUSkey System, including the operations of the ABR CA, requires auditing on a regular basis to ensure compliance with this CPS and all applicable CPs. The detailed process of the AUSkey System audits is not publicly disclosed.

In addition to the audit requirements under this CPS, Gatekeeper accreditation requires the conduct of annual audits to ensure compliance with the Gatekeeper policies and criteria (PDF, 1.84MB) .The ABR must arrange an annual audit to be completed on or about the anniversary of the initial accreditation. The audit must be carried out by an Authorised Auditor from the Gatekeeper Audit Panel.

8.1 Frequency or circumstances of assessment

The AUSkey System will be audited at least once per annum, and may be audited more frequently if required. The auditor will be appointed by the AUSkey PMA.

Ongoing compliance with Gatekeeper Accreditation Criteria will be assessed at least annually by means of a compliance audit undertaken by the Gatekeeper Competent Authority or its nominee.

8.2 Identity/ qualifications of assessors

Auditors require expertise in relation to:

• Public Key technology
• IT security procedures
• any other relevant areas of expertise required of an evaluator to perform an evaluation properly and expertly against the accreditation criteria.

8.3 Assessor's relationship to assessed Entity

Auditors must be independent third parties and have no actual or potential conflict of interest during the period of the audit.

8.4 Topics covered by assessment

The purpose of audits is to ensure that AUSkey System PKI infrastructure elements such as each CA and RA:

• comply with accreditation criteria and policies, and
• comply with the requirements set out in:
  • this CPS
  • all applicable CPs
  • GKP001 Security Profile
  • GKP004 Business Continuity and Disaster and Recovery Plan
  • Privacy Statement
  • GKP005 CA Operations Manual
  • GKP006 RA Operations Manual. 

Topics covered by the assessment are based on the Gatekeeper PKI Framework, which identifies a series of compliance audit activities that must be performed to ensure the operational integrity and suitability of the infrastructure.

8.5 Actions taken as a result of deficiency

Any deficiencies identified by the auditor will be documented against the audit assessment criteria in a formal written report and must be presented to the AUSkey PMA. The AUSkey PMA will determine actions to be taken in relation to any deficiency and will only determine corrective action after consideration of any auditor recommendations. Where the identified deficiency relates to accredited systems, authorised representatives of accrediting agencies such as AGIMO and DSD will be included in reviewing results and formulating solutions.

All required corrective action must be verified to have been completed within the agreed timeframe, and failure to adequately address deficiencies identified in an audit in an agreed timeframe may result in withdrawal of accreditation.

The AUSkey Operations Manager, under the direction and oversight of the AUSkey PMA, is responsible for the on-going management of the AUSkey System accreditation as a Gatekeeper accredited PKI.

8.6 Communication of results

The communication of audit results must balance the need for accountability and transparency with the inherent need for confidentiality in relation to certain security strategies.

The results of an audit are confidential and require the auditor to communicate them only to authorised representatives of accrediting bodies and the AUSkey PMA. In relation to Gatekeeper accreditation audits, the audit report will be submitted to the Gatekeeper Competent Authority at the same time as the AUSkey PMA. Results of the compliance audit against Gatekeeper criteria and policies may be released at the discretion of the AUSkey PMA.

The AUSkey PMA will oversee the communication of results and any communication on actions taken as a result of deficiency with the relevant entities, for example the Gatekeeper Competent Authority or DSD.

The AUSkey PMA is also responsible for determining how and when results should be communicated to participating agencies.

9 Other business and legal matters

Note: an order of precedence applies to the documents forming the applicable contract – see section 1.1.4.

9.1 Privacy of personal information

The subject field of an AUSkey Certificate will contain personal information relating to a business entity (where that business entity is an individual), and where an AUSkey Standard Certificate, will contain personal information about the AUSkey holder. Personal information about the AUSkey Holder of an AUSkey Device Certificate is stored in an information repository.

All information collected as part of an entity’s or person’s interaction with the AUSkey System that is Personal Information will be protected in accordance with the requirements of the Privacy Act 1988 (Cth) and the Privacy Statement.

See the relevant CP for details on personal information contained in a particular type of Certificates.

9.2 Representations and warranties

The ABR CA, the ABR RA and the ABR RCA are, in relation to the AUSkey System, responsible for complying with their respective obligations under the Gatekeeper Core Obligations Policy as, and in the way, identified in this CPS.

Except as set out in this CPS, the ABR Registrar and the Commonwealth give no representation or warranty of any kind, either express or implied, in relation to the AUSkey System (including as to its operation, performance or fitness for a particular purpose).

For the purposes of this section 9.2, and sections 9.3 and 9.4, a reference to:

• the AUSkey System – includes a reference to any part of it, and to any activity, service or product associated with or used in the delivery of the AUSkey System or any part of it
• the ABR Registrar – includes a reference to the ABR CA, the ABR RA, the ABR RCA, ABR Services and their respective officers, employees, contractors and agents
• the Commonwealth – includes a reference to the Commissioner of Taxation, the ATO, all other Commonwealth Agencies, and their respective officers, employees, contractors and agents.

9.3 Disclaimers of all other warranties

All conditions and warranties which would otherwise be implied into this CPS are excluded to the full extent permitted by law. If any condition or warranty is implied by legislation, and that legislation avoids or prohibits excluding or modifying the application of, the exercise of, or liability under, that condition or warranty, that condition or warranty will be taken to be included provided that the liability of the ABR Registrar and/or the Commonwealth for any breach of that condition or warranty is limited to:

• supplying the services (to which the condition or warranty applies) again, or
• paying the cost of having those services supplied again.

9.4 Limitation of liability

AUSkeys are only issued for business entities (within the AUSkey COI) to authenticate themselves to, and carry out electronic transactions with, SBR Agencies (within the AUSkey COI). Any person who uses, or relies on, an AUSkey in any other circumstances does so at their own risk and responsibility.

Subject to sections 9.2 and 9.3:

• neither the ABR Registrar nor the Commonwealth can be held responsible for any misuse of an AUSkey by the AUSkey Holder or any other party in possession of the corresponding Private Key, for any unchecked acceptance of an AUSkey by the Trust Broker or a Relying Party, or for any use or acceptance of an AUSkey outside of the purposes for which it was issued
• neither the ABR Registrar nor the Commonwealth will be liable in any way for any special, indirect damages (including damages for loss of business profits, business interruption, and loss of business information or computer programs) or exemplary or punitive damages or damage to personal property which may arise directly or indirectly in respect of access to or use of the AUSkey System
• where the ABR Registrar or the Commonwealth is legally liable to compensate another party referred to in this CPS, that liability will be reduced proportionally to the extent that any negligent act or omission on the part of the other party contributed to the relevant liability, loss, damage, cost or expense.

9.5 Indemnities

Any indemnities are contained in the Conditions of Use or other applicable contracts.

9.6 Notices

Any notice under this document must be in writing and must be sent to the intended recipient by:

• hand delivery
• ordinary or registered pre-paid post
• facsimile transmission
• email transmission (provided the sender holds an AUSkey which has not been revoked and digitally signs the message using the sender’s Private Authentication Key).

A notice, consent, request or other communication will be taken to have been received by the recipient if sent:

• by hand delivery or registered pre-paid post on the date it is delivered
• by ordinary pre-paid post three business days (or if posted from or to a place outside Australia, seven business days) after the date of posting
• electronically on the business day next following the day on which the transmission was sent in its entirety to the recipient’s facsimile machine or email system (as the case may be).

9.7 Amendments

This document may be amended by or under the authority of the AUSkey PMA as follows:

• A material change is any change to this document that:
  • creates, or reflects the creation of, a new CP for a different COI
  • affects the reliance, level of assurance or acceptability of AUSkey Certificates issued under this document, or otherwise
  • materially affects AUSkey holders, relying parties or other participants in the AUSkey system.
• Changes to contact details set out in, or editorial or typographical corrections to, this document are not material changes.
• A material change to this document requires the prior consent of the Gatekeeper Competent Authority to that change. Where a material change is made to this document, the OID of this document must be changed.
• Subject to the above, a change to this document takes effect when the revised document is published online by or under the authority of the AUSkey PMA.

9.8 Dispute resolution procedures

If a dispute arises in connection with this document, the parties to that dispute undertake in good faith to use all reasonable endeavours to settle the dispute by negotiation or mediation as follows.

• A party to that dispute may give the other party or parties to that dispute a notice setting out the details of that dispute.
• If those parties are not able to resolve that dispute within seven days of receiving that notice, then either party may propose in writing to the others an independent mediator, having appropriate qualifications and practical experience, to be appointed by them to resolve that dispute.
• If those parties are not able to agree on that proposed or an alternate mediator, the parties may seek mediation in accrodance with the mediation rules of the Australian Disputes Centre (ADC). The parties
  • must promptly furnish to the mediator determined above (imposing appropriate obligations of confidence) all information reasonably requested by the mediator relating to the dispute
  • must co-operate fully with that mediator to allow the mediator to render a decision within 30 days of it receiving that information (or as soon as practicable thereafter)
  • will be bound by the decision of that mediator
  • will share equally the fees and expenses of that mediator.
• If those parties do not think that the process described above is appropriate, the parties can agree a different process that is more suitable to the circumstances of the dispute.
• Where all the parties to the dispute are agencies, the process described above only applies if those agencies have not otherwise agreed a process for resolving a dispute of that nature between them.

9.9 Governing law

This document is governed by the laws for the time being in force in the Australian Capital Territory, Australia.

9.10 Fees

No fees are payable to the ABR Registrar (or ABR Services) in relation to:

• applications for, or the issuance of, AUSkeys
• the provision of Certificate Information, CRLs or other AUSkey revocation or status information to the trust broker
• members of the AUSkey COI using or participating in the AUSkey System (including their use of AUSkeys in the course of electronic transactions between them).

9.11 Financial responsibility

No stipulation.

9.12 Confidentiality

In this section, ‘Participant’ means a participant in the AUSkey System as described in section 1.3.

Where a participant in the AUSkey System receives or obtains, in the course of such participation, another participant’s confidential information, it must secure that information against disclosure and use, and must not disclose or use that information except:

• to its employees, officers, internal management personnel or professional advisers in connection with the AUSkey System (and in the case of an Agency – to its Minister, or in response to a request by a House or a Committee of the Parliament of the Commonwealth of Australia)
• as required, authorised or permitted by law or by the Conditions of Use or other applicable contract, the relevant CP, or this CPS
• with that other Participant’s express permission.

‘Confidential information’ means, in relation to a participant in the AUSkey System, information relating to its business, affairs or clients which is confidential in nature and which the other participant in question knows (or should reasonably know) is confidential.

9.13 Intellectual property

No further stipulation.

Note: See individual AUSkey System materials – for example, the front page of this CPS.

9.14 Term and termination

The ABR Registrar can terminate the AUSkey System at its own discretion, or otherwise as may be required by the Commonwealth government. See also section 5.8. No further stipulation.

9.15 Compliance with applicable Law

No stipulation.

9.16 Miscellaneous provisions

9.16.1 Entire agreement

No stipulation.

9.16.2 Assignment

No stipulation.

9.16.3 Severability

In the event that a clause or provision of this CPS, the relevant CP, or applicable contract is held to be unenforceable or illegal by a court of law or other tribunal having authority, that clause or provision may be severed from the relevant document and the remainder of the document will remain valid.

9.16.4 Enforcement

No stipulation.

9.16.5 Force majeure

No stipulation.

9.16.6 Other provisions

No stipulation.

10 Appendix A: OIDs and Certificate Policies under this CPS

OID	Certificate Policy (CP)
1.2.36.1.3001.1.1.1	ABR Root Certification Authority (RCA) OID
1.2.36.1.3001.1.1.7.1	Standard CP (covers Users and Administrators)
1.2.36.1.3001.1.1.8.1	Device CP

Version 1.3 updated for 30 March 2020

Last modified

27 March 2020

 

Certificate policy – AUSkey

Version 1.3 – updated for 30 March 2020

1 Overview

1.1 Overview

The ABR Registrar has established the AUSkey System as Public Key Infrastructure (PKI) to facilitate internet-based electronic transactions between business entities and agencies, and manages the AUSkey System’s operational Certification Authority (the ABR CA).

This document is the GKP003 Standard Certificate Policy. This Certificate Policy (CP) sets out the rules applying to, and provides policy and operational guidance on, the deployment of AUSkey Standard Certificates issued by the ABR CA.

This CP must be read in conjunction with the following documents, which can be accessed on this page.

1.1.1 Standard Business Reporting (SBR) program

See CPS section 1.1.1.

1.1.2 The AUSkey system

See CPS section 1.1.2.

1.1.3 Community of Interest (COI)

See CPS section 1.1.3.

Note: the COI for AUSkey Certificates is restricted to government Agencies who are part of the SBR Program, and Business Entities who have an Australian business number (ABN).

1.1.4 Standard certificates

AUSkey Standard Certificates are issued to individuals acting on behalf of business entities that:

• are registered in the ABR as having an ABN (as the business entity is identified in the AUSkey Certificate by way of its ABN), and
• wish to transact electronically with SBR Agencies.

Note: individuals acting for agencies within the AUSkey COI may also be issued with AUSkey Standard Certificates in situations where the agency also acts as a business entity.

1.1.5 This Certificate policy and the Certification Practice Statement

See CPS section 1.1.4.

Note: a document hierarchy applies: the provisions of the Conditions of Use or other relevant contract override the provisions of this CP, and the provisions of this CP override the CPS.

1.2 Document name and identification

This document is known as the GKP003 Standard Certificate Policy. It is identified by the object identifier (OID) 1.2.36.1.3001.1.1.7.1, based on the following structure:

1	ISO code
2	Member Body
36	Australia
1	Government
3001	Australian Business Register (ABR)
1	Australian Business Register Root CA (RCA)
1	Australian Business Register Operational CA (OCA)
7	Standard Certificate Policy
1	Version number

1.2.1 Attribution

See CPS section 1.2.1.

1.3 AUSkey participants

1.3.1 ABR Root Certification Authority (ABR RCA)

See CPS section 1.3.1.

1.3.2 ABR Certification Authority (ABR CA)

See CPS section 1.3.2.

1.3.3 ABR Registration Authority (ABR RA)

See CPS section 1.3.3.

1.3.4 Business entities

See CPS section 1.3.4.

1.3.5 Business associates

See CPS section 1.3.5.

1.3.6 Users

See CPS section 1.3.6.

1.3.7 Administrators

See CPS section 1.3.7.

1.3.8 Device custodians

See CPS section 1.3.8.

1.3.9 Devices

See CPS section 1.3.9.

1.3.10 Relying parties

See CPS section 1.3.10.

1.3.11 Trust broker

See CPS section 1.3.11.

1.4 Certificate usage

1.4.1 Appropriate certificate use

The appropriate use of an AUSkey Standard Certificate is limited to the certificate holder authenticating him or herself to, and carrying out an electronic transaction with, an SBR Agency within the AUSkey COI on behalf of the Business Entity identified in that certificate.

The typical transaction would be the submission of a form for a Business Entity with revenue reporting and payment obligations to an SBR Agency, for example lodgment of a Business Activity Statement with the ATO.

1.4.2 Limits on use

An AUSkey Standard Certificate is designed for its certificate holder (on behalf of the Business Entity identified by its ABN in that Certificate) to authenticate him or herself to, and to carry out electronic transactions with, SBR Agencies within the AUSkey COI. The AUSkey System does not support use of AUSkeys by or with any other relying parties. Any person who uses, or relies on, an AUSkey Standard Certificate in any other circumstances does so at their own risk and responsibility.

Note: an AUSkey does not provide any indication of the level of authority, delegation or privileges that the AUSkey Holder may possess, and is for authentication rather than authorisation purposes.

1.4.3 Prohibited certificate uses

Any kind of unlawful or improper use of an AUSkey Standard Certificate is prohibited.

1.5 Policy administration

See CPS section 1.5.

1.6 Definitions and acronyms

See CPS section 1.6.

2 Publications and repository responsibilities

2.1 Repositories and publication information

The AUSkey System operates several repositories supporting its operations.

2.2 Publications

See CPS section 2.1.1.

2.3 The Certificate Revocation List (CRL)

See CPS section 2.1.2.

2.4 Internal data repositories

See CPS section 2.1.3.

3 Identification and authentication

3.1 Naming

Every Certificate issued under this CP must have a Distinguished Name (DN) that is unique to the certificate holder the subject of the certificate and compliant with the X.509 standard. That DN must be in the form of a X.509 printable string and may not be blank.

That DN will be present in the certificate’s subjectName field, with the common name in the form <User given names><Space><User family name>, as set out in the certificate profile outlined in section 7 of this CP.

The certificate holder’s common name is a component of that DN, and is supplied in the application for the AUSkey Standard Certificate. The name supplied must be meaningful, unambiguous and (in the Business Entity concerned) unique to the Certificate Holder.

The AUSkey System does not allow anonymity or pseudonymity for any AUSkey Certificate subject names.

Note: an AUSkey Standard Certificate identifies the certificate holder in its subjectName field, and the ABN of the Business Entity for which it is held in its subjectOrganisation field – see section 7.1.

Any disputes in relation to names in AUSkey Standard Certificates will be resolved by the AUSkey Policy Management Authority (AUSkey PMA).

3.2 Initial identity validation

See section 3.1.2 of the CPS.

Note: for identify validation, the AUSkey system allows identity details to be entered online, which are then validated to a previous documentary based Evidence of Identity (EOI) process or processes. In some cases documentary EOI is required, such as where the identity details supplied are insufficient or incorrect.

An application for an AUSkey Standard Certificate must be authorised by either:

• an Administrator for that business entity (a person holding, for that business entity, a valid AUSkey Standard Certificate with administrator level privileges)
• a validated Business Associate of that business entity (a person who has had both their identity, and their status as a business associate of that same business entity, validated).

3.2.1 Initial administrator identity validation

In order to obtain administrator level privileges in relation to an AUSkey Standard Certificate, the certificate holder (or proposed certificate holder) of that Certificate must:

• supply or confirm his or her given names, family name, and email address (the supply of his or her telephone number is optional)
• supply a display name that will be displayed to other administrators of the same business entity concerned to identify him or her as an administrator
• supply his or her date of birth and such other identity details or information as the ABR RA may require to validate or if necessary establish his or her identity in accordance with existing ABR processes on identity verification.

Note: The existing ABR processes on identity verification arise principally because the ABR Registrar must, under the A New Tax System (Australian Business Number) Act 1999, be satisfied that an individual’s identity has been established before including their name in a business entity’s ABR entry (for example as an ‘associate’ or ‘nominated representative’ of that business entity).

For applications for Standard AUSkeys with administrator level privileges, existing ABR processes are applied to verify the identity of the proposed AUSkey holder (and the applicant, if a different person):

• To validate to a previous documentary evidence based EOI process – see proving your identity or contact us
• For documents to initially establish identity – see proving your identity

Applications for Standard AUSkeys with User level privileges, and Device AUSkeys, to be held for a business entity must be made or approved by an administrator (for that same business entity) whose identity has been verified as above and who verifies the identity of the proposed AUSkey holder.

3.2.2 Initial business associate validation

Where an application for an AUSkey Standard Certificate (to be held by the proposed certificate holder for a business entity) is made by, or is to be authorised by, a business associate of that business entity, that business associate must supply:

• his or her given names, family name, date of birth, and such other identity details or information as the ABR RA may require to validate or if necessary establish his or her identity in accordance with existing ABR processes on identity verification
• such other information as the ABR RA may require to confirm that he or she is listed in the ABR as a business associate of that same business entity.

Note: Under the A New Tax System (Australian Business Number) Act 1999, the ABR Registrar must first be satisfied as to an individual’s identity before listing that person, in a business entity’s ABR entry, as an ‘associate’ of that business entity. Where an AUSkey application is made or authorised by a business associate, the existing ABR processes on identity verification are applied to validate that person’s identity and that they are listed in the ABR as an ‘associate’ of the relevant business entity.

3.2.3 Initial user identity validation

Where an application is made for an AUSkey Standard Certificate, to be held by the proposed User for a business entity (and in respect of which that User is not to have Administrator level privileges):

• that user must supply or confirm his or her given names, family name, and email address (the supply of his or her telephone number is optional)
• the validation of that user’s identity is the responsibility of, and is provided by, that business entity’s Administrator or business associate (as the case may be) approving that application.

3.3 Identification and authentication for renewal requests

Not supported.

3.4 Identification and authentication for revocation request

If the revocation of an AUSkey Standard Certificate (held by the Certificate Holder for a business entity) is requested through the AUSkey Manager by that certificate holder, or by an administrator for that same business entity, that certificate holder or administrator (as the case may be) identifies and authenticates him or herself to the AUSkey Manager using their AUSkey (a website logon, including a valid password).

If a telephone request is made to an AUSkey operator for the revocation of an AUSkey Standard Certificate (held by the certificate holder for a business entity), the caller must provide sufficient identity details to allow the AUSkey operator, in accordance with existing ABR processes, to validate the caller’s identity, and verify their status as that certificate holder or an administrator for or a business associate of that same business entity.

All such revocation requests must come through the ABR RA. The ABR CA will only action a revocation request if the ABR CA successfully validates the request by verifying the ABR RA’s signing certificate.

4 Certificate life-cycle operational requirements

This section deals only with the life-cycle operational requirements for AUSkey Standard Certificates. For life-cycle event details for AUSkey Device Certificates, see the applicable CP. Details of certain infrastructure certificates not used by any end entities may be found in the CPS. The certificate life-cycle events are described at a high-level, from the perspective of human end users.

Note: all certificate life-cycle event requests must come through a valid ABR RA communication, using standards based formats such as Public Key Cryptography Standards (PKCS) payloads. At a technical level, a request will only succeed if the ABR CA is able to successfully validate the request by verifying the RA’s signing certificate.

4.1 Certificate application

In most cases, AUSkey Standard Certificate applications are carried out online through the AUSkey Manager and AUSkey website. However, the AUSkey System provides alternate processes so that, where necessary, process steps can be carried out manually via AUSkey Operators. Sections 4.1.2 to 4.1.6 describe the usual process steps for AUSkey Standard Certificate online applications.

4.1.1 Who can submit an application for an AUSkey Standard Certificate

The AUSkey System supports the following AUSkey Standard Certificate applications.

An application for an AUSkey Standard Certificate with user level privileges to be held by a proposed new User for a business entity may be made by either:

• an Administrator for that same business entity
• that proposed new User (but the application must be authorised by an administrator for that same business entity).

An application for an AUSkey Standard Certificate with administrator level privileges – to be held by a proposed new administrator for a business entity may be made by either:

• an (existing) administrator for that same business entity
• a business associate of that same business entity.

• An administrator for a business entity may apply to vary the privileges associated with a current AUSkey Standard Certificate (held for that same business entity) from user level to administrator level or from administrator level to user level.

Note: a business entity’s first AUSkey application must be made by a business associate of that business entity, and must be for an AUSkey Standard Certificate with administrator privileges.

4.1.2 Administrator applies for an AUSkey for a new user

The process for an administrator for a business entity applying online for an AUSkey Standard Certificate to be held by a new user for that same business entity is generally as follows.

The administrator authenticates to the AUSkey Manager using their AUSkey.

The administrator enters and submits details of the new user, including their:

• given names and family name
• email and confirmation email address
• privilege level (as user).

The AUSkey System sends the new User a notification email informing them that they are being issued an AUSkey Standard Certificate (with user privileges).

The new user clicks on a link in the notification email to initiate certificate activation, and enters and submits the displayed Captcha code (to begin the issuance process).

4.1.3 New user applies for their own AUSkey

The process for a person applying for an AUSkey Standard Certificate to be held by them as a user for a business entity is generally as follows.

The applicant accesses an unauthenticated page on the AUSkey website and follows the system prompts to register.

The applicant enters and submits:

• the displayed Captcha code
• the ABN of that business entity
• their given names and family name
• their email and confirmation email address
• their privilege level (as user)
• the email address of an administrator for that business entity to approve their application.

On submission, an activation code is displayed to the applicant.

The AUSkey system sends that administrator an email informing them of the new application, and the administrator authenticates to the AUSkey Manager using their AUSkey, and locates and approves that application.

The AUSkey system sends the applicant a notification email informing them that their application has been approved.

The applicant clicks on a link in the notification email, and enters and submits the activation code (to initiate certificate activation) and the displayed Captcha code (to begin the issuance process).

4.1.4 Administrator applies for an AUSkey for a new administrator

The process for an administrator for a business entity applying for an AUSkey Standard Certificate to be held by a new administrator for that same business entity is generally as follows.

The administrator authenticates to the AUSkey Manager using their AUSkey.

The administrator enters and submits details of the new Administrator, including their:

• given names and family name
• email and confirmation email address
• privilege level (as administrator).

The AUSkey System sends a notification email to the new administrator informing them that they have been nominated for an AUSkey Standard Certificate (with administrator privileges).

The new Administrator clicks on a link in the notification email and is taken to the application form in the AUSkey website.

The new administrator enters and submits;

• the displayed Captcha code
• a display name that will be displayed to other administrators for that business entity to identify them as administrator
• their identity validation details (as described in section 3.2.1).

Once the new aministrator’s identity is validated and confirmed, the AUSkey System sends a second notification email to the new administrator confirming that they have registered successfully.

The new administrator clicks on a link in the email, and enters and submits the displayed Captcha code to initiate certificate activation and begin the issuance process.

4.1.5 Business associate applies for an AUSkey for a new administrator

The process for a business associate of a business entity applying for an AUSkey Standard Certificate – to be held by a new administrator for that same business entity is generally as follows.

The business associate accesses an unauthenticated page on the AUSkey website.

The business associate identifies they are a business associate, identifies whether they, or another person, is the new administrator, and enters and submits:

• the displayed Captcha code
• the ABN of that business entity
• their identity validation details (as described in section 3.2.2)
• where the new administrator has been identified as either
  • the business associate – a display name that will be displayed to other administrators within that business entity to identify them as an administrator
  • another person – that other person’s given names and family name, and email and confirmation email address.

Once the business associate’s identity and status (as a listed business associate of that business entity) is validated and confirmed:

• where the business associate is the new administrator
  • an activation code is displayed to the business associate
  • the AUSkey System sends a notification email to the business associate confirming that they have registered successfully
  • the business associate clicks on a link in the notification email and enters and submits the activation code (to initiate certificate activation) and the displayed Captcha code (to begin the issuance process), or
• where another person is the new Administrator, the process continues through steps 3 to 7 in section 4.1.4 above save that
  • at the end of step 5, an activation code is displayed to the new administrator
  • in step 7, the new administrator enters and submits the activation code (to initiate certificate activation) and the displayed Captcha code (to begin the issuance process).

4.1.6 Administrator varies privilege level of an existing AUSkey

Note: the privilege level of an AUSkey Standard Certificate is managed outside the certificate. A variation to the privilege level (from user level to administrator level, or vice versa) does not result in, or require, a new certificate being issued.

The process for an administrator for a business entity to vary the privilege level of an existing AUSkey Standard Certificate held for that business entity is generally as follows.

The administrator authenticates to the AUSkey Manager using their AUSkey.

The administrator selects the AUSkey Standard Certificate, selects the privilege level to which it is to be varied, and submits the request for that variation.

The AUSkey system sends a notification email to the certificate holder informing them that an administrator has approved variation to the privilege level associated with their certificate

• Where the variation is from administrator to user level, the system applies the variation.
• Where the variation is from user level to administrator level, the following steps apply.

The certificate holder clicks on the link in the notification email, is taken to a form in the AUSkey website, and enters and submits:

• the displayed Captcha code
• a display name that will be displayed to other administrators within that business entity to identify them as an administrator
• their identity validation details (as described in section 3.2.1).

Once the certificate holder’s identity is validated and confirmed, the AUSkey System applies variation and sends a second notification email to the certificate holder informing them that they now have administrator privileges.

4.2 Certificate issuance

The typical issuance of an AUSkey Standard Certificate includes these steps. The:

• AUSkey system prompts the certificate holder to accept the AUSkey Standard Certificate Conditions of Use.
• Certificate holder accepts those Conditions of Use.
• Certificate holder selects the location to which the AUSkey Standard Certificate is to be downloaded and stored (the ccertificate older’s local hard drive or portable USB device).
• System prompts the Certificate holder to create and confirm a password to protect their certificate (and criterion are displayed explaining how to construct a “strong” password).
• Certificate holder enters and confirms the password.

AUSkey Standard Certificate is generated and downloaded to the selected store file.

AUSkey system generates and stores a confirmation message that the AUSkey Standard Certificate has been activated successfully.

Note: if a password already exists due to prior issuance of an AUSkey Certificate to the Certificate Holder’s selected location, then the correct password must be entered.

4.3 Certificate acceptance

The AUSkey Standard Certificate Conditions of Use set out responsibilities of the Certificate Holder of an AUSkey Standard Certificate (and of the business rntity for which that certificate is held) in relation to that Certificate. Responsibilities of the Certificate Holder are also set out in this CP. That Certificate holder’s acceptance of those Conditions of Use constitutes acceptance of that certificate. The use of that certificate constitutes acceptance of both:

• that AUSkey Standard Certificate
• the GKP003 Standard Certificate Policy, the GKP002 Certification Practice Statement, and the AUSkey Standard Certificate Conditions of Use (in each case, as current as at the time of use).

4.4 Key pair and certificate usage

AUSkey Standard Certificates operate with a single key pair and have their key Usage extension set to include these values:

• Digital Signature
• Non-Repudiation
• Key Encipherment
• Data Encipherment.

This means that, for the purposes of both X.509 and this CP, an AUSkey Standard Certificate may be used for (and its one Key Pair can be used for) both signing and encryption (confidentiality) purposes. However, encryption use should only be for traffic in transit. AUSkey Standard Certificates are not designed to encrypt data long term, for example in a database.

4.4.1 Certificate holder responsibilities

The Certificate holder of an AUSkey Standard Certificate is responsible for:

• downloading the certificate when it is issued, following registration
• creating the password that protects the certificate and its associated Keys, and changing that password at recommended intervals
• safely installing the certificate onto a local keystore such as a hard drive or USB memory device
• safeguarding the certificate throughout its lifetime
• requesting revocation of the certificate, when required.

Other responsibilities and obligations of the Certificate holder are also set out in this CP, the AUSkey Standard Certificate Conditions of Use and the CPS (e.g. CPS sections 4.1.2, 4.4, 5.7.3 and 6.1.1).

4.4.2 Administrator privileges

An AUSkey Standard Certificate is held by an individual – the Certificate holder – for the business entity identified in that certificate (by way of its ABN). Where that certificate has administrator level privileges, the Certificate holder can perform the following administrative functions associated with that business entity’s correct and effective utilisation of the AUSkey system:

• View a list of all AUSkeys issued for that the business entity, including the relevant Certificate Holder’s username, status (active, inactive, pending) and type (user, administrator or Device custodian).
• View a list of all pending AUSkey applications made for that business entity (including the proposed Certificate holder’s username and type) and delete and cancel pending applications from that list.
• View and edit contact information (including email address and name) for all existing and proposed Certificate holders of AUSkeys issued for, and pending AUSkey applications made for, that business entity.
• Request new AUSkey Standard Certificates (with user or administrator level privileges), and new AUSkey Device Certificates, for that business entity.
• Request the revocation of any AUSkey held for that eusiness entity.
• Reassign an AUSkey Device Certificate held for that business entity from one Device Custodian to another.
• Vary the privilege level associated with an AUSkey Standard Certificate held for that business entity from user level to administrator level, or from administrator level to user level.

4.4.3 Relying party responsibilities

See CPS sections 1.3.10 and 6.1.4.

4.5 Certificate renewal

Not supported.

4.6 Certificate re-key

Not supported.

4.7 Certificate modification

Certificate modification is not supported for Auskey User Certificates. See CPS section 4.7.

4.8 Certificate revocation and suspension

4.8.1 Circumstances for revocation

See CPS sections 4.8.1, 4.10 and 5.7.1.

4.8.2 Who may request revocation

Revocation of an AUSkey Standard Certificate – held by the Certificate Holder for a Business Entity – may be requested by:

• that Certificate holder
• an administrator for, or a business associate of, that business entity
• the ABR RA
• the ABR Registrar.

Organisations cannot initiate revocation action when acting as relying parties.

4.8.3 Procedure for revocation request

The revocation of an AUSkey Standard Certificate may be requested by the Certificate holder, an administrator for or a business associate of, the business entity identified in that certificate, as follows:

• The Certificate holder authenticates to the AUSkey Manager using, and requests the revocation of, their own AUSkey Standard Certificate.
• That administrator authenticates to the AUSkey Manager using their own AUSkey and requests the revocation of that AUSkey Standard Certificate.
• The Certificate holder telephones an AUSkey Operator, provides sufficient identity details to allow the AUSkey operator, in accordance with existing ABR processes, to validate their identity and their status as the Certificate holder, and requests the revocation of their AUSkey Standard Certificate.
• That administrator or business associate telephones an AUSkey operator, provides sufficient identity details to allow the AUSkey operator, in accordance with existing ABR processes, to validate their identity and their status as an administrator for or a business associate of that business entity, and requests the revocation of that AUSkey Standard Certificate.

The CA must advise the Trust broker of the revocation in accordance with the requirements of the CPS, and notify the relevant Certificate Holder (or in default, an administrator for or business associate of the relevant business entity) that the AUSkey Standard Certificate is revoked. The notice need not include the reason for revocation.

The CA must also archive the revoked AUSkey Standard Certificate and the certificate revocation request for a period of seven years after the Certificate would have otherwise expired.

Note: this is to provide proof of who requested the digital certificate or its revocation, which may be necessary as part of a forensic investigation if the existence of the Certificate itself is ever questioned.

Access to revocation information will be through a standards compliant and approved X.509 protocol such as LDAP.

4.8.4 Suspension of AUSkey standard certificates

Suspension is not supported for AUSkey Standard Certificates under this CP. See CPS section 4.8.4.

4.9 Certificate status services

See CPS section 4.9.

4.10 End of subscription

See CPS section 4.10.

4.11 Key escrow and recovery

See CPS section 4.11.

5 Facility, management and operational controls

See section 5 of the CPS for a description of the AUSkey System’s facility, management and operational controls, including:

• CPS section 5.1 – Physical security controls
• CPS section 5.2 – Procedural controls
• CPS section 5.3 – Personnel controls
• CPS section 5.4 – Audit logging procedures
• CPS section 5.5 – Records archival
• CPS section 5.6 – Key changeover
• CPS section 5.7 – Compromise and disaster recovery
• CPS section 5.8 – ABR RA or ABR CA termination.

Note: the most detailed information on these matters is contained in GKP001 Security Profile (SEC 1), which contains sensitive security information and is not publicly available.

6 Technical security controls

See section 6 of the CPS for a description of the AUSkey System’s technical security controls, including:

• CPS section 6.1 – Key Pair Generation and Installation
• CPS section 6.2 – Private Key Protection
• CPS section 6.3 – Other Aspects of Key Pair Management
• CPS section 6.4 – Activation Data
• CPS section 6.5 – Computer Security Controls
• CPS section 6.6 – Life Cycle Technical Controls
• CPS section 6.7 – Network security controls
• CPS section 6.8 – Time-stamping.

Note: the most detailed information on these matters is contained in GKP001 Security Profile (SEC 1), which contains sensitive security information and is not publicly available.

7 Certificate, CRL and OCSP profiles

7.1 User certificate profile

Certificate Fields
Attribute	Value
version	“3” to indicate X.509 version 2 certificates.
serialNumber	Unique identifier for each certificate, composed of incremental positive integers.
signature	Algorithm identifier for the algorithm used by the CA to sign the certificate: SHA-1 with RSA encryption.
issuer	Distinguished Name of the issuing CA: Common Name = Australian Business Register CA OU = Certification Authority Organisation = Australian Business Register Country = AU.
validity	2 years maximum (expressed as “From” and “To” dates)
subject	Distinguished Name of the certificate subject, in this case the User associated with the private key. Common Name = <User given names><Space><User family name> dnQualifier=<Person identifier value> Organisation = Business entity ABN value Country = AU
subjectPublicKeyInfo	The public key and the public key algorithm (SHA256).
Certificate Extensions
Attribute	Value
Key size	1024
keyUsage	Defines valid purposes, such as encipherment or signature, for the key contained in the certificate. Settings will include Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment. The values keyCertSign or crlSign are not allowed in User Certificates. See section 4.4 above for more information on valid usage of the single key pair.
certificatePolicies	CP information such as the OID and the URL where the CPS is available: Policy Identifier OID = 1.2.36.1.3001.1.1.7.1 Certificate Practice Statement available on this AUSkey Terms and Conditions page. User Notice = This certificate may only be used for the purpose permitted in the applicable Certificate Policy. Limited liability applies – refer to the Certificate Policy.
basicConstraints	Indicates if the subject may act as a CA and should be set to “False”.
ABN (custom extension)	Uses the Gatekeeper II OID to identify the ABN: 1.2.36.1.333.1 The ABN value is encoded as an IA5String.

7.2 CRL profile

CRL Attributes
Attribute	Value
CRL issue period	90 minutes
CRL validity	7 hours
CRL signature digest	SHA-256
revokedCertificates	List of revoked certificates by serial number.
reasonCode	Not used.
invalidityDate	Date at which it is known or suspected that the private key was compromised or that the certificate should otherwise be considered invalid.

7.3 OCSP profile

No stipulation.

8 Compliance audits and other assessments

See section 8 of the CPS for a description of the AUSkey System’s compliance audits and other assessments, including:

• CPS section 8.1 – Frequency or Circumstances of Assessment
• CPS section 8.2 – Identity/Qualifications of Assessor
• CPS section 8.3 – Assessor's Relationship to Assessed Entity
• CPS section 8.4 – Topics Covered by Assessment
• CPS section 8.5 – Actions Taken as a Result of Deficiency
• CPS section 8.6 – Communication of Results.

9 Other business and legal matters

Note: an order of precedence applies to the documents forming the applicable contract – see CPS section 1.1.4.

9.1 Privacy of personal information

See CPS section 9.1.

9.2 Representations and warranties

See CPS section 9.2.

9.3 Disclaimers of all other warranties

See CPS section 9.3.

9.4 Limitation of liability

See CPS section 9.4.

9.5 Indemnities

See CPS section 9.5.

9.6 Notices

See CPS section 9.6.

9.7 Amendments

See CPS section 9.7.

9.8 Dispute resolution procedures

See CPS section 9.8.

9.9 Governing law

See CPS section 9.9.

Version 1.3 – Updated 30 March 2020

Certificate policy - Device AUSkey

Version 1.3 - updated 30 March 2020

1 Overview

1.1 Overview

The ABR Registrar has established the AUSkey System as Public Key Infrastructure to facilitate internet-based electronic transactions between business entities and Agencies, and manages the AUSkey System’s operational Certification Authority (the ABR CA).

This document is the GKP003 Device Certificate Policy. This Certificate Policy (CP) sets out the rules applying to, and provides policy and operational guidance on the deployment of, AUSkey Device Certificates issued by the ABR CA.

This CP must be read in conjunction with the following documents, which can be accessed online:

• GKP002 Certification Practice Statement (the CPS)
• AUSkey Device Certificate Conditions of Use
• AUSkey Terms and Conditions – Glossary.

1.1.1 Standard Business Reporting (SBR) program

See CPS section 1.1.1.

1.1.2 The AUSkey system

See CPS section 1.1.2.

1.1.3 Community of Interest (COI)

See CPS section 1.1.3.

Note: the COI for AUSkey Certificates is restricted to government agencies who are part of the SBR Program, and Business Entities who have an Australian Business Number (ABN).

1.1.4 Device certificates

Device certificates are used to identify servers or other computer devices within organisations, rather than individuals within organisations.

An AUSkey Device certificate both:

• identifies a business entity (by its ABN), and a particular device (computer hardware, such as a server) that is owned, controlled or operated by that usiness entity
• facilitates machine-to-machine interactions between that business entity and SBR Agencies.

1.1.5 This Certificate Policy and the Certification Practice Statement

See CPS section 1.1.4.

Note: a document hierarchy applies: the provisions of the Conditions of Use or other relevant contract override the provisions of this CP, and the provisions of this CP override the CPS.

1.2 Document name and identification

This document is known as the GKP003 Device Certificate Policy. It is identified by the object identifier (OID): 1.2.36.1.3001.1.1.8.1, based on the following structure:

1	ISO code
2	Member Body
36	Australia
1	Government
3001	Australian Business Register (ABR)
1	Australian Business Register Root CA (RCA)
1	Australian Business Register Operational CA (OCA)
8	Device Certificate Policy
1	Version number

1.2.1 Attribution

See CPS section 1.2.1.

1.3 AUSkey participants

1.3.1 ABR Root Certification Authority (ABR RCA)

See CPS section 1.3.1

1.3.2 ABR Certification Authority (ABR CA)

See CPS section 1.3.2.

1.3.3 ABR Registration Authority (ABR RA)

See CPS section 1.3.3.

1.3.4 Business entities

See CPS section 1.3.4.

1.3.5 Business associates

See CPS section 1.3.5.

1.3.6 Users

See CPS section 1.3.6.

1.3.7 Administrators

See CPS section 1.3.7.

1.3.8 Device Custodians

See CPS section 1.3.8.

Note: a Device Custodian is the individual responsible for safeguarding and managing the use of an AUSkey Device Certificate on behalf of the business entity identified in that certificate. The Device Custodian is linked to that certificate linked through processes external to the certificate (that is, the Device Custodian is not identified in the Certificate itself).

1.3.9 Devices

See CPS section 1.3.9.

Note: a device is computer hardware (such as a server) onto which a Device certificate may be installed. For an AUSkey Device certificate, the device on which it is installed must be owned, controlled and/or operated by the business entity identified in that certificate.

1.3.10 Relying parties

See CPS section 1.3.10.

1.3.11 Trust broker

See CPS section 1.3.11.

1.4 Certificate usage

1.4.1 Appropriate certificate use

The appropriate use of an AUSkey Device Certificate is limited to authenticating the Device identified in that certificate as owned, controlled or operated by the business entity identified in that certificate for the purposes of a machine-to-machine interaction between that business entity and an SBR Agency within the AUSkey COI.

A typical transaction for an AUSkey Device Certificate would be a business entity’s system submitting a form (that does not need to be lodged or signed by an individual) directly to an SBR Agency’s system through the SBR channel.

Note: the SBR channel refers to the lodgment of forms using SBR-enabled business software.

1.4.2 Limits on use

An AUSkey Device Certificate is designed for the business entity identified by its ABN in that certificate to authenticate itself, and that it owns, controls or operates the device identified in that Certificate, for the purposes of carrying out a machine-to-machine interaction with an SBR Agency within the AUSkey COI. The AUSkey System does not support use of AUSkeys by or with any other relying parties. Any person who uses, or relies on, an AUSkey Device Certificate in any other circumstances does so at their own risk and responsibility.

Note: the use of an AUSkey Device Certificate for a given transaction with a participating SBR Agency depends not only on the nature of the transaction (whether it can be carried out machine-to-machine, or needs to be signed or submitted by an individual), but also on the Agency’s system (whether it is designed to accept that transaction machine-to-machine). For transactions submitted and accepted using a web browser, an AUSkey Standard Certificate should be used. AUSkey Device Certificates are not suitable for transactions that require a web-based logon.

Find out more

For other limits on use, refer to the:

• Certification Practice Statement
• Conditions of Use.

1.4.3 Prohibited certificate uses

Any kind of unlawful or improper purpose of an AUSkey Device Certificate is prohibited.

1.5 Policy administration

See CPS section 1.5.

1.6 Definitions and acronyms

See CPS section 1.6.

2 Publications and repositor responsibilities

2.1 Repositories and publication information

The AUSkey System operates several repositories supporting its operations.

2.1.1 Publications

See CPS section 2.1.1.

2.1.2 The Certificate revocation list (CRL)

See CPS section 2.1.2.

2.1.3 Internal data repositories

See CPS section 2.1.3.

3 Identification and authentication

3.1 Naming

Every Certificate issued under this CP must have a Distinguished Name (DN) that is unique to the device the subject of the certificate and compliant with the X.509 standard. The DN must be in the form of a X.509 printable string and may not be blank.

That DN will be present in the certificate’s subject name field, as set out in the certificate profile outlined in section 7 of this CP.

The common name of the device is a component of that DN, and is supplied in the application for the AUSkey Device Certificate. The name supplied must be meaningful, unambiguous and (in the business entity concerned) unique to the device, and should be either a domain name or an IP address as these will provide unique and distinguishable Device names that are both intuitive and allow for a logical and documented device naming scheme within the business entity.

The AUSkey System does not allow anonymity or pseudonymity for any AUSkey Certificate subject names, including Device names.

Any disputes in relation to names in AUSkey Device Certificates will be resolved by the AUSkey Policy Management Authority (AUSkey PMA).

Note: although device names must be unique, it is possible that a single device may be issued multiple certificates. This is to allow for cluster implementations so that a certificate may be installed on each individual server within a cluster. For example, a business entity may have several servers in an array for failover and load balancing. An AUSkey Device Certificate must be installed on each of those servers. It is optional how a business entity would name their Device Certificates in such a configuration. If it elects to have:

• one name that is common across all the servers, then it only needs to enroll the AUSkey at an SBR Agency once (as whenever the agency gets a transaction with that same name, they will assign the same permissions, irrespective of which server it came from).
• a different name for each server (e.g. server1.acme.com, server2.acme.com) then it will have to enrol each of those names at each SBR Agency separately.

3.2 Initial identity validation

See section 3.1.2 of the CPS.

Note: for identify validation, the AUSkey System allows identity details to be entered online, which are then validated to a previous documentary based Evidence of Identity (EOI) processes. In some cases documentary EOI is required, such as where the identity details supplied are insufficient or incorrect.

An application for an AUSkey Device Certificate must be made online through the AUSkey Manager by an administrator for the business entity concerned, and that administrator must nominate a Device Custodian to be associated with that Certificate. That administrator may nominate him or herself as that Device Custodian.

3.2.1 Initial Administrator identity validation

When applying for an AUSkey Device Certificate, the administrator initially identifies and authenticates themself to the AUSkey Manager using their AUSkey Standard Certificate (a website logon, including a valid password).

For the identity validation details required in order to obtain administrator level privileges in relation to an AUSkey Standard Certificate, see GKP003 Standard Certificate Policy section 3.2.1.

Note: For applications for Standard AUSkeys with Administrator level privileges, existing ABR processes are applied to verify the identity of the proposed AUSkey holder:

• To validate to a previous documentary evidence based EOI process – see proving your identity or Contact us.
• For documents to initially establish identity – see proving your identity

3.2.2 Initial Device Custodian identity validation

In an application for an AUSkey Device Certificate (to be held for a business entity), the nominated Device Custodian is selected from a list of individuals who hold a valid AUSkey Standard Certificate for that same business entity, and is initially identified and authenticated by reference to their certificate.

For the identity validation details required in order to obtain an AUSkey Standard Certificate, see GKP003 Standard Certificate Policy sections 3.2.1 and 3.2.3.

Note: Applications for Standard AUSkeys with user level privileges must be made or approved by an administrator whose identity has been verified (in accordance with existing ABR processes on identity verification) and who verifies the identity of the proposed AUSkey holder.

3.3 Identification and authentication for renewal requests

Not supported.

3.4 Identification and authentication for revocation request

If the revocation of an AUSkey Device Certificate (held for a business entity) is requested through the AUSkey Manager by the Device Custodian associated with that certificate, or by an administrator for that business entity, they identify and authenticate themselves to the AUSkey Manager using their AUSkey Standard Certificate (a website logon, including a valid password).

If a telephone request is made to an AUSkey operator for the revocation of an AUSkey Device Certificate (held for a business entity), the caller must provide sufficient identity details to allow the AUSkey operator, in accordance with existing ABR processes, to validate the caller’s identity, and verify their status as the Device Custodian associated with that AUSkey Device Certificate, or an administrator for a or business associate of that same business entity.

All revocation requests must come through the ABR RA. The ABR CA will only action a revocation request if the ABR CA successfully validates the request by verifying the ABR RA’s signing certificate.

4 Certificate life-cycle operational requirements

This section deals only with the life-cycle operational requirements for AUSkey Device Certificates. For life-cycle event details for AUSkey Standard Certificates, see the applicable CP. Details of certain infrastructure certificates not used by any end entities may be found in the CPS. The certificate life-cycle events are described at a high-level, from the perspective of human end users.

Note: all certificate life-cycle event requests must come through a valid ABR RA communication, using standards based formats such as Public Key Cryptography Standards (PKCS) payloads. At a technical level, a request will only succeed if the ABR CA is able to successfully validate the request by verifying the ABR RA’s signing certificate.

4.1 Certificate application

4.1.1 Who can submit an application for a Device Certificate

An application for an AUSkey Device Certificate (to be held for a Business Entity):

• can only be made by an administrator for that same business entity
• can only be made online through the AUSkey Manager, and
• must nominate an individual who holds a valid AUSkey Standard Certificate (for that same business entity) as the Device Custodian to be associated with that Device Certificate.

The administrator may nominate – as the Device Custodian – either themselves or another individual who holds a valid AUSkey Standard Certificate for the business entity concerned. The individual nominated may already be associated with another Device Certificate as its Device Custodian.

4.1.2 Certificate application process

The process for an administrator for a business entity applying for an AUSkey Device Certificate to be held for that same business entity is generally as follows:

The administrator authenticates to the AUSkey Manager using their AUSkey Standard Certificate.

The administrator selects the new device option and follows the system prompts to:

• enter the requested details of the device, including a DN identifying it (e.g. server name or IP address)
• select a Device Custodian for the Device Certificate from a list of individuals holding valid AUSkey Standard Certificates for that business entity.

The administrator submits the application, and the AUSkey System generates and displays an application reference number and advises the Administrator that a notification email will be sent to the nominated Device Custodian.

The AUSkey System sends the nominated Device Custodian a notification email informing them of the application and their nomination as the Device Custodian for the named device.

The AUSkey system records the registration details of the Device Custodian, associating them with that AUSkey Device Certificate.

The nominated Device Custodian clicks on a link in the notification email, and enters and submits the displayed Captcha code to initiate certificate activation and begin the issuance process.

4.2 Certificate issuance

The typical issuance of an AUSkey Device Certificate includes these steps:

The AUSkey System prompts the Device Custodian to accept the AUSkey Device Certificate Conditions of Use.

The Device Custodian accepts those Conditions of Use.

The Device Custodian selects the location to which the AUSkey Device Certificate is to be downloaded and stored (a default key store, other existing key store, or new location).

Note: the selected store file may be temporary pending the Device Custodian transferring the Certificate to e.g. the server location – see section 4.4.1 below.

The system prompts the Device Custodian to create and confirm a password to protect their Certificate, and the Device Custodian enters and confirms the password.

Note: if a password already exists due to prior issuance of an AUSkey Certificate to the Device Custodian’s selected location, then the correct password must be entered.

The AUSkey Device Certificate is generated and downloaded to the selected store file.

The AUSkey System generates and stores a confirmation message that the AUSkey Device Certificate has been activated successfully.

4.3 Certificate acceptance

The AUSkey Device Certificate Conditions of Use set out responsibilities of the Device Custodian of an AUSkey Device Certificate (and of the business entity for which that Certificate is held) in relation to that certificate. Responsibilities of the Device Custodian are also set out in this CP. That Device Custodian’s acceptance of those Conditions of Use constitutes acceptance of that Certificate. The use of that certificate constitutes acceptance of:

• that AUSkey Device Certificate
• the GKP003 Device Certificate Policy, the GKP002 Certification Practice Statement, and the AUSkey Device Certificate Conditions of Use (in each case, as current as at the time of use).

4.4 Key Pair and certificate usage

AUSkey Device Certificates operate with a single Key Pair and have their key usage extension set to include these values:

• Digital Signature
• Non-Repudiation
• Key Encipherment
• Data Encipherment.

This means that, for the purposes of both X.509 and this CP, an AUSkey Device Certificate may be used for (and its one Key Pair can be used for) both signing and encryption (confidentiality) purposes. However, encryption use should only be for traffic in transit. AUSkey Device Certificates are not designed to encrypt data long term, for example in a database.

Note: SBR Agencies may only accept Device Certificates for limited transactions and only then if their systems are designed to accept those transactions machine-to-machine.

4.4.1 Device Custodian responsibilities

The Device Custodian for an AUSkey Device Certificate is responsible for:

• downloading the Device Certificate when it is issued, following registration
• creating the password that protects the Device Certificate and its associated Keys, and changing that password at recommended intervals
• ensuring the Device Certificate is attached to the correct device, for example by ensuring a match between the IP address of the device and the subject of the certificate
• safely transferring the Device Certificate from the download location to the server location, if required for example because:
  • email access is not available on that server, so that the download link that is used to install the Device Certificate cannot be accessed from that location
  • the business entity has an IT Outsourcing, SaaS or similar arrangement with another entity, and needs to transfer its Device Certificate to that other entity’s hosting location
• managing the use of, and safeguarding, the Device Certificate
• requesting revocation of the Device Certificate, when required.

Other responsibilities and obligations of the Device Custodian are also set out in this CP, the AUSkey Device Certificate Conditions of Use and the CPS (e.g. CPS sections 4.1.2, 4.4, 5.7.3 and 6.1.1).

Note: a Business Entity remains responsible for any transactions performed on its behalf using its Device Certificate, and for ensuring its Device Certificate is managed in a secure manner. Before a business entity enters onto an IT Outsourcing, SaaS or similar arrangement – particularly where its Device Certificate is hosted by the 3rd party provider or the Device Custodian is not its direct employee – it should obtain its own legal advice on managing those responsibilities under that arrangement.

4.4.2 Relying party responsibilities

See CPS sections 1.3.10 and 6.1.4.

4.5 Certificate renewal

Not Supported.

4.6 Certificate re-key

Not supported.

4.7 Certificate modification

Certificate modification is not supported for AUSkey Device Certificates. See CPS section 4.7.

4.8 Certificate revocation and suspension

4.8.1 Circumstances for revocation

See CPS sections 4.8.1, 4.10 and 5.7.1.

Note: an administrator can re-assign a Device Certificate from one custodian to another (see GKP003 Standard Certificate Policy section 4.4.2). If a custodian’s Standard Certificate is revoked, the Device Certificate needs to be re-assigned within 30 days otherwise it will be automatically revoked.

4.8.2 Who may request revocation

Revocation of an AUSkey Device Certificate – held for a Business Entity – may be requested by:

• the Device Custodian associated with that certificate
• an administrator for or a business associate of that business entity
• the ABR RA
• the ABR Registrar.

Organisations cannot initiate revocation action when acting as relying parties.

4.8.3 Procedure for revocation request

The revocation of an AUSkey Device Certificate may be requested by the Device Custodian associated with that certificate, an administrator for or a business associate of, the business entity identified in that certificate, as follows:

• The Device Custodian authenticates to the AUSkey Manager using their own AUSkey Standard Certificate and requests the revocation of that AUSkey Device Certificate.
• That administrator authenticates to the AUSkey Manager using their own AUSkey and requests the revocation of that AUSkey Device Certificate.
• The Device Custodian telephones an AUSkey Operator, provides sufficient identity details to allow the AUSkey operator, in accordance with existing ABR processes, to validate their identity and their status as the Device Custodian, and requests the revocation of that AUSkey Device Certificate.
• That administrator or business associate telephones an AUSkey operator, provides sufficient identity details to allow the AUSkey Operator, in accordance with existing ABR processes, to validate their identity and their status as an administrator for or a business associate of that business entity, and requests the revocation of that AUSkey Device Certificate.

The CA must advise the Trust broker of the revocation in accordance with the requirements of the CPS, and notify the relevant Device Custodian (or in default, an administrator for or business associate of the relevant business entity) that the Device Certificate is revoked. The notice need not include the reason for revocation.

The CA must also archive the revoked Device Certificate and the certificate revocation request for a period of seven years after the Certificate would have otherwise expired.

Note: this is to provide proof of who requested the digital certificate or its revocation, which may be necessary as part of a forensic investigation if the existence of the Certificate itself is ever questioned.

Access to revocation information will be through a standards compliant and approved X.509 protocol such as LDAP.

4.8.4 Suspension of Device Certificates

Suspension is not supported for Device Certificates under this CP.

4.9 Certificate status services

See CPS section 4.9.

4.10 End of subscription

See CPS section 4.10.

4.11 Key escrow and recovery

See CPS section 4.11.

5 Facility, management and operational controls

See section 5 of the CPS for a description of the AUSkey System’s facility, management and operational controls, including:

• CPS section 5.1 – Physical Security Controls
• CPS section 5.2 – Procedural Controls
• CPS section 5.3 – Personnel Controls
• CPS section 5.4 – Audit logging procedures
• CPS section 5.5 – Records Archival
• CPS section 5.6 – Key Changeover
• CPS section 5.7 – Compromise and disaster recovery
• CPS section 5.8 – ABR CA or ABR RCA termination.

Note: the most detailed information on these matters is contained in GKP001 Security Profile (SEC 1), which contains sensitive security information and is not publicly available.

6 Technical security controls

See section 6 of the CPS for a description of the AUSkey System’s technical security controls, including:

• CPS section 6.1 – Key Pair Generation and Installation
• CPS section 6.2 – Private Key Protection
• CPS section 6.3 – Other Aspects of Key Pair Management
• CPS section 6.4 – Activation Data
• CPS section 6.5 – Computer Security Controls
• CPS section 6.6 – Life Cycle Technical Controls
• CPS section 6.7 – Network security controls
• CPS section 6.8 – Time-stamping.

Note: the most detailed information on these matters is contained in GKP001 Security Profile (SEC 1), which contains sensitive security information and is not publicly available.

7 Certificate, CRL and OCSP profiles

7.1 Device Certificate profile

Certificate Fields
Attribute	Value
version	“3” to indicate X.509 version 2 certificates.
serialNumber	Unique identifier for each certificate, composed of incremental positive integers.
signature	Algorithm identifier for the algorithm used by the CA to sign the certificate: SHA-1 with RSA encryption.
issuer	Distinguished Name of the issuing CA: Common Name = Australian Business Register CA OU = Certification Authority Organisation = Australian Business Register Country = AU.
validity	two years maximum (expressed as “From” and “To” dates)
subject	Distinguished name of the certificate subject, in this case the device associated with the private key. Common name = assigned by business, recommend businesses use relevant domain name or IP address Organisation = Business entity ABN value Country = AU
subjectPublicKeyInfo	The public key and the public key algorithm (SHA 256).

 

Certificate extensions
Attribute	Value
Key size	1024
keyUsage	Defines valid purposes, such as encipherment or signature, for the key contained in the certificate. Settings will include Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment. The values keyCertSign or crlSign are not allowed in Device Certificates. See section 4.4 above for more information on valid usage of the single key pair.
certificatePolicies	CP information such as the OID and the URL where the CPS is available: Policy Identifier OID = 1.2.36.1.3001.1.1.8.1 Certificate Practice Statement available on this AUSkey Terms and Conditions page. User Notice = This certificate may only be used for the purpose permitted in the applicable Certificate Policy. Limited liability applies - refer to the Certificate Policy.
basicConstraints	Indicates if the subject may act as a CA and should be set to “False”.
ABN (custom extension)	Uses the Gatekeeper II OID to identify the ABN: 1.2.36.1.333.1 The ABN value is encoded as an IA5String.

7.2 CRL profile

CRL Attributes
Attribute	Value
CRL issue period	90 minutes
CRL validity	Seven hours
CRL signature digest	SHA-256
revokedCertificates	List of revoked certificates by serial number.
reasonCode	Not used.
invalidityDate	Date at which it is known or suspected that the private key was compromised or that the certificate should otherwise be considered invalid.

7.3 OCSP Profile

No stipulation.

8 Compliance audits and other assessments

See section 8 of the CPS for a description of the AUSkey System’s compliance audits and other assessments, including:

• CPS section 8.1 – Frequency or Circumstances of Assessment
• CPS section 8.2 – Identity/Qualifications of Assessor
• CPS section 8.3 – Assessor's Relationship to Assessed Entity
• CPS section 8.4 – Topics Covered by Assessment
• CPS section 8.5 – Actions Taken as a Result of Deficiency
• CPS section 8.6 – Communication of Results.

9 Other business and legal matters

Note: an order of precedence applies to the documents forming the Applicable Contract – see CPS section 1.1.4.

9.1 Privacy of personal information

See CPS section 9.1.

9.2 Representations and warranties

See CPS section 9.2.

9.3 Disclaimers of all other warranties

See CPS section 9.3.

9.4 Limitations of liability

See CPS section 9.4.

9.5 Indemnities

See CPS section 9.5.

9.6 Notices

See CPS section 9.6.

9.7 Amendments

See CPS section 9.7.

9.8 Dispute resolution procedures

See CPS section 9.8.

9.9 Governing law

See CPS section 9.9.

Version 1.3 – updated 30 March 2020

Conditions of use - AUSkey

These Conditions of Use are to be read in conjunction with the following documents:

• The GKP002 Certification Practice Statement (the CPS).
• The GKP003 Standard Certificate Policy (the CP).
• The AUSkey Terms and Conditions - Glossary (unless specially defined in these Conditions of Use, capitalised terms are defined in this glossary).

1 Background

1.1 The Registrar of the Australian Business Register (ABR):

• has established the AUSkey System to facilitate internet-based electronic transactions between business entities and participating agencies
• is the Certification Authority (CA) for the AUSkey System.

1.2 The business wishes to use (and have the Certificate Holder use on its behalf) the AUSkey Standard Certificate issued under the CP.

• The business means the entity identified by its Australian Business Number (ABN) in the application for that AUSkey Standard Certificate and as the Organisation in that Certificate.
• The Certificate holder means the individual nominated in the application for that AUSkey Standard Certificate to hold it for the business and identified in that certificate.

2 Conditions associated with the AUSkey Standard Certificate

2.1 The CP, the CPS and the AUSkey Standard Certificate Conditions of use may change over time. Those current at a given time are those then published on this AUSkey Terms and Conditions page.

2.2 By accepting, and by using, the AUSkey Standard Certificate, the Certificate Holder and the business agree in each case to be bound by the CP, the CPS and the AUSkey Standard Certificate Conditions of Use current as at that time.

3 Use of the AUSkey Standard Certificate

3.1 The Certificate holder and the business are jointly and severally responsible for the storage and use of the AUSkey Standard Certificate, including all transactions and communications carried out under or using it.

3.2 The Certificate holder must not use the AUSkey Standard Certificate for any unlawful or improper purpose.

3.3 The business warrants that the Certificate holder has full authority to use the AUSkey Standard Certificate on the business' behalf.

3.4 The business and the Certificate Holder permit the ABR CA to (and to authorise others to) publish information relating to the AUSkey Standard Certificate, the business and the Certificate holder for the purposes of the AUSkey System and as indicated in the CP and CPS.

3.5 All intellectual property rights in the AUSkey Standard Certificate are owned by (the ABR CA as custodian for) the Commonwealth of Australia. The Certificate holder and the business may only reproduce, publish and transmit the AUSkey Standard Certificate (in unaltered form) for the purposes of its use in accordance with the CPS, the CP and these Conditions of use.

4 Responsibilities in relation to the AUSkey Standard Certificate

4.1 The Certificate holder and the business must not:

• disclose the password for the AUSkey Standard Certificate to any other person
• store the AUSkey Standard Certificate in a keystore to which any other person has access
• otherwise allow, grant, permit or enable any person other than the Certificate holder to use the AUSkey Standard Certificate.

4.2 The Certificate holder and the business must promptly advise the ABR CA if:

• the Certificate holder is no longer authorised to use the AUSkey Standard Certificate on the business' behalf
• it becomes aware of any unauthorised use of the AUSkey Standard Certificate
• the security of the AUSkey Standard Certificate or its password has been compromised.

5 Cancellation of the AUSkey Standard Certificate

5.1 The circumstances under which the ABR CA may revoke the AUSkey Standard Certificate are described in the CP and the CPS.

5.2 The AUSkey Standard Certificate must not be used for any purpose after it has been cancelled.

6 Warranty and indemnity

6.1 Except as set out in these Conditions of Use, the CP or the CPS, the ABR CA gives no implied or express warranties in relation to the AUSkey Standard Certificate or its use. All statutory warranties are, to the fullest extent permitted by law, expressly excluded.

6.2 The Business indemnifies the ABR CA against any loss arising from any:

• failure by it (or the Certificate holder) to ensure the safety and integrity of the AUSkey Standard Certificate and its password
• use of the AUSkey Standard Certificate otherwise than in accordance with these Conditions of use
• wilful, negligent or unlawful act or omission by it (or the Certificate holder) in relation to the storage or use of the AUSkey Standard Certificate.

6.3 The business' liability under this indemnity is reduced to the extent that any wilful, negligent or unlawful act or omission by the ABR CA has contributed to its loss.

6.4 A reference in this clause to the ABR CA includes a reference to the ABR CA, the ABR Root Certification Authority, the ABR Registration Authority, the ABR Registrar, the Commonwealth, and their respective officers, employees and agents.

7 General

7.1 The CP and the CPS sets out how disputes between the persons referred to in these Conditions of use are to be resolved.

7.2 These Conditions of use are governed by, and are to be construed in accordance with, the laws for the time being in force in the Australian Capital Territory.

 

Conditions of use - Device AUSkey

These Conditions of use are to be read in conjunction with the following documents:

• The GKP002 Certification Practice Statement (the CPS)
• The GKP003 Device Certificate Policy (the CP)
• The AUSkey Terms and Conditions - Glossary (unless specially defined in these Conditions of Use, capitalised terms are defined in this glossary).

1 Background

1.1 The Registrar of the Australian Business Register (ABR):

• has established the AUSkey System to facilitate internet-based electronic transactions between business entities and participating agencies
• is the Certification Authority (CA) for the AUSkey System.

1.2 The Business wishes to use (and have the Device Custodian responsible on its behalf for) the AUSkey Device Certificate issued under the CP.

• The business means the entity identified by its Australian Business Number (ABN) in the application for that AUSkey Device Certificate and as the Organisation in that Certificate.
• The Device Custodian means the individual nominated in the application as the Device Custodian for that AUSkey Device Certificate, and associated with that Certificate as its Device Custodian.

2 Conditions associated with the AUSkey Device Certificate

2.1 The CP, the CPS and the AUSkey Device Certificate Conditions of use may change over time. Those current at a given time are those then published on this AUSkey terms and conditions page.

2.2 By accepting, and by using, the AUSkey Device Certificate, the Device Custodian and the business agree in each case to be bound by the CP, the CPS and the AUSkey Device Certificate Conditions of use current as at that time.

3 Use of the AUSkey Device Certificate

3.1 The Device Custodian and the business are jointly and severally responsible for the storage and use of the AUSkey Device Certificate including all transactions and communications carried out under or using it.

3.2 The business and the Device Custodian must ensure that the AUSkey Device Certificate is not used for any unlawful or improper purpose.

3.3 The business warrants that the Device Custodian has full authority to manage the use of the AUSkey Device Certificate on the business' behalf.

3.4 The business and the Device Custodian permit the ABR CA to (and to authorise others to) publish information relating to the AUSkey Device Certificate, the business and the Device Custodian for the purposes of AUSkey System and as indicated in the CP and CPS.

3.5 All intellectual property rights in the AUSkey Device Certificate are owned by (the ABR CA as custodian for) the Commonwealth of Australia. The Device Custodian and the Business may only reproduce, publish and transmit the AUSkey Device Certificate (in unaltered form) for the purposes of its use in accordance with the CPS, the CP and these Conditions of Use.

4 Responsibilities in relation to the AUSkey Device Certificate

4.1 The Device Custodian and the Business must not:

• disclose the password for the AUSkey Device Certificate to any other person
• store the AUSkey Device Certificate in a keystore to which any person may have unauthorised access
• otherwise allow, grant, permit or enable any person to use the AUSkey Device Certificate other than under their authority.

4.2 The Device Custodian and the Business must promptly advise the ABR CA if:

• the Device Custodian is no longer authorised to manage the use of the AUSkey Device Certificate on the Business' behalf
• it becomes aware of any unauthorised use of the AUSkey Device Certificate
• the security of the AUSkey Device Certificate or its password has been compromised.

5 Cancellation of the AUSkey Device Certificate

5.1 The circumstances under which the ABR CA may revoke the AUSkey Device Certificate are described in the CP and the CPS.

5.2 The AUSkey Device Certificate must not be used for any purpose after it has been cancelled.

6 Warranty and Indemnity

6.1 Except as set out in these Conditions of use, the CP or the CPS, the ABR CA gives no implied or express warranties in relation to the AUSkey Device Certificate or its use. All statutory warranties are to the fullest extent permitted by law expressly excluded.

6.2 The business indemnifies the ABR CA against any loss arising from:

• any failure by it (or the Device Custodian) to ensure the safety and integrity of the AUSkey Device Certificate and its password
• any use of the AUSkey Device Certificate otherwise than in accordance with these Conditions of use
• any wilful, negligent or unlawful act or omission by it (or the Device Custodian) in relation to the use of the AUSkey Device Certificate.

6.3 The Business' liability under this indemnity is reduced to the extent that any wilful, negligent or unlawful act or omission by the ABR CA has contributed to its loss.

6.4 A reference in this clause to the ABR CA includes a reference to the ABR CA, the ABR Root Certification Authority, ABR Registration Authority, the Registrar, the Commonwealth, and their respective officers, employees and agents.

7 General

7.1 The CP and the CPS sets out how disputes between the persons referred to in these Conditions of Use are to be resolved.

7.2 These Conditions of use are governed by, and are to be construed in accordance with, the laws for the time being in force in the Australian Capital Territory.

AUSkey Terms and Conditions glossary

Acronym	Definition
ABN	See 'Australian Business Number'.
ABR	See 'Australian Business Register'.
ABR CA	The Certification Authority (CA) in the AUSkey System. The ABR CA issues and digitally signs AUSkey certificates.
ABR RA	The Registration Authority (RA) in the AUSkey System. The ABR RA digitally signs relevant requests for AUSkey Certificates, and forwards them to the ABR CA.
ABR RCA	The Root Certification Authority (RCA) in the AUSkey System. It: generates its own Authentication Key creates and signs its own Certificate, and the ABR CA’s Certificate, using that Key.
Administrator	The Certificate Holder of an AUSkey Standard Certificate who has administrator level privileges in relation to that certificate (see 'AUSkey Manager').
Agency	An Agency means: a Department of State or of the Parliament of a body established or constituted for a public purpose under the laws of a body established by the Governor General, the Governor, or a Minister of State of an incorporated company, the controlling interest in which is held by, the Commonwealth of Australia, or an Australian State or Territory.
Approved Documents	The documents that describe the operations of an Organisation that have been approved by the Gatekeeper Competent Authority in the course of it granting Gatekeeper Accreditation to that Organisation (and changes to those documents as subsequently approved by the Gatekeeper Competent Authority).
AUSkey	See 'AUSkey Certificate'.
AUSkey Certificate	A Digital Certificate issued by the ABR Certification Authority. Known colloquially as 'AUSkey'.
AUSkey Device Certificate	An AUSkey Certificate that identifies a Device in its Subject Distinguished Name field (that is the certificate is issued in the name of a device).
AUSkey Holder	The Certificate Holder of an AUSkey Certificate. For an AUSkey Standard Certificate, the Certificate Holder is the individual identified in the Subject Distinguished Name field of that Certificate. For an AUSkey Device Certificate, the Certificate Holder is the Device Custodian associated with that Certificate.
AUSkey PMA	See 'AUSkey Policy Management Authority'
AUSkey Policy Management Authority	This is the governing body of the AUSkey system. It sets the strategic direction for the AUSkey system and approves all changes of policy.
AUSkey Standard Certificate	An AUSkey Certificate that identifies an individual in its Subject Distinguished Name field.
AUSkey System	The Public Key Infrastructure for the creation, management and distribution of AUSkey Certificates. This includes the functions and facilities of the ABR CA, the ABR RA, the ABR RCA and the AUSkey Manager.
AUSkey Manager	An online web interface through which AUSkey Certificates and associated Keys are requested and managed. Administrator level privileges allow the Certificate Holder to authorise applications for AUSkey Certificates and to appoint Certificate Holders as Device Custodians (as described in the Certificate Policies for AUSkey Standard Certificates and AUSkey Device Certificates).
Australian Business Number (ABN)	An Australian Business Number issued in accordance with the A New Tax System (Australian Business Number) Act 1999.
Australian Business Register (ABR)	The database register, established under the A New Tax System (Australian Business Number) Act 1999, of information provided by Business Entities for their ABN registration. The ABR is maintained by the ABR Registrar.
Authentication	The process of testing or verifying an assertion (usually as to identity), in order to establish a level of confidence in the assertion's reliability.
Authentication Key	The Private Key in a Key Pair associated with a Digital Certificate when used for the purposes of Digital Signature.
Business Associate	An individual who can exercise the powers of the relevant Business Entity to (and to authorise others to) carry out electronic transactions with Agencies, including providing that Business Entity's information to, and receiving that Business Entity's information from, those Agencies. The Business Associate approves a Certificate for the first AUSkey Holder in the Business. They may have an AUSkey Certificate issued in their own name, which may or may not have administrator privileges attached.
Business Entity	An entity that has, or is entitled to have, an ABN.
CA	See 'Certification Authority'.
Certificate	See 'Digital Certificate'.
Certificate Directory	The published directory which lists Digital Certificates issued by a given Certification Authority that are currently in force.
Certificate Holder	The individual who manages the use of a Digital Certificate on behalf of the Business Entity identified in that certificate.
Certificate Information	Information needed to generate a Digital Certificate as required by its Certificate Profile.
Certificate Policy	A set of rules applying to, and providing policy and operational guidance on the deployment of, a particular type of Digital Certificate issued by a Certification Authority.
Certificate Profile	The specification (in the Certificate Policy for a Digital Certificate) of the fields to be included in that Digital Certificate and the contents of each field.
Certificate Revocation List	The published directory that lists Digital Certificates issued by a given Certification Authority that have been revoked. The CRL may form part of the Certificate Directory or may be published separately.
Certification Authority	An Organisation that issues, and digitally signs, X.509 v3 Digital Certificates (which may or may not include Key Generation) using its Private Key.
Certification Practice Statement	A statement of the practices that a Certification Authority employs in issuing, managing, revoking, and renewing (and that a Registration Authority employs in conducting registration activities for) particular classes of Digital Certificates.
Commonwealth	The Commonwealth of Australia.
Compromise	A violation (or suspected violation) of a system (includes a CA's or Certificate Holder's Private Keys) such that unauthorised disclosure of sensitive information may have occurred.
CP	See 'Certificate Policy'.
CPS	See 'Certification Practice Statement'.
CRL	See 'Certificate Revocation List'.
Custodian	See 'Device Custodian'.
Device	Computer hardware onto which a Device Certificate may be installed.
Device Certificate	A Digital Certificate that identifies a Device in its Subject Distinguished Name field.
Device Custodian	The individual responsible for managing the use of a given AUSkey Device Certificate on behalf of the Business Entity identified in that certificate. To be a Device Custodian the individual must be the Certificate Holder of an AUSkey Standard Certificate.
Digital Certificate	An electronic document, based on public key cryptographic technology, which: identifies a business entity, and either an individual that represents that business entity or a device owned, operated or controlled by the business entity binds that individual or device to a Key Pair by specifying the Public Key of that Key Pair contains the other information required by the relevant Certificate Profile is signed by the relevant Certification Authority.
Digital Signature	In relation to a Digital Certificate with a Key Usage extension including Digital Signature, the use of that Digital Certificate as (or as part of) an electronic signature.
Distinguished Name	A unique identifier having the structure required by the relevant Certificate Profile.
DN	See 'Distinguished Name'.
DSOT	Daily System Operability Tasks
EOI	See 'Evidence of Identity'.
Evidence of Identity	Evidence (for example, in the form of documents) provided to substantiate the identity of the presenting party.
Gatekeeper	The Commonwealth Government strategy to develop Public Key Infrastructure to facilitate Government online service delivery and e-procurement.
Gatekeeper Accreditation / Gatekeeper Accredited	Formal recognition of an Organisation that is granted by the Gatekeeper Competent Authority which signifies that the Organisation is competent to carry out the operations described in the Approved Documents.
Gatekeeper Competent Authority	The entity which approves an Organisation's application for Gatekeeper Accreditation (including the Approved Documents and any changes to them) as meeting the criteria for Gatekeeper Accreditation or Recognition. The Competent Authority for the Gatekeeper PKI is the Digital Transformation Agency (DTA), .
Hardware Security Module	A piece of hardware and associated software/firmware that usually attaches to the inside of a PC or server and provides cryptographic functions, for example, encryption, decryption, key generation, and hashing. The physical device offers some level of physical tamper-resistance and has a user interface and a programmable interface.
HSM	See 'Hardware Security Module'.
HTTP	See 'Hypertext Transfer Protocol'.
Hypertext Transfer Protocol	An application-level protocol for distributed, collaborative, hypermedia information systems. Its use for retrieving inter-linked resources led to the establishment of the World Wide Web.
Issuer	The CA that digitally signs a Digital Certificate (which may or may not include Key generation) using its Private Key.
Key	A string of characters used with a cryptographic algorithm to encrypt and decrypt.
Key Pair	A pair of asymmetric cryptographic Keys (for example, one decrypts messages which have been encrypted using the other) consisting of a Public Key and a Private Key.
Key Usage	The Key Usage extension defines the purpose (for example, encryption, signature etc) of the Key contained in the Digital Certificate.
LDAP	Lightweight Directory of Accessory Protocol
Object Identifier (OID)	A string of decimal numbers that uniquely identifies an object. These objects are typically an object class or an attribute. It serves to name almost every object type in X.509 Certificates, such as components of Distinguished Names and Certificate Policies.
OID	See 'Object Identifier'.
Organisation	Relates to an entity that has authorised one or more of its employees to hold and use Keys and Digital Certificates on its behalf. An Organisation may or may not be a Business Entity.
Personal Information	Information or an opinion (including information or an opinion forming part of a database), whether true or not, and whether recorded in a material form or not, about a natural person whose identity is apparent, or can reasonably be ascertained, from the information or opinion.
PKCS	See 'Public Key Cryptography Standards'.
PKI	See 'Public Key Infrastructure'.
Private Key	The Private Key in an asymmetric Key Pair that must be kept secret.
Public Key	The Key in an asymmetric Key Pair which may be made public.
Public Key Cryptography Standards	A set of standards for managing Digital Certificates, Keys and associated data.
Public Key Infrastructure	The combination of hardware, software, people, policies and procedures needed to create, manage, store and distribute Keys and Digital Certificates based on public Key cryptography.
RA	See 'Registration Authority'.
RAID	Redundant Array of Independent Disks
RCA	See 'Root Certification Authority'.
Registration	The process for collecting and processing applications for Digital Certificates.
Registration Authority	An Organisation that processes requests for the registration and revocation of X.509 v3 Digital Certificates. The Registration Authority digitally signs relevant requests, using its Private Key, and forwards them to the Certification Authority. The Registration Authority may also be responsible for the secure distribution of Digital Certificates to Certificate Holders.
Relying Party	An individual or entity to whom a Digital Certificate is presented and who acts in reliance on the Certificate presented.
Revoke	In relation to a Digital Certificate - to terminate the Certificate prior to the end of its operational period.
rfc3647	Internet Engineering Task Force's Request for Comment 3647 Internet X.509 PKI Certificate Policy and Certification Practices Framework.
Root Certification Authority (RCA)	A Certification Authority that is the top most Certification Authority in a trust hierarchy.
SaaS	See 'Software as a Service'.
SAML	Security Assertion Mark-up Language
SBR	Standard Business Reporting (program)
SBR-enabled business software	A commercial software package that supports the secure lodgment of forms, using AUSkey Certificates, through the Trust Broker.
SCEC	Security Construction Equipment Committee
Self-Signed Certificate	A Digital Certificate where the Subject Distinguished Name identifies the Issuer of that Certificate.
Software as a Service	A software distribution model in which applications are hosted by a vendor or service provider and made available to customers over a network, typically the Internet.
Subject Distinguished Name	A field in a Digital Certificate that uniquely identifies the individual (or, in the case of a Device Certificate, the Device) associated with the Private Key for that certificate.
Trust Broker	An Organisation which provides a service that checks the validity status of a Digital Certificate and retrieves identity information relating to that certificate. For AUSkey, the Trust Broker is the Department of Industry.
USB	Universal Serial Bus
User	The Certificate Holder of an AUSkey Standard Certificate who does not have administrator level privileges in relation to that certificate (see 'AUSkey Manager').
X.509 and X.509 v3	The international standards for the framework for Public Key Certificates. It is part of wider group protocols from the International Telecommunication Union-T X500 Directory Services Standards.