Alignment with ISO 17090-4 and Points for Discussion Comment submitted by: IHE-Japan

[findex-miyakawa]

To ensure consistency and alignment with the ongoing revision of ISO 17090-4, it is recommended to foster discussion and exchange opinions among stakeholders on the following points:

Specific examples for discussion:

• Rationale for limiting Detached mode to ObjectIdByURI format: What is the reasoning behind supporting only the ObjectIdByURI format for Detached signatures?
• Justification for restricting to SHA256: What are the grounds for limiting the hash algorithm to SHA256?
• Clarification on Payload handling in Detached mode: The document proposes removing the Payload from the JWS JSON object in Detached mode. Should a zero-byte stream be set instead of removing it entirely?
• Inclusion of JAdES-B-LTA in Long-Term Signature support: Is there a specific reason for excluding JAdES-B-LTA from the scope of Long-Term Signature support?

[ritikarawlani]

Thank you for the comments. At the core of the decision making were the principles to set up "minimal" requirements that can be tested at connectathons for the purposes of interoperability. Keeping that in mind, specific rationale is provided below for the points raise:

Justification for restricting to SHA256: SHA256 has been requested as the minimal only for the purpose of interoperability testing. It does not restrict from using additional other algorithms that best fit the need.

Quoting from the chapter "RS256 algorithm SHALL be implemented for the purpose of interoperability testing. However, implementors SHOULD take into account additional considerations such as jurisdictional policies, quantum safe computing, and evolving guidance from RFC 7518 and ETSI TS 119 312."

Clarification on Payload handling in Detached mode: This was picked from the base guidance https://datatracker.ietf.org/doc/html/rfc7515#autoid-82 which suggests that "when using the JWS JSON Serialization, the deletion is accomplished by deleting the "payload" member". However, For the computation of the signature we did recommend following section 5.2.8.3.2 of the JAdES.

Inclusion of JAdES-B-LTA in Long-Term Signature support: JAdES-B-LTA is not excluded, it's just not set as the minimal requirement keeping in alignment with DSG chapter for XML . However, we did discuss it and saw that the main distinguishing parameter would be the "arcTst" which is additionally required by the JAdES-B-LTA. Do you think/have reasons for why "arcTst" should be minimally required?

We're discussing objectIdbyURI and will respond soon