Updates to Certificate Management

[ACCC-CDR]

Description

Various updates are requested to be made to the Certificate Management section of the Consumer Data Standards in order to match the security issuing procedures of the ACCC.

Area Affected

Security Profile > Certificate Management

Change Proposed

Various changes are proposed.

Data Recipient Server Certificates

Currently within the Certificate Management section of the Consumer Data Standards, there is an option for Data Recipients to request a server certificate issued by the Register CA. They are also given the option to use a server certificate issued by a Public CA.

As the Data Recipient hosted endpoints are not mTLS there is no need to use a Register CA issued server certificate. As such, the ACCC has never issued a server certificate to a Data Recipient. Data Recipients can simply use a server certificate issued by a Public CA, which would then align to their current certificate management practices for their software product.

Therefore, it is recommended that the wording around server certificate issuance to a Data Recipient is updated to remove the option to request a Register CA issued server certificate.

Certificate Signing Request

Also, to provide additional guidance to participants requesting Register CA issued certificates, the following amendments are requested to the Certificate Signing Request Profile section:

• Include additional fields that can be provided in a CSR
• Change Common Name to Software Product Name only for client certificate
• Change Organization to include the Brand Name only
• Add a mandatory indicator to specify which fields are required or optional
• Include a statement that if optional fields are required then they will be validated to ensure correctness

For e.g.

CSR Field	Field Requirement	Server	Client
Common Name (CN)	Mandatory	Primary DNS Name e.g. api1.test.entity.com	Software Product Name
SAN	Optional	Secondary DNS Name(s) e.g. api2.test.entity.com	N/A
Organization (O)	Mandatory	Brand Name	Brand Name
Organizational Unit (OU)	Mandatory	Consumer Data Right	Consumer Data Right
Country (C)	Mandatory	Country of participant e.g. AU	Country of participant e.g. AU
State (ST)	Optional	State of the Participant e.g. New South Wales	State of the Participant e.g. New South Wales
Locality (L)	Optional	Locality of the Participant e.g. Sydney	Locality of the Participant e.g. Sydney
Email Address	Optional	Participant's email address to be displayed in the issued certificate	Participant's email address to be displayed in the issued certificate
Signature Algorithm	Mandatory	SHA256	SHA256
Key Algorithm	Mandatory	RSA	RSA
Key Size	Mandatory	2048	2048

Note: optional values, if provided, will be validated to be correct.

Certificate Trust Model

Remove the Test Environment details from the Certificate Trust Model section. Participants will be provided the trust chain for the test environment when they begin CTS.

DSB Proposed Solution

The DSB proposed solution is presented here.

[perlboy]

Firstly, discrepancies in ACCC issuing versus the Standard have been gradual particularly throughout 2022. Biza customers had certificates issued at the beginning of last year which had different constraints on them than those issued at the end of the year, this lack of clarity led to multiple back and forths and requirements from the ACCC that, quite frankly, were in violation of the prescribed Standard. There's a broader question here of what the point of a Standard actually is if government bodies aren't going to comply with it.

Secondly, the use of a Software Product Name exclusively for the client certificate conflicts with the use of either Software Product or Brand name for authentication to the register ("client_id, iss and sub claims MUST be set to the ID of the calling client Data Recipient Brand ID OR Software Product ID issued by the CDR Register") . This seems to therefore suggest there are broader changes that should be enacted.

Finally, on the dropping of Register CA certificate availability for Recipients. It's unclear what the design of AI looks like however if there are more drivers for Holder -> Recipient comms it's a very real possibility that such APIs may be preferred to be conducted over an ACCC CA secured channel.

Alternatively there's a broader question about what the point of securing a single surface with an ACCC CA certificate actually is, that is to say, the value the ACCC CA actually serves at a server (ie. Holder) level is dubious. I suspect many holders would prefer to simply roll-up their CDR services into their normal PKI management procedures. Why not ditch the ACCC CA server certificate entirely and use it purely for MTLS client purposes, possibly in both directions depending on AI?

[JamesMBligh]

After discussions in the MI meetings and inter-agency discussions with the ACCC the proposed solution for the issues raised in this CR will be:

• Discussion of the use of the CDR CA in general will be deferred to the Register Review consultation
• The Certificate Signing Request and Certificate Trust Model sections will be updated as outlined in the issue description to reflect the practice of the Registrar

Note that we did seriously consider taking this section out of the standards as it is more operational/guidance in nature but we have decided to retain it for the moment as removing it without a clear and discoverable location for community members to find the information would cause more problems than it solves. This isn't a permanent position, however.

[perlboy]

Not sure if this is the right thread however recent changes to the ACCC CTS approach to certificate authorities preclude the ability for Holders to deliberately test a Production environment against the CTS, effectively forcing them to conduct CTS testing on a non-production environment and most probably leading to differences between what has been tested and what is released to Data Recipients.

Specifically the following statements within the Standards would be in violation if a Holder wished to complete CTS successfully:

Use of MTLS
All back-channel communication between Data Recipient Software Product and Data Holder systems MUST incorporate, unless stated otherwise, [MTLS] as part of the TLS handshake:
The presented Client transport certificate MUST be issued by the CDR Certificate Authority (CA). The Server MUST NOT trust Client transport certificates issued by other authorities.
The presented Server transport certificate MUST be issued by the CDR Certificate Authority (CA). The Client MUST NOT trust Server transport certificates issued by other authorities.

The ACCC has recently announced that the CTS will no longer be issuing certificates from the CDR Certificate Authority. While the announcement makes reference to the new authority being "production-like" this seems to ignore the fundamental laws of cryptography.

Conversely (or perversely?) the ACCC requires Holders to make an attestation that the environment is Production-like, Biza does not consider an environment with an incorrect CA to be Production-like so will be unable to provide this attestation.

[nils-work]

Changes for this issue were staged here and incorporated into Standards version 1.24.0.