The draft security standard uses the term ‘Mutual TLS’ ambiguously. In some contexts it appears that MTLS is meant, and in other cases it appears that the standard may have intended TLS Mutually Authenticated (i.e. requiring the client to prove its identity with a certificate as in RFC5246 7.4.6).
Partially related to the above, we have the following comments and questions:
Part(s) of standard
Comment/Question
Where references are made to ‘MTLS’
What validation checks are needed on the client certificates for resource servers and for authorisation servers? Is validation of the certificate chain from the trusted CA (i.e. the ACCC directory) or any other validation check required? Our expectation is that this is not the case as in the [MTLS] normative reference s.2 and s4.2.
11.2. Mutual TLS which is referenced by 5. Client Authentication
From 11.2 “All back-channel communication between Data Recipient and Data Holder systems MUST incorporate, unless stated otherwise, MTLS as part of the TLS handshake…” Similarly in 5.
Is TLS-MA meant here?
i.e. “TLS-MA as part of the TLS handshake…”
11.2. Mutual TLS
“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.”
What is the rationale for requiring server certificates to be bound to the CDR (ACCC) certificate authority? Why not allow other certificate authorities already trusted by industry (e.g. Entrust, DigitCert)?
11.2. Mutual TLS
(This question may be best directed to the ACCC.) Will client certificates be bound in any way to the client applications of data consumers in any way? I.e. If a data consumer has two client applications will there be a client certificate issued for each or a common certificate for both?
13. Endpoints
This section gives transport security requirements for each authorisation endpoint as either ‘TLS’ or ‘MTLS’.
Specific references as to what needs to be enforced in the MTLS case would be appreciated. Do both cases require TLS-MA? Does ‘TLS’ mean ‘TLS-MA’?
What about resource endpoints? Should we follow the standards draft for the requirements? It would be good to align the formatting between the two if so. Is ‘Mutual TLS’ referring to TLS-MA in the Additional Constraints section we linked to above? We will also direct this question to the standards working group.
Interpretation of the security profile
Across the security profile and the technical standard, we’d like to confirm our interpretations. In particular:
The following authorisation endpoints are TLS only:
Authorisation Endpoint
OpenID Provider Configuration Endpoint
JWKS Endpoint
The following authorisation endpoints are TLS with signed JWT using a ACCC client certificate which is not required to be validated during the TLS handshake:
Backchannel Authorisation Endpoint
Token Endpoint
Userinfo Endpoint
Introspection Endpoint
Revocation Endpoint
Client Registration Endpoint
The resource endpoints are TLS-MA using a ACCC issued client certificate which should be validated and that there is no other alternative method supported (e.g. TLS with a signed JWT using a client certificate).
URI Structure
The draft technical standard specifies a <provider path> for resource endpoints. We suggest that explicit requirements are also published for the endpoints in the security standard. We request that the following assumptions are accommodated:
Mutual TLS
The draft security standard uses the term ‘Mutual TLS’ ambiguously. In some contexts it appears that MTLS is meant, and in other cases it appears that the standard may have intended TLS Mutually Authenticated (i.e. requiring the client to prove its identity with a certificate as in RFC5246 7.4.6).
We suggest either removing the term in all cases, or aligning with the [MTLS] normative reference which uses this term to mean Transport Layer Security Mutual Authentication (TLS-MA). If the latter option is taken then the definition of Mutual TLS should be made explicit.
Comments and Questions
Partially related to the above, we have the following comments and questions:
which is referenced by
5. Client Authentication
From 11.2 “All back-channel communication between Data Recipient and Data Holder systems MUST incorporate, unless stated otherwise, MTLS as part of the TLS handshake…” Similarly in 5.
i.e. “TLS-MA as part of the TLS handshake…”
“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.”
Will client certificates be bound in any way to the client applications of data consumers in any way? I.e. If a data consumer has two client applications will there be a client certificate issued for each or a common certificate for both?
Specific references as to what needs to be enforced in the MTLS case would be appreciated. Do both cases require TLS-MA? Does ‘TLS’ mean ‘TLS-MA’?
What about resource endpoints? Should we follow the standards draft for the requirements? It would be good to align the formatting between the two if so. Is ‘Mutual TLS’ referring to TLS-MA in the Additional Constraints section we linked to above? We will also direct this question to the standards working group.
Interpretation of the security profile
Across the security profile and the technical standard, we’d like to confirm our interpretations. In particular:
URI Structure
The draft technical standard specifies a
<provider path>for resource endpoints. We suggest that explicit requirements are also published for the endpoints in the security standard. We request that the following assumptions are accommodated:<provider path>to endpoints which must use TLS-MA.