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:
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:
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.
SBR is a multi-agency initiative that will simplify business to government reporting by:
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.
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:
The AUSkey COI consists of Relying Parties (who accept AUSkeys) and Business Entities (who have AUSkeys). For the purposes of the AUSkey COI:
Note: the SBR channel refers to the lodgment of forms using SBR-enabled business software. An example is when an end entity lodges a form from within an accounting or similar software package (like MYOB or Quicken) that is SBR-enabled.
Participation in the AUSkey COI:
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:
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:
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.
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.
The use of the following in the preparation of this document is gratefully acknowledged:
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:
The ABR CA is the single operational Certification Authority in the AUSkey Certificate hierarchy. The ABR CA is responsible for generating AUSkey Certificates and CRLs.
Note: although the ABR CA generates AUSkey Certificates, the end user’s Private Keys are generated by the end user – the AUSkey Holder. The ABR CA’s own Certificate is signed by the ABR RCA.
The ABR CA receives AUSkey Certificate signing and revocation requests over HTTP from (and digitally signed by) the ABR RA. The ABR CA’s system processes all of the signed requests it receives from the ABR RA’s system via HTTP with no further checks. All the business logic and security controls confirming which requests are valid are provided by the ABR RA’s system.
The ABR CA’s software system is a commercial off the shelf (COTS) product. It operates online to support a real-time certificate management process, and consequently needs to be highly available, with low latency, for processing Certificate signing and revocation requests.
The ABR CA’s system must be kept highly secure, since its Key material is used to protect the integrity of all AUSkey Certificates. The ABR CA’s Private Key material is stored in a dedicated Hardware Security Module (HSM) to provide this security assurance. The ABR CA’s system also includes the ABR CA database, which is used to store data such as information on Certificates issued by the ABR CA and their status, and audit logs.
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:
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.
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:
A Business Associate of a Business Entity:
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.
An Administrator is the AUSkey Holder of an AUSkey Standard Certificate who has undertaken an EOI check and been granted administrator level privileges in relation to that Certificate. Only an Administrator may appoint themselves or another AUSkey Holder to the role of Device Custodian.
Note: the grant of Administrator status is a separate authorisation process that is not inherent in the grant of an AUSkey Certificate.
In order to obtain administrator level privileges, an individual must be nominated by either a validated Business Associate of the relevant Business Entity, or another individual within that Business Entity who is already in possession of a valid AUSkey Standard Certificate with Administrator privileges (that is, an Administrator may appoint an Administrator).
Details on how Administrators are appointed are described in the GKP003 Standard Certificate Policy.
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:
Details on how Device Custodians are appointed are described in the GKP003 Device Certificate Policy.
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.
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:
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:
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:
See section 4.4 and the applicable CP for appropriate usage of each AUSkey Certificate type.
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.
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.
The Gatekeeper Core Obligations PolicyExternal Link is published by the Department of Finance (AGIMO). That Policy:
Note: for Gatekeeper Accreditation purposes, ABR Services is a Relationship Organisation, and AUSkeys are Certificates in the Special Category.
When generating a Digital Certificate, the CA must ensure that:
Complies – see section 4.2
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
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
The CA must ensure the prompt:
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)
In the event that a CA terminates its operations (whether voluntarily or involuntarily) it must:
Complies – see section 5.8 and sections 5.8.1 to 5.8.4.
Registration Authority Core Obligations
Evidence of Identity (EOI) – General
A Registration Authority must:
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 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.
Known Customer Organisation Core Obligations
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.
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:
The Known Customer Organisation must:
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:
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.
Threat / Risk Organisation Core Obligations
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.
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.
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.
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:
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.
Subscriber Core Obligations
A Subscriber must:
Complies – see sections 4.1.2, 4.4, 5.7.3 and 6.1.1.
Relying Party Core Obligations
A Relying Party must:
Complies – see sections 1.3.10 and 6.1.4.
The AUSkey System includes several repositories to support its operation. These are described below.
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.
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.
The following repositories support the AUSkey System:
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.
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.
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:
In general, the principles set out below apply to all AUSkey Certificates.
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).
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:
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.
Where the ABR RA retains a copy of EOI documentation submitted by applicants, it must ensure the secure storage of that information in accordance with the requirements of this CPS.
The ABR RA must, in respect of an AUSkey signing request, ensure that its knowledge of, and history of its dealings with, the relevant applicant is sufficient, to an internally defined risk level and for internally determined purposes, to authorise the issuance of a Gatekeeper compliant Digital Certificate to that applicant. Accordingly, the rules for AUSkey Operator verification of applicants, including EOI status, conform to existing ABR processes on identity verification.
Note: The existing ABR processes on identity verification arise principally because the ABR Registrar must, under the A New Tax System (Australian Business Number) Act 1999, be satisfied that an individual’s identity has been established before including their name in a Business Entity’s ABR entry (e.g. as an ‘associate’ or ‘nominated representative’ of that Business Entity).
For applications for Standard AUSkeys with Administrator level privileges, existing ABR processes are applied to verify the identity of the proposed AUSkey holder (and the applicant, if a different person):
Applications for Standard AUSkeys with User level privileges, and Device AUSkeys, to be held for a Business Entity must be made or approved by an Administrator (for that same Business Entity) whose identity has been verified as above and who verifies the identity of the proposed AUSkey holder.
If an error is identified in the 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.
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.
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.
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.
The methods for requesting a revocation of an AUSkey include the following:
Any exceptions or variations to the above must be set out in the applicable CP.
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
This section contains a generalised summary of the life-cycle operational requirements for AUSkey Certificates. More specific details for particular types of AUSkey Certificates may be found in the applicable CP. The processes are described at a high-level, from the perspective of human end users.
Note: all AUSkey life-cycle event requests must come through a valid ABR RA communication, using standards based formats such as Public Key Cryptography Standards (PKCS) payloads. At a technical level, a request will only succeed if the ABR CA is able to successfully validate the request by verifying the ABR RA’s signing Certificate.
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.
An application for an AUSkey Certificate (to be held for a Business Entity), in the case of an:
For details, please see the applicable CP.
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:
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.
The typical issuance of an AUSkey Certificate includes these steps:
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:
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.
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.
Note: the X.509 key usage field in the Certificate itself does not convey any express or implied permission to use any AUSkey Certificate in any way, unless such use is explicitly permitted in the applicable contract.
The use of an AUSkey Certificate and associated Keys by a Relying Party may also be further limited by any relevant contractual or other arrangement between the ABR Registrar and that Relying Party. The Relying Party is responsible for ensuring that AUSkey Certificate is only used by it within all such limits.
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:
Note: although the new AUSkey Certificate overwrites the old Certificate, the old Certificate is not revoked.
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.
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 modification is not supported.
Circumstances for revocation include, but are not limited to, the following:
See sections 3.1.2, 3.1.6, 4.8.1 and the applicable CP.
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
Revocation of AUSkey Operator certificates or elements of the AUSkey System infrastructure are contained in classified documents, primarily the Key Management Plan.
Suspension is not supported for any AUSkey Certificates. AUSkeys can only be revoked.
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.
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.
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.
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.
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.
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.
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.
Fire extinguishers and smoke alarms are located within the relevant secure operating areas.
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.
Paper documents and magnetic media containing Private Key or commercially sensitive or confidential information are securely disposed of by:
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:
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.
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).
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.
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.
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.
All AUSkey System personnel shall be trained in the following:
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.
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.
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.
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.
All AUSkey Operators must sign a confidentiality and non-disclosure agreement. These staff (all of whom have HP clearance) have access to:
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.
The minimum audit records to be retained include all for the following:
Audit logs are processed on a daily, weekly, monthly and annual basis.
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).
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.
Audit logs are backed-up daily.
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.
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.
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.
The ABR CA produces and stores the following data:
The ABR RA produces and stores the following data:
The following audit information is archived:
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).
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:
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.
The AUSkey Operators have the following responsibilities:
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.
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.
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:
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.
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.
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).
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:
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.
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.
The AUSkey Holder must promptly:
If an AUSkey Private Key is compromised it is revoked and the AUSkey Holder must re-apply for a new AUSkey Certificate.
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:
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:
In the event of a CA (the ABR CA or ABR RCA) termination, the CA must not:
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:
A programmed termination will arise where there is termination by the ABR CA or ABR RCA for default or for convenience.
Insofar as it is required, that CA shall affect a transfer of Keys and Certificates to another CA service provider. The alternate service provider must also be Gatekeeper accredited. The transfer must be performed in a manner agreed to by the AUSkey PMA and Gatekeeper Competent Authority. For the purposes of this and the next section, Keys and Certificates can be taken to mean any set of Keys and Certificates within that CA’s span of control.
Note: this section only attempts to list the high level actions of cessation of the ABR CA or ABR RCA service. On Cessation of such a CA Service a “CA Transition-Out Plan” will be formulated and released by the AUSkey PMA.
If programmed termination is required by the ABR CA or the ABR RCA, then the AUSkey PMA will:
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:
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.
In the event of the ABR CA termination:
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.
All AUSkeys operate with single Key Pairs.
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.
End users generate their own Private Keys so no delivery by the ABR CA is necessary.
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.
Relying Parties do not directly obtain a user’s Public Key. The process is as follows:
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).
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).
Keys used within the AUSkey System generated using the RSA algorithm. The RSA algorithm does not require the generation of parameters.
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).
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.
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.
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).
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.
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.
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.
Private Keys are deactivated by removal of the token or HSM (where used) or by logging out.
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.
See section 6.2.1.
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.
In general, AUSkey Certificates issued to end users have an operational period of two years, and the key usage period is also two years. For more details please see the relevant CP.
The ABR CA has a certificate operational period and a key usage period of 10 years.
Note: AUSkey System Certificate lifetimes are nested and the Key lifetime depends on the Certificate life. That is, an issued Certificate (of an end entity or a CA) expires before the Certificate of the CA that issued it. Otherwise, after the ABR CA Certificate’s expiration, the issued Certificate becomes invalid, even if it hasn’t expired itself.
Key lifetimes are set as a matter of policy and will depend on a number of factors, with shorter Key lengths usually having shorter usage periods.
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.
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.
This is sensitive information and is detailed in the confidential GKP001 Security Profile.
Controls in place include:
Hardware in use meets standards including Common Criteria EAL4 and FIPS 140-1.
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:
Further information can be found in the Security Plan.
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.
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:
Further information surrounding this subject can be found in the Security Plan.
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:
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.
The network security controls include:
The network security controls were developed after conducting a comprehensive threat and risk assessment.
The AUSkey System environment:
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.
All audit log entries and transactions must be time-stamped and the asserted times shall be accurate to within +/- 5 seconds.
“3” to indicate X.509 version 2 certificates.
Distinguished Name of the issuing CA:
Common Name = Australian Business Register Root CA
OU = Certification Authority
Organisation = Australian Business Register
Country = AU.
20 years maximum (expressed as “From” and “To” dates)
Distinguished Name of the certificate subject, in this case the device associated with the private key:
The public key and the public key algorithm (RSA 4096 with a SHA-512).
Defines valid purposes, in this case:
CP information such as the OID and the URL where the CPS is available:
Policy Identifier OID = 126.96.36.199.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.
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.
Distinguished - Name of the issuing CA
OU= Certification Authority
10 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 = Australian Business Register CA
The public key and the public key algorithm (RSA 2048 with a SHA-256 digest).
Policy Identifier OID = 188.8.131.52.3001.1.1.1.1
Same value as Australian Business Register Root CA Subject Key Identifier.
Common Name = Australian Business Register RA
The public key and the public key algorithm (RSA 2048 with a SHA-256).
Digital Signature, Non-Repudiation.
Policy Identifier OID = 184.108.40.206.3001.1.1.4.1
Indicates if the subject may act as a CA and should be set to “False”.
160-bit SHA-1 hash of the value of the BIT STRING of the RA’s subjectPublicKey (Method 1 described in RFC5280).
Same value as Australian Business Register CA Subject Key Identifier.
For end entity Certificate Profiles, for example for AUSkey Standard or Device Certificates, please see the relevant CP.
CRL issue period
A new CRL is issued each time the Root CA is brought online to renew the Australian Business Register CA.
CRL signature digest
SHA-1 (since SHA-256 is not supported by the UniCERT CA or VANguard).
List of revoked certificates by serial number.
Not included in the CRL.
Date at which it is known or suspected that the private key was compromised or that the certificate should otherwise be considered invalid.
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 criteriaExternal Link. 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.
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.
Auditors require expertise in relation to:
Auditors must be independent third parties and have no actual or potential conflict of interest during the period of the audit.
The purpose of audits is to ensure that AUSkey System PKI infrastructure elements such as each CA and RA:
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.
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.
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.
Note: an order of precedence applies to the documents forming the applicable contract – see section 1.1.4.
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 ABR Privacy Statement.
See the relevant CP for details on Personal Information contained in a particular type of Certificates.
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:
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:
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:
Any indemnities are contained in the Conditions of Use or other applicable contracts.
Any Notice under this document must be in writing and must be sent to the intended recipient by:
A Notice, consent, request or other communication will be taken to have been received by the recipient if sent:
This document may be amended by or under the authority of the AUSkey PMA as follows:
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.
This document is governed by the laws for the time being in force in the Australian Capital Territory, Australia.
No fees are payable to the ABR Registrar (or ABR Services) in relation to:
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:
‘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.
No further stipulation.
Note: See individual AUSkey System materials – e.g. the front page of this CPS.
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.
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.
ABR Root Certification Authority (RCA) OID
Standard CP (covers Users and Administrators)
Version 1.2 - updated 5 November 2013