Certificate policy - Device AUSkey

1 Overview

1.1 Overview

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

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

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

1.1.1 Standard Business Reporting (SBR) Program

See CPS section 1.1.1.

1.1.2 The AUSkey System

See CPS section 1.1.2.

1.1.3 Community of Interest (COI)

See CPS section 1.1.3.

Attention

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

End of attention

1.1.4 Device Certificates

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

An AUSkey Device Certificate:

  • identifies a Business Entity (by its ABN), and a particular Device (computer hardware, such as a server) that is owned, controlled and/or operated by that Business Entity, and
  • facilitates machine-to-machine interactions between that Business Entity and SBR Agencies.

1.1.5 This Certificate Policy and the Certification Practice Statement

See CPS section 1.1.4.

Attention

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.

End of attention

1.2 Document Name and Identification

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

1

ISO code

2

Member Body

36

Australia

1

Government

3001

Australian Business Register (ABR)

1

Australian Business Register Root CA (RCA)

1

Australian Business Register Operational CA (OCA)

8

Device Certificate Policy

1

Version number

1.2.1 Attribution

See CPS section 1.2.1.

1.3 AUSkey Participants

1.3.1 ABR Root Certification Authority (ABR RCA)

See CPS section 1.3.1

1.3.2 ABR Certification Authority (ABR CA)

See CPS section 1.3.2.

1.3.3 ABR Registration Authority (ABR RA)

See CPS section 1.3.3.

1.3.4 Business Entities

See CPS section 1.3.4.

1.3.5 Business Associates

See CPS section 1.3.5.

1.3.6 Users

See CPS section 1.3.6.

1.3.7 Administrators

See CPS section 1.3.7.

1.3.8 Device Custodians

See CPS section 1.3.8.

Attention

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

End of attention

1.3.9 Devices

See CPS section 1.3.9.

Attention

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.

End of attention

1.3.10 Relying Parties

See CPS section 1.3.10.

1.3.11 Trust Broker

See CPS section 1.3.11.

1.4 Certificate Usage

1.4.1 Appropriate certificate use

The appropriate use of an AUSkey Device Certificate is limited to authenticating the Device identified in that Certificate as owned, controlled 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.

Attention

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

End of attention

1.4.2 Limits on use

An AUSkey Device Certificate is designed for the Business Entity identified by its ABN in that Certificate to authenticate itself, and that it owns, controls 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.

Attention

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.

End of attention

Find out more

For other limits on use, refer to the:

1.4.3 Prohibited certificate uses

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

1.5 Policy Administration

See CPS section 1.5.

1.6 Definitions and Acronyms

See CPS section 1.6.

2 Publications and Repositor Responsibilities

2.1 Repositories and Publication Information

The AUSkey System operates several repositories supporting its operations.

2.1.1 Publications

See CPS section 2.1.1.

2.1.2 The Certificate Revocation List (CRL)

See CPS section 2.1.2.

2.1.3 Internal Data Repositories

See CPS section 2.1.3.

3 Identification and Authentication

3.1 Naming

Every Certificate issued under this CP must have a Distinguished Name (DN) that is unique to the Device the subject of the Certificate and compliant with the X.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).

Attention

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

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

End of attention

3.2 Initial Identity Validation

See section 3.1.2 of the CPS.

Attention

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.

End of attention

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.

3.2.1 Initial Administrator Identity Validation

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.

Attention

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

End of attention

3.2.2 Initial Device Custodian Identity Validation

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

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

Attention

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.

End of attention

3.3 Identification and Authentication for Renewal Requests

AUSkey Device Certificates are renewed automatically.

The renewal process is described in sections 4.5 and 4.6 below.

3.4 Identification and Authentication for Revocation Request

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

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

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

4 Certificate Life-Cycle Operational Requirements

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

Attention

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.

End of attention

4.1 Certificate Application

4.1.1 Who can submit an application for a Device Certificate?

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

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

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

4.1.2 Certificate application process

  1. The process for an Administrator for a Business Entity applying for an AUSkey Device Certificate – to be held for that same Business Entity – is generally as follows:
  2. The Administrator authenticates to the AUSkey Manager using their AUSkey Standard Certificate.
  3. The Administrator selects the new device option and follows the system prompts to:
    • enter the requested details of the Device, including a DN identifying it (e.g. server name or IP address)
    • select a Device Custodian for the Device Certificate from a list of individuals holding valid AUSkey Standard Certificates for that Business Entity.

     

  4. The Administrator submits the application, and the AUSkey System generates and displays an application reference number and advises the Administrator that a notification email will be sent to the nominated Device Custodian.
  5. The AUSkey System sends the nominated Device Custodian a notification email informing them of the application and their nomination as the Device Custodian for the named Device.
  6. The AUSkey System records the registration details of the Device Custodian, associating them with that AUSkey Device Certificate.
  7. The nominated Device Custodian clicks on a link in the notification email, and enters and submits the displayed Captcha code to initiate certificate activation and begin the issuance process.

4.2 Certificate Issuance

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

  1. The AUSkey System prompts the Device Custodian to accept the AUSkey Device Certificate Conditions of Use.
  2. The Device Custodian accepts those Conditions of Use.
  3. The Device Custodian selects the location to which the AUSkey Device Certificate is to be downloaded and stored (a default key store, other existing key store, or new location).
    Attention

    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.

    End of attention

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

    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.

    End of attention

  5. The AUSkey Device Certificate is generated and downloaded to the selected store file.
  6. The AUSkey System generates and stores a confirmation message that the AUSkey Device Certificate has been activated successfully.

4.3 Certificate Acceptance

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

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

4.4 Key Pair and Certificate Usage

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

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

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

Attention

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.

End of attention

4.4.1 Device Custodian responsibilities

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

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

     

  • managing the use of, and safeguarding, the Device Certificate
  • requesting revocation of the Device Certificate, when required.

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

Attention

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.

End of attention

4.4.2 Relying Party responsibilities

See CPS sections 1.3.10 and 6.1.4.

4.5 Certificate Renewal

4.5.1 Routine renewal

Device Certificates are renewed automatically as follows:

  1. Whenever an AUSkey Device Certificate is used, the AUSkey System checks the Certificate’s expiration date.
  2. If the system determines that the expiration date is near (within 14 months), a new AUSkey Device Certificate request is generated and signed using the old Certificate’s Keys (providing the necessary EOI for Certificate renewal).
    Attention

    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.

    End of attention

  3. The PKCS#10 Certificate request is sent to the AUSkey Manager and then forwarded to the ABR RA.
  4. The ABR RA validates and checks the contents of the PKCS#10 data.
  5. The ABR RA signs the AUSkey Standard Certificate request.
  6. The ABR RA stores the signed request in the local ABR RA database.
  7. The ABR RA sends the request to the ABR CA.
  8. The ABR CA issues and returns a Certificate chain containing the new AUSkey Device Certificate, the ABR CA Certificate and the ABR RCA Certificate.

See section 4.6 below for Certificate re-key.

4.5.2 Renewal after revocation

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.

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:

  1. Whenever an existing AUSkey Device Certificate is used, the AUSkey System checks the Certificate’s expiration date.
  2. If the AUSkey Device Certificate is due to expire within 14 months, the system initiates the renewal process (see section 4.5 above).
  3. The new AUSkey Device Certificate is generated and downloaded to the local key store (where the existing AUSkey is stored), silently, with no interaction with the Device Custodian.
  4. The next time the Device attempts to authenticate using the existing AUSkey Device Certificate, the system selects the new AUSkey Device Certificate, confirms that it is functioning, and overwrites the old AUSkey in the key store.
  5. The system generates and stores a confirmation that the AUSkey Device Certificate has been renewed successfully. This confirmation is not displayed in the user interface.

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

4.7 Certificate Modification

Certificate modification is not supported by the AUSkey System. See CPS section 4.7.

4.8 Certificate Revocation and Suspension

4.8.1 Circumstances for revocation

See CPS sections 4.8.1, 4.10 and 5.7.1.

Attention

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.

End of attention

4.8.2 Who may request revocation

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

  • the Device Custodian associated with that Certificate
  • an Administrator for or a Business Associate of that Business Entity
  • the ABR RA, or
  • the ABR Registrar.

Organisations cannot initiate revocation action when acting as Relying Parties.

4.8.3 Procedure for revocation request

The revocation of an AUSkey Device Certificate may be requested by the Device Custodian associated with that Certificate, an Administrator for or a Business Associate of, the Business Entity identified in that Certificate, as follows:

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

The CA must advise the Trust Broker of the revocation in accordance with the requirements of the CPS, and notify the relevant Device Custodian (or in default, an Administrator for or Business Associate of the relevant Business Entity) that the Device Certificate is revoked. The notice need not include the reason for revocation.

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

Attention

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.

End of attention

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

4.8.4 Suspension of Device Certificates

Suspension is not supported for Device Certificates under this CP.

4.9 Certificate Status Services

See CPS section 4.9.

4.10 End of Subscription

See CPS section 4.10.

4.11 Key Escrow and Recovery

See CPS section 4.11.

5 Facility, Management and Operational Controls

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

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

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.

End of attention

6 Technical Security Controls

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

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

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.

End of attention

7 Certificate, CRL and OCSP Profiles

7.1 Device Certificate Profile

Certificate Fields
Attribute Value

version

“3” to indicate X.509 version 2 certificates.

serialNumber

Unique identifier for each certificate, composed of incremental positive integers.

signature

Algorithm identifier for the algorithm used by the CA to sign the certificate: SHA-1 with RSA encryption.

issuer

Distinguished Name of the issuing CA:

Common Name = Australian Business Register CA

OU = Certification Authority

Organisation = Australian Business Register

Country = AU.

validity

2 years maximum (expressed as “From” and “To” dates)

subject

Distinguished Name of the certificate subject, in this case the device associated with the private key.

Common Name = assigned by business, recommend businesses use relevant domain name or IP address

Organisation = Business entity ABN value

Country = AU

subjectPublicKeyInfo

The public key and the public key algorithm (RSA 1024 with a SHA-1 digest).

 

Certificate Extensions
Attribute Value

Key size

1024

keyUsage

Defines valid purposes, such as encipherment or signature, for the key contained in the certificate. Settings will include Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment. The values keyCertSign or crlSign are not allowed in Device Certificates. See section 4.4 above for more information on valid usage of the single key pair.

certificatePolicies

CP information such as the OID and the URL where the CPS is available:

Policy Identifier OID = 1.2.36.1.3001.1.1.8.1

Certificate Practice Statement available 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.

basicConstraints

Indicates if the subject may act as a CA and should be set to “False”.

ABN (custom extension)

Uses the Gatekeeper II OID to identify the ABN:

1.2.36.1.333.1

The ABN value is encoded as an IA5String.

7.2 CRL Profile

CRL Attributes
Attribute Value

CRL issue period

90 minutes

CRL validity

7 hours

CRL signature digest

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

revokedCertificates

List of revoked certificates by serial number.

reasonCode

Not used.

invalidityDate

Date at which it is known or suspected that the private key was compromised or that the certificate should otherwise be considered invalid.

7.3 OCSP Profile

No stipulation.

8 Compliance Audits and Other Assessments

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

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

9 Other Business and Legal Matters

Attention

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

End of attention

9.1 Privacy of Personal Information

See CPS section 9.1.

9.2 Representations and Warranties

See CPS section 9.2.

9.3 Disclaimers of all other Warranties

See CPS section 9.3.

9.4 Limitations of Liability

See CPS section 9.4.

9.5 Indemnities

See CPS section 9.5.

9.6 Notices

See CPS section 9.6.

9.7 Amendments

See CPS section 9.7.

9.8 Dispute Resolution Procedures

See CPS section 9.8.

9.9 Governing Law

See CPS section 9.9.

Version 1.2 - updated 5 November 2013

Last modified
26 Oct 2018
ID
155