The ABR Registrar has established the AUSkey System as Public Key Infrastructure to facilitate internet-based electronic transactions between Business Entities and Agencies, and manages the AUSkey System’s operational Certification Authority (the ABR CA).
This document is the GKP003 Device Certificate Policy. This Certificate Policy (CP) sets out the rules applying to, and provides policy and operational guidance on the deployment of, AUSkey Device Certificates issued by the ABR CA.
This CP must be read in conjunction with the following documents, which can be accessed online:
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).
Device Certificates are used to identify servers or other computer devices within organisations, rather than individuals within organisations.
An AUSkey Device Certificate:
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 Device Certificate Policy. It is identified by the object identifier (OID): 126.96.36.199.3001.1.1.8.1, based on the following structure:
Australian Business Register (ABR)
Australian Business Register Root CA (RCA)
Australian Business Register Operational CA (OCA)
Device 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.
Note: a Device Custodian is the individual responsible for safeguarding and managing the use of an AUSkey Device Certificate on behalf of the Business Entity identified in that Certificate. The Device Custodian is linked to that Certificate linked through processes external to the Certificate (that is, the Device Custodian is not identified in the Certificate itself).
See CPS section 1.3.9.
Note: a Device is computer hardware (such as a server) onto which a Device Certificate may be installed. For an AUSkey Device Certificate, the Device on which it is installed must be owned, controlled and/or operated by the Business Entity identified in that Certificate.
See CPS section 1.3.10.
See CPS section 1.3.11.
The appropriate use of an AUSkey Device Certificate is limited to authenticating the Device identified in that Certificate as owned, controlled and/or operated by the Business Entity identified in that Certificate for the purposes of a machine-to-machine interaction between that Business Entity and an SBR Agency within the AUSkey COI.
A typical transaction for an AUSkey Device Certificate would be a Business Entity’s system submitting a form (that does not need to be lodged or signed by an individual) directly to an SBR Agency’s system through the SBR channel.
Note: the SBR channel refers to the lodgment of forms using SBR-enabled business software.
An AUSkey Device Certificate is designed for the Business Entity identified by its ABN in that Certificate to authenticate itself, and that it owns, controls and/or operates the Device identified in that Certificate, for the purposes of carrying out a machine-to-machine interaction with an SBR Agency within the AUSkey COI. The AUSkey System does not support use of AUSkeys by or with any other relying parties. Any person who uses, or relies on, an AUSkey Device Certificate in any other circumstances does so at their own risk and responsibility.
Note: the use of an AUSkey Device Certificate for a given transaction with a participating SBR Agency depends not only on the nature of the transaction (whether it can be carried out machine-to-machine, or needs to be signed or submitted by an individual), but also on the Agency’s system (whether it is designed to accept that transaction machine-to-machine). For transactions submitted and accepted using a web browser, an AUSkey Standard Certificate should be used. AUSkey Device Certificates are not suitable for transactions that require a web-based logon.
Find out more
For other limits on use, refer to the:
Any kind of unlawful or improper purpose of an AUSkey Device 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 Device the subject of the Certificate and compliant with the X.501 standard. The 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, as set out in the certificate profile outlined in section 7 of this CP.
The common name of the Device is a component of that DN, and is supplied in the application for the AUSkey Device Certificate. The name supplied must be meaningful, unambiguous and (in the Business Entity concerned) unique to the Device, and should be either a domain name or an IP address as these will provide unique and distinguishable Device names that are both intuitive and allow for a logical and documented Device naming schema within the Business Entity.
The AUSkey System does not allow anonymity or pseudonymity for any AUSkey Certificate subject names, including Device names.
Any disputes in relation to names in AUSkey Device Certificates will be resolved by the AUSkey Policy Management Authority (AUSkey PMA).
Note: although Device names must be unique, it is possible that a single Device may be issued multiple Certificates. This is to allow for cluster implementations so that a Certificate may be installed on each individual server within a cluster. For example, a Business Entity may have several servers in an array for failover and load balancing. An AUSkey Device Certificate must be installed on each of those servers. It is optional how a Business Entity would name their Device Certificates in such a configuration. If it elects to have:
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 Device Certificate must be made online through the AUSkey Manager by an Administrator for the Business Entity concerned, and that Administrator must nominate a Device Custodian to be associated with that Certificate. That Administrator may nominate him or her self as that Device Custodian.
When applying for an AUSkey Device Certificate, the Administrator initially identifies and authenticates him or her self to the AUSkey Manager using their AUSkey Standard Certificate (a website logon, including a valid password).
For the identity validation details required in order to obtain administrator level privileges in relation to an AUSkey Standard Certificate, see GKP003 Standard Certificate Policy section 3.2.1.
Note: For applications for Standard AUSkeys with Administrator level privileges, existing ABR processes are applied to verify the identity of the proposed AUSkey holder:
In an application for an AUSkey Device Certificate (to be held for a Business Entity), the nominated Device Custodian is selected from a list of individuals who hold a valid AUSkey Standard Certificate for that same Business Entity, and is initially identified and authenticated by reference to their Certificate.
For the identity validation details required in order to obtain an AUSkey Standard Certificate, see GKP003 Standard Certificate Policy sections 3.2.1 and 3.2.3.
Note: Applications for Standard AUSkeys with User level privileges must be made or approved by an Administrator whose identity has been verified (in accordance with existing ABR processes on identity verification) and who verifies the identity of the proposed AUSkey holder.
AUSkey Device Certificates are renewed automatically.
The renewal process is described in sections 4.5 and 4.6 below.
If the revocation of an AUSkey Device Certificate (held for a Business Entity) is requested through the AUSkey Manager by the Device Custodian associated with that Certificate, or by an Administrator for that Business Entity, they identify and authenticate themselves to the AUSkey Manager using their AUSkey Standard Certificate (a website logon, including a valid password).
If a telephone request is made to an AUSkey Operator for the revocation of an AUSkey Device Certificate (held for a Business Entity), the caller must provide sufficient identity details to allow the AUSkey Operator, in accordance with existing ABR processes, to validate the caller’s identity, and verify their status as the Device Custodian associated with that AUSkey Device Certificate, or an Administrator for a or Business Associate of that same Business Entity.
All revocation requests must come through the ABR RA. The ABR CA will only action a revocation request if the ABR CA successfully validates the request by verifying the ABR RA’s signing certificate.
This section deals only with the life-cycle operational requirements for AUSkey Device Certificates. For life-cycle event details for AUSkey Standard Certificates, see the applicable CP. Details of certain infrastructure certificates not used by any end entities may be found in the CPS. The certificate life-cycle events are described at a high-level, from the perspective of human end users.
Note: all certificate life-cycle event requests must come through a valid ABR RA communication, using standards based formats such as Public Key Cryptography Standards (PKCS) payloads. At a technical level, a request will only succeed if the ABR CA is able to successfully validate the request by verifying the ABR RA’s signing certificate.
An application for an AUSkey Device Certificate (to be held for a Business Entity):
The Administrator may nominate – as the Device Custodian – either themselves or another individual who holds a valid AUSkey Standard Certificate for the Business Entity concerned. The individual nominated may already be associated with another Device Certificate as its Device Custodian.
The typical issuance of an AUSkey Device Certificate includes these steps:
Note: the selected store file may be temporary pending the Device Custodian transferring the Certificate to e.g. the server location – see section 4.4.1 below.
Note: if a password already exists due to prior issuance of an AUSkey Certificate to the Device Custodian’s selected location, then the correct password must be entered.
The AUSkey Device Certificate Conditions of Use set out responsibilities of the Device Custodian of an AUSkey Device Certificate (and of the Business Entity for which that Certificate is held) in relation to that Certificate. Responsibilities of the Device Custodian are also set out in this CP. That Device Custodian’s acceptance of those Conditions of Use constitutes acceptance of that Certificate. The use of that Certificate constitutes acceptance of:
AUSkey Device 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 Device Certificate may be used for (and its one Key Pair can be used for) both signing and encryption (confidentiality) purposes. However, encryption use should only be for traffic in transit. AUSkey Device Certificates are not designed to encrypt data long term, for example in a database.
Note: SBR Agencies may only accept Device Certificates for limited transactions and only then if their systems are designed to accept those transactions machine-to-machine.
The Device Custodian for an AUSkey Device Certificate is responsible for:
Other responsibilities and obligations of the Device Custodian are also set out in this CP, the AUSkey Device Certificate Conditions of Use and the CPS (e.g. CPS sections 4.1.2, 4.4, 5.7.3 and 6.1.1).
Note: a Business Entity remains responsible for any transactions performed on its behalf using its Device Certificate, and for ensuring its Device Certificate is managed in a secure manner. Before a Business Entity enters onto an IT Outsourcing, SaaS or similar arrangement – particularly where its Device Certificate is hosted by the 3rd party provider or the Device Custodian is not its direct employee – it should obtain its own legal advice on managing those responsibilities under that arrangement.
See CPS sections 1.3.10 and 6.1.4.
Device Certificates are renewed automatically 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, is once again renewed. This means that a Device which uses an AUSkey only once year would always have a current AUSkey.
See section 4.6 below for Certificate re-key.
If an AUSkey Device 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).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 Device 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 Device 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.
Note: an Administrator can re-assign a Device Certificate from one Custodian to another (see GKP003 Standard Certificate Policy section 4.4.2). If a Custodian’s Standard Certificate is revoked, the Device Certificate needs to be re-assigned within 30 days otherwise it will be automatically revoked.
Revocation of an AUSkey Device Certificate – held for a Business Entity – may be requested by:
Organisations cannot initiate revocation action when acting as Relying Parties.
The revocation of an AUSkey Device Certificate may be requested by the Device Custodian associated with that Certificate, an Administrator for or a Business Associate of, the Business Entity identified in that Certificate, as follows:
The CA must advise the Trust Broker of the revocation in accordance with the requirements of the CPS, and notify the relevant Device Custodian (or in default, an Administrator for or Business Associate of the relevant Business Entity) that the Device Certificate is revoked. The notice need not include the reason for revocation.
The CA must also archive the revoked Device Certificate and the certificate revocation request for a period of seven years after the Certificate would have otherwise expired.
Note: this is to provide proof of who requested the digital certificate or its revocation, which may be necessary as part of a forensic investigation if the existence of the Certificate itself is ever questioned.
Access to revocation information will be through a standards compliant and approved X.509 protocol such as LDAP.
Suspension is not supported for Device Certificates under this CP.
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 device associated with the private key.
Common Name = assigned by business, recommend businesses use relevant domain name or IP address
Organisation = Business entity ABN value
Country = AU
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 Device 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.8.1
Certificate Practice Statement available at 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 VANguard)
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