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, revoking and renewing 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 Defence Signals Directorate (DSD) and Department of Finance
  • 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
  • it automatically renews a Certificate approaching its expiry date, tests that it is working and overwrites the old Certificate – see sections 3.1.4 and 4.5
  • 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.
    Attention

    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.

    End of attention

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). (The format for OIDs for the associated Certificate Polices is set out in section ). This CPS can be accessed online on the 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 Australian Government Information Management Office (AGIMO), Department of Finance (© 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.

Attention

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.

End of attention

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.

Attention

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

End of attention

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, and
  • 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 Department of Finance (AGIMO). 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”.
Attention

Note: for Gatekeeper Accreditation purposes, ABR Services is a Relationship Organisation, and AUSkeys are Certificates in the Special Category.

End of attention

The following table identifies the compliance with those Core Obligations.
Certification Authority Core Obligations Compliance

Certificate Generation

When generating a Digital Certificate, the CA must ensure that:

  • the Certificate Information provided to it has been accurately transcribed into the Digital Certificate
  • all other Certificate Information it generates itself is accurate
  • the Digital Certificate operates with functional Key Pairs
  • the Digital Certificate contains all the elements required by the Certificate Profile contained in the CP.

Complies – see section 4.2

Key Generation

Where the CA generates a Key Pair, it must ensure that each Key Pair can work as an operable pair of cryptographic Keys.

Complies – see section 6.1.1

Possession of Private Key

The CA that issues the Digital Certificate to the Key Holder must take all reasonable actions to ensure that the Key Holder (or an appropriately authorised entity) is in control of the Private Key(s) corresponding to the Public Key identified in the Digital Certificate before the Private Key(s) can be used.

Complies – see sections 6.1.1 and 6.1.2 – end entity generates Private Key

Certificate Repository/Directory

The CA must, in accordance with the ITU-T Recommendation X.500 and consistent with RFC3647 generate, maintain and make available a list of issued Digital Certificates in a manner accessible by all potential Relying Parties using standard protocols and technologies to enable them to verify, in a timely manner, the currency of a particular Digital Certificate.

In relation to Relationship Certificates, the CA only needs to make the Repository or Directory available to those members of the defined Community of Interest.

Complies – see sections 1.3.11, 2.1.2 and 4.9

Certificate Revocation

The CA must ensure the prompt:

  • revocation of a Digital Certificate in accordance with the requirements of the CP under which it was issued
  • generate, maintain and make available a list of revoked Digital Certificates in a manner accessible by all potential Relying Parties using standard protocols and technologies to enable them to verify, in a timely manner, the revocation status of a particular Digital Certificate.

In relation to Relationship Certificates, the CA only needs to make the list of revoked Digital Certificates available to those Agencies participating in the defined Community of Interest.

Complies – see section 4.8.3 (revocation) and sections 1.3.11, 2.1.2 and 4.9 (CRL)

CA Termination

In the event that a CA terminates its operations (whether voluntarily or involuntarily) it must:

  • not enter into any new Contracts with Customers, or renew any existing Contracts
  • not enter into any new Subscriber Agreements, or renew any existing Subscriber Agreements that were entered into for Commonwealth Agency purposes
  • make arrangements to novate to a Gatekeeper Accredited CA or terminate all Subscriber Agreements that were entered into for Commonwealth Agency purposes in accordance with the relevant Certificate Policy
  • give notice to all Commonwealth Agencies terminating its Contracts with them, the termination to be effective in accordance with the terms of the relevant Contract
  • continue to provide the Services (in particular the maintenance of a CRL or other listing of revoked Digital Certificates) in accordance with the contractual arrangements it has with Agencies, and any relevant Approved Documents which include arrangements to accommodate significant interruptions in the provision of the Services
  • co-operate with Finance (and Finance must co-operate with the Service Provider), and other Agencies, to achieve a seamless and secure migration of the Agencies and Subscribers to a new Gatekeeper Accredited CA, or RA, as the case may be.

Complies – see section 5.8 and sections 5.8.1 to 5.8.4.

Registration Authority Core Obligations

Compliance

Evidence of Identity (EOI) – General

A Registration Authority must:

  • take all reasonable actions to verify the accuracy and sufficiency of EOI documentation (including any client application forms and supporting documentation) received by it
  • ensure the accurate recording and secure transmission of all relevant Certificate Information to the relevant CA.

Where the 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 its Approved Documents.

Complies – see sections 1.3.3 and 3.1.2.

Certificate Revocation Requests

A RA must, in the event that an error is identified in the EOI process that gives rise to uncertainty as to the authentication of a particular Subscriber, promptly notify the CA that generated the Digital Certificate of the error and request the Revocation of the Digital Certificate.

Complies – see section 3.1.2

Relationship Organisation Core Obligations

Compliance

Compliance with Core Obligations Policy

A Relationship Organisation that is Listed by the Gatekeeper Competent Authority must, as relevant, ensure its compliance with the Core Obligations specified in this document.

Compliance with Core Obligations detailed in this table.

Evidence of Identity

A Relationship Organisation must ensure that in respect of its authorisation for the issuance of a Digital Certificate to an Individual/Organisation, its knowledge of, and history of its dealings with that Individual or Organisation 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 Individual or Organisation.

Complies – see section 3.1.2

Known Customer Organisation Core Obligations

Compliance

Compliance with Core Obligations Policy

A Known Customer Organisation that is Listed by the Gatekeeper Competent Authority must, as relevant, ensure its compliance with the Core Obligations specified in this document.

n/a

Evidence of Identity

A Known Customer Organisation must ensure that in respect of its authorisation for the issuance of a Digital Certificate to an Individual/Organisation, the KCO has, within the preceding five years, performed the EOI check on the individual/organization, as appropriate, which complies with the Gatekeeper EOI Policy, including:

  • a face-to-face presentation at the time of document submission
  • the provision of a current photograph.

The Known Customer Organisation must:

  • be able to provide a reasonable assurance that an entity has transacted business on a regular basis with the Organisation in accordance with regulatory or compliance requirements for a minimum of 12 calendar months immediately before the authorisation for the issuance of a Digital Certificate, and continues to do so
  • take all reasonable action to verify the accuracy and sufficiency of the EOI documentation received by it
  • ensure the accurate recording and secure transmission of all relevant Certificate Information to the relevant CA.

n/a

Storage of Information

Known Customer Organisations must ensure the secure storage of all EOI information (whether in electronic or hardcopy form) in accordance with Gatekeeper policy, in particular, the:

  • requirements of the Commonwealth Protective Security Manual
  • Australian Government Information and Communications Technology Security Manual (ISM).

n/a

Revocation of Certificates

A Known Customer Organisation must, in the event that either the organisation itself or the Subscriber identify an error in their EOI processes that gives rise to uncertainty as to the identity of a particular Subscriber, immediately notify the CA that generated the Digital Certificate of the error and request the Revocation of the Digital Certificate.

n/a

Threat / Risk Organisation Core Obligations

Compliance

Compliance with Core Obligations Policy

A Threat / Risk Organisation that is Listed by the Gatekeeper Competent Authority must, as relevant, ensure its compliance with the Core Obligations specified in this document.

n/a

Evidence of Identity

A Threat / Risk Organisation must ensure that its internal EOI processes that are relied on for requesting or authorising the issuance of a Digital Certificate to an individual/organisation comply with the processes that were documented in the Threat and Risk Assessment as approved by the Gatekeeper Competent Authority.

n/a

Where changes to these internal EOI processes are proposed by the Threat / Risk Organisation, the changes must be approved by the Gatekeeper Competent Authority before being implemented to ensure that their overall integrity is not compromised.

n/a

Storage of Information

Threat / Risk Organisations must ensure the secure storage of all EOI information (whether in electronic or hardcopy form) in accordance with Gatekeeper policy, in particular, the:

  • requirements of the Commonwealth Protective Security Manual
  • Australian Government Information and Communications Technology Security Manual (ISM).

n/a

Revocation of Certificates

A Threat / Risk Organisation must, in the event that either the organisation itself or the Subscriber identify an error in their EOI processes that gives rise to uncertainty as to the identity of a particular Subscriber, immediately notify the CA that generated the Digital Certificate of the error and request the Revocation of the Digital Certificate.

n/a

Subscriber Core Obligations

Compliance

A Subscriber must:

  • ensure that all information provided, and any representations made to a Gatekeeper Accredited RA, a Relationship Organisation, a Known Customer Organisation or a Threat and Risk Organisation are complete and accurate
  • perform any additional requirements as specified in the CP under which the Digital Certificate was issued
  • only use Keys and Digital Certificates within the limits specified in the CP under which the Digital Certificate was issued
  • take all reasonable measures to protect their Private Key(s) from compromise and take all necessary precautions to prevent loss, disclosure, modification, or unauthorised use of their Private Key(s)
  • promptly notify the CA in the event that they consider or suspect there has been a compromise of their Private Keys
  • promptly notify the relevant RA, Relationship Organisation, Known Customer or Threat and Risk Organisation in the event that they consider the Evidence of Identity information provided by them is or may be incorrect.

Complies – see sections 4.1.2, 4.4, 5.7.3 and 6.1.1.

Relying Party Core Obligations

Compliance

A Relying Party must:

  • verify the validity of a Digital Certificate i.e. verify that the Digital Certificate is current and has not been revoked or suspended, in the manner specified in the CP under which the Digital Certificate was issued
  • verify that the Digital Certificate is being used within the limits specified in the CP under which the Digital Certificate was issued
  • promptly notify the Service Provider in the event that it suspects that there has been a compromise of the Subscriber’s Private Keys.

Complies – see sections 1.3.10 and 6.1.4.

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:

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 (Certificate Information, CRLs, etc). The CRL is not directly available to the public or to Relying Parties. The Trust Broker 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 Highly Protected 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.
      Attention

      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.

      End of attention

    • 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 renewal requests
  • 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 Device 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/es) 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/es 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.
Attention

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

End of attention

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.

Attention

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):

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.

End of attention

If an error is identified in the EOI and/or validation information or process/es 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 Operators are vetted at the Highly Protected 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

The AUSkey System always renews end entity AUSkeys by causing the end entity to generate a new Key Pair. The system then issues a new AUSkey Certificate that certifies the new Public Key. When the AUSkey System detects authentication with an end entity’s AUSkey with less than 14 months before expiry, it automatically initiates the renewal process. The end entity’s authentication with their existing AUSkey provides the necessary EOI for renewal.

From an end user perspective, AUSkey Certificates are renewed automatically. More details are contained in sections 4.5 and 4.6 below and in the applicable CP. The AUSkey System will not renew revoked or expired AUSkey Certificates. Instead, the AUSkey Holder must reapply and the system will issue a new Certificate, following the identification and authentication procedures described in the applicable CP.

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 to Highly Protected. 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) Certificate 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.

Attention

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.

End of attention

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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).
  5. The ABR RA signs the AUSkey Certificate request using its own Certificate.
  6. The ABR RA stores the signed request in the local ABR RA database.
  7. The ABR RA sends the request to the ABR CA.
  8. 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:

  1. The AUSkey System prompts the proposed AUSkey Holder to accept the Conditions of Use associated with that AUSkey Certificate.
  2. The proposed AUSkey Holder accepts those Conditions of Use.
  3. The AUSkey is generated and stored, either on a local hard drive or a portable USB device.
  4. The AUSkey Holder creates a password in order to protect their AUSkey.
  5. 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 System 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.

Attention

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.

End of attention

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

AUSkey Certificate Renewal always takes place through generating a new Key Pair and issuing a new Certificate that certifies the new Public Key. The AUSkey System provides a routine for AUSkey Certificates to be renewed automatically as follows:

  1. Whenever an AUSkey is used, the system checks the Certificate’s expiration date.
  2. If the system determines that the expiration date is near (within 14 months), it issues a new AUSkey Certificate. The end entity’s authentication with their existing AUSkey provides the necessary EOI for this renewal (see section 3.1.4). Once the AUSkey has been renewed, expiry is again two years. This means the renewed AUSkey could be used daily over the next ten months and would not be renewed. However, if used after 10 months and one day, the AUSkey is once again renewed. The impact of this is that an AUSkey Holder who uses their AUSkey only once a year would always have a current AUSkey.
  3. The new AUSkey is downloaded to the local certificate store, the AUSkey software installed on the end entity’s computer generates the new Key Pair (see section 4.1.2) and relevant Certificate Information for the new AUSkey is provided to the ABR RA’s system and to the Trust Broker via the AUSkey Manager (see sections 1.3.11 and 2.1.3).
  4. The next time the AUSkey is used, the system selects the new credential and confirms that it is functioning and overwrites the old AUSkey in the key store.
    Attention

    Note: although the new AUSkey Certificate overwrites the old Certificate, the old Certificate is not revoked.

    End of attention

  5. The renewal process remains invisible with no end user intervention required.
  6. The system generates and stores a confirmation that the Certificate has been renewed successfully. This confirmation is not displayed in the user interface.

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

Certificate re-key is the process of generating a new Key Pair and issuing a new Certificate that certifies the new Public Key. All AUSkey Certificate renewals include re-keying as described in section 4.5 above. The AUSkey system does not support:

  • Certificate re-key requests (outside of the AUSkey System’s automatic renewal routine), or
  • Certificate re-key after revocation (as revoked AUSkeys cannot be renewed).

4.7 Certificate Modification

Certificate modification is not supported.

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 section and the applicable CP.3.1.6

  • 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 Security 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 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 Highly Protected clearance via a vetting agency. The Facility Manager must ensure those personnel have Highly Protected 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 Crimes Act 1914
  • 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

and 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. All backup copies are to be registered and their location recorded in an operations log.
  • Store tapes from a five week cycle both onsite and offsite. Daily differentials are 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. Further confidential details are 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. For that changeover, the ABR CA’s Keys and Certificates are re-issued by the ABR RCA.

Key changeover periods will be in accordance with the Key Management Plan contained within GKP001 Security Profile and prior to normal Certificate/Key expiry.

The AUSkey System renews end user AUSkey Certificates automatically, as described previously. See the relevant CP for further details.

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. 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. 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:

  1. Physical investigation of disaster and collection of necessary evidence to complete investigation.
  2. Re-establishment of secure environment for AUSkey operations.
  3. Reconstitute the ability to issue CRLs and process revocation requests – this includes audit functionality.
  4. Reconstitute the ability to receive, process and issue AUSkeys.
  5. Return to stable operating conditions.
  6. Update documentation to reflect any changes as a result of recovery – including to processes, procedures and configuration.
  7. 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
  • renew any existing Certificates
  • enter into or renew an applicable contract relating to such a Certificate,

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.

Attention

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.

End of attention

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, and
  • 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 of Certificates 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 Highly Protected 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.

Attention

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.

End of attention

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 Renewal Ceremonies, 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, or
  • 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)
  • DSD Australian Government Information Security Manual (ISM), 2012 Release
  • Attorney General’s Department Protective Security Policy Framework (2010) 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:

  1. firewalls
  2. strong authentication
  3. physical access controls
  4. mechanisms to prevent denial-of-service attacks
  5. 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 DSD 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 the 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 the 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 the 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”.

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-1 (since SHA-256 is not supported by the UniCERT CA or VANguard).

7.6 CA CRL Profile

CRL Attributes
Attribute Value

CRL issue period

90 minutes.

CRL validity

7 hours.

CRL signature digest

SHA-1 (since SHA-256 is not supported by the UniCERT CA or VANguard).

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, and
  • 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

Attention

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

End of attention

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/s), 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, or
  • 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 to by them to resolve that dispute.
  • If those parties are not able to agree on that proposed or an alternate mediator within seven days of receiving that proposal, then the parties will appoint the person nominated by the President for the time being of the Australian Institute of Arbitrators to resolve that dispute. Either party may request the President of the Australian Institute of Arbitrators to make such a nomination.
  • 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, and
    • 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 or renewal 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, or
  • 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.

Attention

Note: See individual AUSkey System materials – e.g. the front page of this CPS.

End of attention

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.2 - updated 5 November 2013

Last modified
19 Feb 2019
ID
153