64   clearToken1 should not hold IVs

Created: 31 Oct 2024

Status: Approval (Editoral)

Part: Part 4 (2018, Edition 1.1)

Links:

Page: Annex B

Clause: aesnnn-cbc

Paragraph: 1

Issue

Annex B under Supported-encrypt-algorithms ::= { aes256-CBC } defines aes128-CBC and aes256-CBC as
aesxxx-CBC ALGORITHM ::= {
PARMS AES-InitializationVector
IDENTIFIED BY id-aesxxx-CBC }
Since this is carried in clearToken1 there is nothing to encrypt and no need for an IV. ClearToken2 which is used for conveying information does contain an IV field.

Proposal

Renove these definitions. It is sufficient to have the algo fields in clearToken1 simply be defined as having type ALGORITHM.

Discussion Created Status
Erik already reacted in comment that the IV shall not be included in ClearToken1

Add further info: “As future improvement the update of the ALGORITHM definition according to X.509 Corrigendum comprising fixed and dynamic parameter is envisioned”

Remaining open issue reltes to a typo: encr-mode.aea-non.encr.algo should read encr-mode.non-aea.encr.algo

Attachement 20250103_iec62351-4-tissue_64.pdf provides further information on what data to be included in ClearToken1
03 Jan 25 Approval (Editoral)
To be converted to Approval (Editorial) as only the editorial correction remains.

Note that the editorial update will be contained in an updated Annex B
19 Dec 24 Discussion (red)
Text already states that the CllearToken1 should not hold the IV.

Remaining issue is the editorial correction of "encr-mode.aea-non.encr.algo component" to "encr-mode.non-aea.encr.algo"
13 Dec 24 Accepted
"encr-mode.aea-non.encr.algo component", should this not be "encr-mode.non-aea.encr.algo"? 15 Nov 24 Accepted
Action by Erik

The PARMS fields of aes128-CBC and aes256-CBC algorithms have been commented out.

NOTE:
In13.3.1.1, i) the encr-mode component, 2) The non-aea alternative, i) In the encr component it is stated:
The encr-mode.aea-non.encr.algo component shall not include the AES-InitializationVector.
It should not have been an issue.
14 Nov 24 Accepted
Action by Erik

The PARMS fields of aes128-CBC and aes256-CBC algorithms have been commented out.

NOTE:
In13.3.1.1, i) the encr-mode component, 2) The non-aea alternative, i) In the encr component it is stated:
The encr-mode.aea-non.encr.algo component shall not include the AES-InitializationVector.
It should not have been an issue.
14 Nov 24 Accepted
I think that in the mentioned definitions, the "PARMS AES-InitializationVector" can be removed. So, these definitions can be made simpler. 07 Nov 24 Accepted
The transport of IV in cleartoken2 instead of cleartoken1 and also the transport of the nonce in the authenticator instead of cleartoken1 has been stated in TISSUE#60 and should be handled in the same batch.

Proposal to handle the changes related to the selection and tranport of cryptographic parameters in cleartoken1 and cleartoken2 in one TISSUE and refer to the resolution from other tissues.
31 Oct 24 Accepted

 

Privacy | Contact | Disclaimer

Tissue DB v. 24.12.6.1