The ABR Registrar has established the AUSkey System as Public Key Infrastructure (PKI) to facilitate internet-based electronic transactions between Business Entities and Agencies, and manages the AUSkey System’s operational Certification Authority (the ABR CA).
This document is the GKP003 Standard Certificate Policy. This Certificate Policy (CP) sets out the rules applying to, and provides policy and operational guidance on, the deployment of AUSkey Standard Certificates issued by the ABR CA.
This CP must be read in conjunction with the following documents, which can be accessed online:
See CPS section 1.1.1.
See CPS section 1.1.2.
See CPS section 1.1.3.
Note: the COI for AUSkey Certificates is restricted to government Agencies who are part of the SBR Program, and Business Entities who have an Australian business number (ABN).
AUSkey Standard Certificates are issued to individuals acting on behalf of Business Entities that:
Note: individuals acting for Agencies within the AUSkey COI may also be issued with AUSkey Standard Certificates in situations where the Agency also acts as a Business Entity.
See CPS section 1.1.4.
Note: a document hierarchy applies: the provisions of the Conditions of Use or other relevant contract override the provisions of this CP, and the provisions of this CP override the CPS.
This document is known as the GKP003 Standard Certificate Policy. It is identified by the object identifier (OID) 126.96.36.199.3001.1.1.7.1, based on the following structure:
Australian Business Register (ABR)
Australian Business Register Root CA (RCA)
Australian Business Register Operational CA (OCA)
Standard Certificate Policy
See CPS section 1.2.1.
See CPS section 1.3.1.
See CPS section 1.3.2.
See CPS section 1.3.3.
See CPS section 1.3.4.
See CPS section 1.3.5.
See CPS section 1.3.6.
See CPS section 1.3.7.
See CPS section 1.3.8.
See CPS section 1.3.9.
See CPS section 1.3.10.
See CPS section 1.3.11.
The appropriate use of an AUSkey Standard Certificate is limited to the Certificate Holder authenticating him or herself to, and carrying out an electronic transaction with, an SBR Agency within the AUSkey COI on behalf of the Business Entity identified in that Certificate.
The typical transaction would be the submission of a form for a Business Entity with revenue reporting and payment obligations to an SBR Agency, for example lodgment of a Business Activity Statement with the ATO.
An AUSkey Standard Certificate is designed for its Certificate Holder (on behalf of the Business Entity identified by its ABN in that Certificate) to authenticate him or herself to, and to carry out electronic transactions with, SBR Agencies within the AUSkey COI. The AUSkey System does not support use of AUSkeys by or with any other relying parties. Any person who uses, or relies on, an AUSkey Standard Certificate in any other circumstances does so at their own risk and responsibility.
Note: an AUSkey does not provide any indication of the level of authority, delegation or privileges that the AUSkey Holder may possess, and is for authentication rather than authorisation purposes.
Find out more
For other limits on use, refer to the:
Certification practice statement
AUSkey Standard Certificate Conditions of Use.
Any kind of unlawful or improper use of an AUSkey Standard Certificate is prohibited.
See CPS section 1.5.
See CPS section 1.6.
The AUSkey System operates several repositories supporting its operations.
See CPS section 2.1.1.
See CPS section 2.1.2.
See CPS section 2.1.3.
Every Certificate issued under this CP must have a Distinguished Name (DN) that is unique to the Certificate Holder the subject of the Certificate and compliant with the X.501 standard. That DN must be in the form of a X.501 printable string and may not be blank.
That DN will be present in the Certificate’s subjectName field, with the Common Name in the form <User given names><Space><User family name>, as set out in the certificate profile outlined in section 7 of this CP.
The Certificate Holder’s common name is a component of that DN, and is supplied in the application for the AUSkey Standard Certificate. The name supplied must be meaningful, unambiguous and (in the Business Entity concerned) unique to the Certificate Holder.
The AUSkey System does not allow anonymity or pseudonymity for any AUSkey Certificate subject names.
Note: an AUSkey Standard Certificate identifies the Certificate Holder in its subjectName field, and the ABN of the Business Entity for which it is held in its subjectOrganisation field – see section 7.1.
Any disputes in relation to names in AUSkey Standard Certificates will be resolved by the AUSkey Policy Management Authority (AUSkey PMA).
See section 3.1.2 of the CPS.
Note: for identify validation, the AUSkey System allows identity details to be entered online, which are then validated to a previous documentary based Evidence of Identity (EOI) process/es. In some cases documentary EOI is required, such as where the identity details supplied are insufficient or incorrect.
An application for an AUSkey Standard Certificate must be authorised by:
In order to obtain administrator level privileges in relation to an AUSkey Standard Certificate, the Certificate Holder (or proposed Certificate Holder) of that Certificate must:
Note: The existing ABR processes on identity verification arise principally because the ABR Registrar must, under the A New Tax System (Australian Business Number) Act 1999, be satisfied that an individual’s identity has been established before including their name in a Business Entity’s ABR entry (for example as an ‘associate’ or ‘nominated representative’ of that Business Entity).
For applications for Standard AUSkeys with Administrator level privileges, existing ABR processes are applied to verify the identity of the proposed AUSkey holder (and the applicant, if a different person):
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.
Where an application for an AUSkey Standard Certificate (to be held by the proposed Certificate Holder for a Business Entity) is made by, or is to be authorised by, a Business Associate of that Business Entity, that Business Associate must supply:
Note: Under the A New Tax System (Australian Business Number) Act 1999, the ABR Registrar must first be satisfied as to an individual’s identity before listing that person, in a Business Entity’s ABR entry, as an ‘associate’ of that Business Entity. Where an AUSkey application is made or authorised by a Business Associate, the existing ABR processes on identity verification are applied to validate that person’s identity and that they are listed in the ABR as an ‘associate’ of the relevant Business Entity.
Where an application is made for an AUSkey Standard Certificate, to be held by the proposed User for a Business Entity (and in respect of which that User is not to have Administrator level privileges):
AUSkey Standard Certificates are renewed automatically. See CPS section 3.1.4.
The renewal process is described in sections 4.5 and 4.6 below.
If the revocation of an AUSkey Standard Certificate (held by the Certificate Holder for a Business Entity) is requested through the AUSkey Manager by that Certificate Holder, or by an Administrator for that same Business Entity, that Certificate Holder or Administrator (as the case may be) identifies and authenticates him or herself to the AUSkey Manager using their AUSkey (a website logon, including a valid password).
If a telephone request is made to an AUSkey Operator for the revocation of an AUSkey Standard Certificate (held by the Certificate Holder for a Business Entity), the caller must provide sufficient identity details to allow the AUSkey Operator, in accordance with existing ABR processes, to validate the caller’s identity, and verify their status as that Certificate Holder or an Administrator for or a Business Associate of that same Business Entity.
All such revocation requests must come through the ABR RA. The ABR CA will only action a revocation request if the ABR CA successfully validates the request by verifying the ABR RA’s signing certificate.
This section deals only with the life-cycle operational requirements for AUSkey Standard Certificates. For life-cycle event details for AUSkey Device Certificates, see the applicable CP. Details of certain infrastructure certificates not used by any end entities may be found in the CPS. The certificate life-cycle events are described at a high-level, from the perspective of human end users.
Note: all certificate life-cycle event requests must come through a valid ABR RA communication, using standards based formats such as Public Key Cryptography Standards (PKCS) payloads. At a technical level, a request will only succeed if the ABR CA is able to successfully validate the request by verifying the RA’s signing certificate.
In most cases, AUSkey Standard Certificate applications are carried out online through the AUSkey Manager and AUSkey website. However, the AUSkey System provides alternate processes so that, where necessary, process steps can be carried out manually via AUSkey Operators. Sections 4.1.2 to 4.1.6 describe the usual process steps for AUSkey Standard Certificate online applications.
The AUSkey System supports the following AUSkey Standard Certificate applications:
Note: a Business Entity’s first AUSkey application must be made by a Business Associate of that Business Entity, and must be for an AUSkey Standard Certificate with administrator privileges.
The process for an Administrator for a Business Entity applying online for an AUSkey Standard Certificate – to be held by a new User for that same Business Entity – is generally as follows:
The process for a person applying for an AUSkey Standard Certificate – to be held by them as a User for a Business Entity – is generally as follows:
On submission, an activation code is displayed to the applicant.
The process for an Administrator for a Business Entity applying for an AUSkey Standard Certificate – to be held by a new Administrator for that same Business Entity – is generally as follows:
The process for a Business Associate of a Business Entity applying for an AUSkey Standard Certificate – to be held by a new Administrator for that same Business Entity – is generally as follows:
Note: the privilege level of an AUSkey Standard Certificate is managed outside the Certificate. A variation to the privilege level (from user level to administrator level, or vice versa) does not result in, or require, a new Certificate being issued.
The process for an Administrator for a Business Entity to vary the privilege level of an existing AUSkey Standard Certificate – held for that Business Entity – is generally as follows:
The typical issuance of an AUSkey Standard Certificate includes these steps. The:
Note: if a password already exists due to prior issuance of an AUSkey Certificate to the Certificate Holder’s selected location, then the correct password must be entered.
The AUSkey Standard Certificate Conditions of Use set out responsibilities of the Certificate Holder of an AUSkey Standard Certificate (and of the Business Entity for which that Certificate is held) in relation to that Certificate. Responsibilities of the Certificate Holder are also set out in this CP. That Certificate Holder’s acceptance of those Conditions of Use constitutes acceptance of that Certificate. The use of that Certificate constitutes acceptance of:
AUSkey Standard Certificates operate with a single key pair and have their keyUsage extension set to include these values:
This means that, for the purposes of both X.509 and this CP, an AUSkey Standard Certificate may be used for (and its one Key Pair can be used for) both signing and encryption (confidentiality) purposes. However, encryption use should only be for traffic in transit. AUSkey Standard Certificates are not designed to encrypt data long term, for example in a database.
The Certificate Holder of an AUSkey Standard Certificate is responsible for:
Other responsibilities and obligations of the Certificate Holder are also set out in this CP, the AUSkey Standard Certificate Conditions of Use and the CPS (e.g. CPS sections 4.1.2, 4.4, 5.7.3 and 6.1.1).
An AUSkey Standard Certificate is held by an individual – the Certificate Holder – for the Business Entity identified in that Certificate (by way of its ABN). Where that Certificate has administrator level privileges, the Certificate Holder can perform the following administrative functions associated with that Business Entity’s correct and effective utilisation of the AUSkey system:
See CPS sections 1.3.10 and 6.1.4.
Routine Renewal of an AUSkey Standard Certificate takes place through the AUSkey System generating a new Key Pair and issuing a new Certificate that certifies the new Public Key. The auto-renewal process is invisible to the Certificate Holder and is generally as follows:
Note: once the AUSkey has been renewed, expiry is again two years. If it is used after 10 months from its renewal date and before its expiration date, it is once again renewed. This means an AUSkey Holder who uses their AUSkey only once year would always have a current AUSkey.
See section 4.6 below for Certificate re-key.
If an AUSkey Standard Certificate is revoked it will not be renewed. Instead, a new Certificate must be applied for and issued (see sections 3.2, 4.1 and 4.2 above).
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 Standard Certificate renewals include re-keying as follows:
The AUSkey System has no limit on the number of renewals it will perform on a single Certificate.
If an AUSkey Standard Certificate is not used within 14 months of its expiration date, it will expire at the end of its validity period (as set out in the Certificate Profile in section 7 below). The AUSkey System will not renew revoked or expired AUSkeys. Instead, a new Certificate must be applied for and issued (see sections 3.2, 4.1 and 4.2 above).
Certificate modification is not supported by the AUSkey System. See CPS section 4.7.
See CPS sections 4.8.1, 4.10 and 5.7.1.
Revocation of an AUSkey Standard Certificate – held by the Certificate Holder for a Business Entity – may be requested by:
Organisations cannot initiate revocation action when acting as Relying Parties.
The revocation of an AUSkey Standard Certificate may be requested by the Certificate Holder, an Administrator for or a Business Associate of, the Business Entity identified in that Certificate, as follows:
The CA must advise the Trust Broker of the revocation in accordance with the requirements of the CPS, and notify the relevant Certificate Holder (or in default, an Administrator for or Business Associate of the relevant Business Entity) that the AUSkey Standard Certificate is revoked. The notice need not include the reason for revocation.
The CA must also archive the revoked AUSkey Standard Certificate and the certificate revocation request for a period of seven years after the Certificate would have otherwise expired.
Note: this is to provide proof of who requested the digital certificate or its revocation, which may be necessary as part of a forensic investigation if the existence of the Certificate itself is ever questioned.
Access to revocation information will be through a standards compliant and approved X.509 protocol such as LDAP.
Suspension is not supported for AUSkey Standard Certificates under this CP. See CPS section 4.8.4.
See CPS section 4.9.
See CPS section 4.10.
See CPS section 4.11.
See section 5 of the CPS for a description of the AUSkey System’s facility, management and operational controls, including:
Note: the most detailed information on these matters is contained in GKP001 Security Profile (SEC 1), which contains sensitive security information and is not publicly available.
See section 6 of the CPS for a description of the AUSkey System’s technical security controls, including:
“3” to indicate X.509 version 2 certificates.
Unique identifier for each certificate, composed of incremental positive integers.
Algorithm identifier for the algorithm used by the CA to sign the certificate: SHA-1 with RSA encryption.
Distinguished Name of the issuing CA:
Common Name = Australian Business Register CA
OU = Certification Authority
Organisation = Australian Business Register
Country = AU.
2 years maximum (expressed as “From” and “To” dates)
Distinguished Name of the certificate subject, in this case the User associated with the private key.
Common Name = <User given names><Space><User family name>
dnQualifier=<Person identifier value>
Organisation = Business entity ABN value
Country = AU
The public key and the public key algorithm (RSA 1024 with a SHA-1 digest).
Defines valid purposes, such as encipherment or signature, for the key contained in the certificate. Settings will include Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment. The values keyCertSign or crlSign are not allowed in User Certificates. See section 4.4 above for more information on valid usage of the single key pair.
CP information such as the OID and the URL where the CPS is available:
Policy Identifier OID = 188.8.131.52.3001.1.1.7.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.
Indicates if the subject may act as a CA and should be set to “False”.
ABN (custom extension)
Uses the Gatekeeper II OID to identify the ABN:
The ABN value is encoded as an IA5String.
CRL issue period
CRL signature digest
SHA-1 (since SHA-256 is not supported by the UniCERT CA or The Trust Broker.
List of revoked certificates by serial number.
Date at which it is known or suspected that the private key was compromised or that the certificate should otherwise be considered invalid.
See section 8 of the CPS for a description of the AUSkey System’s compliance audits and other assessments, including:
Note: an order of precedence applies to the documents forming the applicable contract – see CPS section 1.1.4.
See CPS section 9.1.
See CPS section 9.2.
See CPS section 9.3.
See CPS section 9.4.
See CPS section 9.5.
See CPS section 9.6.
See CPS section 9.7.
See CPS section 9.8.
See CPS section 9.9.
Version 1.2 - updated 5 November 2013.