Advertised Signing Algorithms about standards-maintenance HOT 6 CLOSED

Unfortunately the DSB has no information on the specifics of the Register implementation. It is recommended that this question be asked of the Register team on GitHub at https://github.com/cdr-register/register

If an answer is unable to be obtained via that channel then the DSB team would be happy to engage with the ACCC to determine an answer to this query.

from standards-maintenance.

Thanks @CDR-API-Stream, I agree for one part of this query which is why I have asked a linked question there.

On the Standards side however, the question is whether Recipients implementing to the Standards must support both PS256 and ES256 in order to be compliant. As per original question:

More simply is ES256 support mandatory for Data Recipients to implement?

from standards-maintenance.

Apologies, the focus of the query was misunderstood. As the standards do not prescribe any specific algorithm and as the normative references allow for both PS256 and ES256 then a data recipient should support both of these algorithms if they wish to reliably connect to any data holder.

To be clear, however, this is not a mandatory requirement of the CDR standards. Only a practical outcome of the use of OIDC constrained by FAPI R/W. For instance, if all data holders implement PS256 exclusively then a data recipient would not need to support ES256.

from standards-maintenance.

Apologies, the focus of the query was misunderstood. As the standards do not prescribe any specific algorithm and as the normative references allow for both PS256 and ES256 then a data recipient should support both of these algorithms if they wish to reliably connect to any data holder.

To be clear, however, this is not a mandatory requirement of the CDR standards. Only a practical outcome of the use of OIDC constrained by FAPI R/W. For instance, if all data holders implement PS256 exclusively then a data recipient would not need to support ES256.

It is impossible for Data Holder to implement and test ES256 as this is only possible if the ACCC Register is an Elliptic Curve CA. Assuming that the ACCC CA is more traditional RSA based the timeline for converting to EC certificates would be measured in years (possibly a decade depending on CA key lifetime).

As per library support outlined at Jwt.io there is a variety of support for these algorithms but requiring support for both decreases the available choices somewhat materially.

In addition the cipher list provided in FAPI-RW and reiterated in the Standards includes EC related combinations.

In order to optimise the pathway for a Recipient to reach CDR compliance I would suggest that explicit guidance be given that at least for the forseeable future only PS256 and a suitable cipher list are required.

from standards-maintenance.

If you would like to propose this change in a change issue with Rationale it will be considered for a future iteration.

from standards-maintenance.

As per above link to CDR Register github, it is impossible to propose a change without information from the government.

from standards-maintenance.