Introduction
Certificates are a key component in maintaining the security and trust between participants of the Consumer Data Right (CDR) ecosystem.
Both Transport Layer Security (TLS) and Mutual Transport Layer Security (mTLS) communication is used within the CDR ecosystem, depending on the scenario. TLS and mTLS rely on certificates to establish the secure communication channel.
All 'authenticated' connections in CDR use mTLS in a private trust chain based on certificates provisioned by the ACCC. The ACCC uses DigiCert as the Certificate Authority (CA) for this purpose. The certificates provisioned for CDR are known as 'Register CA certificates' or 'CDR certificates' and they form a trust chain to a 'CDR Root CA'.
In mTLS, a client and server certificate are used, and both sides of the connection (client and server) need to verify the respective certificates, hence the term “mutual”. In CDR, the client and server certificates are both 'CDR certificates'.
In TLS, only a server certificate is used. The client needs to verify that the server certificate is valid and trusted before establishing a connection to it. For TLS connections, the 'CDR certificates' provisioned for mTLS connections should not be used. Participants should use certificates from a well-known CA whitelisted by major web browsers.
This article outlines guidance that can be used for the validation of certificates, whether or not they have been provisioned by the ACCC CA.
Certificate Authority
DigiCert is the Certificate Authority (CA) of the CDR. The client and server certificates used for mTLS within the CDR are provisioned by DigiCert, via the ACCC.
All certificates used in mTLS should be validated to ensure that they have been provisioned by the DigiCert CA, based on the Root and Intermediate certificates of the CDR.
The trust chain of CDR certificates is as follows:
- CDR Root CA
- CDR Intermediate CA
- Participant Certificate (client or server)
The Root and Intermediate certificates used in the CDR ecosystem are available in the Certificate Management section of the Consumer Data Standards documentation.
Certificate Agreements
As part of the CDR on-boarding process, participants are required to accept two agreements for the acceptance, use and reliance on certificates: the Subscriber and Relying Party Agreements. Both agreements, as well as the Certificate Policy and Certificate Practice Statement, can be found on the CDR website . If these agreements are not accepted, then the participant cannot proceed through the on-boarding process and cannot be made active on the Register.
Acceptance of the certificate agreements also encompasses agreement to the Certificate Policy. The Certificate Policy includes sections on certificate revocation (4.9) and certificate status services (4.10).
Certificate Validation
Prior to relying on information listed in a certificate, a Relying Party (participant) must confirm the validity of each certificate in the certificate path in accordance with IETF PKIX standards, including:
- checking for certificate validity,
- ie. verify private key signature is mathematically linked to the presented public key certificate, presented certificate identifies trusted User/Application and/or Service and certificate is both valid and not revoked
- the current Register design does not require client organisation metadata as published on the GetDataRecipients endpoint to be validated against the certificate in the validation process. This information published on the GetDataRecipients endpoint is mutable and does not currently require certificate re-issuance on change.
- issuer‐to‐subject name chaining,
- ie. signatures from Issuing CA’s and associated CA public key certificates are trusted, valid and not revoked
- policy and key use constraints, and
- ie. each certificate has the applicable and appropriate x.509 certificate extensions, e.g. CA and CRL signing, Digital Signing, Client and Server Authentication, etc
- revocation status through Certificate Revocation Lists (CRL) or Online Certificate Status Protocol (OCSP) responders, identified in each certificate in the chain.
- See sections on CRL and OCSP below.
Certificate Revocation Lists (CRL)
DigiCert maintains a Certificate Revocation List (CRL) for all subscriber certificates issued for the CDR. The CRL contains a list of certificates that have been revoked before their scheduled expiration date and should no longer be trusted.
The issuance frequency of CRLs issued by DigiCert are outlined in table below:
|
Type |
Issuance Frequency |
|
Routine |
At least once every 24 hours |
|
Loss/Compromise of Private Key |
Within 18 hours of notification |
|
CA Compromise |
Immediately, but no later than within 18 hours of notification |
The serial number of a revoked certificate remains on the CRL until one additional CRL is published after the end of the Certificate's validity period, with the expired certificate serial number then automatically removed from the next published CRL.
Online Certificate Status Protocol (OCSP)
In addition to CRLs, participants may support online status checking with OCSP. OCSP is the preferred mechanism for checking the validity of certificates used within the ecosystem and software using online status checking need not obtain or process CRLs.
OCSP involves performing a lookup of the status of a given certificate against an OCSP Responder. It is described in RFC 6960 .
Each CDR certificate provisioned by DigiCert includes OCSP details that can be used in the validation process. As the CA, the OCSP Responder is provided by DigiCert.
Configuring OCSP
Infrastructure used in mTLS communication, such as web servers, API gateways and Web Application Firewalls (WAF), commonly have support for OCSP out of the box. Generally, nothing more needs to be done to configure OCSP specifically. However, some infrastructure/software may offer the ability to alter OCSP cache timeouts. In those situations, consideration should be given to the frequency of updates to OCSP responses given by DigiCert.
OCSP Update Times
|
Type |
Update Frequency |
|
Revocation |
Within 2 hours of notification |
|
Routine |
At least once every 4 days |
Unavailability
While certificate status services are designed to be available 24x7 without interruption, there may be times when the certificate status services are unavailable.
Relying Parties are bound to their obligations and the stipulations of the Relaying Parties, Certificate Policy and the Certification Practice Statement irrespective of the availability of the certificate status service.
Certificate status services are available 24x7 without interruption. However, there may be times when the certificate status services are unavailable.
Relying Parties are bound to their obligations and the stipulations of the Relying Party Agreement, Certificate Policy and the Certification Practice Statement irrespective of the availability of the certificate status service.
The Register Design Reference outlines that data sharing cannot proceed if the authenticating certificate(s) revocation status checking is not possible, either in 'real time' or cached mode.
NOTE: CRL and OCSP revocation checking responses have a set validity period.
Participants may decide to use CRL as a fallback mechanism when OCSP is unavailable and some infrastructure products and services support this configuration. Participants are encouraged to consult product documentation for their particular situation.
OCSP Stapling
The use of OCSP Stapling within the CDR ecosystem is not currently recommended.
OCSP Stapling is generally used to address concerns about OCSP TLS negotiation delays by removing the need for a separate network connection to DigiCert's OCSP responders. It is typically used by web servers to ensure that the browser gets the same response performance for the certificate status as it does for the website content, by providing a pre-cached OCSP response in the TLS handshake.
If participants believe that OCSP Stapling would have a positive impact on the ecosystem and would like to promote its adoption, please contact the ACCC to discuss.
References
|
Name |
Location |
|
Subscriber Agreement |
https://www.cdr.gov.au/sites/default/files/2020-12/CDR - ACCC Subscriber agreement.pdf |
|
Relying Party Agreement |
https://www.cdr.gov.au/sites/default/files/2020-12/CDR - ACCC Relying party agreement.pdf |
|
Certificate Policy |
https://www.cdr.gov.au/sites/default/files/2020-12/CDR - ACCC Certificate policy.pdf |
|
Certification Practice Statement |
https://www.cdr.gov.au/sites/default/files/2020-12/CDR - ACCC Certification practice statement.pdf |
|
Register Design - Certificate Management |
https://cdr-register.github.io/register/#certificate-management |
|
Register Design - Certificate Authority Unavailable |
https://cdr-register.github.io/register/#certificate-authority-unavailable |
|
RFC 6960 |
|
|
OCSP |
Comments
0 comments
Please sign in to leave a comment.