Ambiguity around serialization of encryption packet in section 5.2.1

[alexanderkjall]

Hi

In section 5.2.1 it's stated:

   //   Input:
   //   algID     - the algorithm ID encoded as octet
   //   publicKey - the recipient's encryption sub-key packet
   //               serialized as octet string

   fixedInfo = algID || SHA3-256(publicKey)

As far as I have understood it, the sub-key packet might be represented in different ways.

This is from a conversation I had about it:

< teythoon> capitol: because when we hash packets or kdf them, we provide an explicit normalized form
< teythoon> capitol: normalized wrt the packet framing
< teythoon> capitol: because the ctb may be new or old, the packet length can be encoded in different ways, none of which should change the semantics
< capitol> oh, tricky
< teythoon> yeah
< teythoon> my preferred interpretation of that would be to simply exclude packet framing

Should there maybe be a clarification around this added to 5.2.1?

[wussler]

Hello @alexanderkjall, we considered to remove the PK hash in favor of hashing the PK material only with PRs #50 and #55

[falko-strenzke]

The problem is solved by not using the public key as input any more.