This came up when working on test implementation of COSE-HPKE:
Section 3.2. HPKE Encryption with SealBase says:
"This specification does not mandate the use of the info and the aad
parameters."
This looks to be very problematic for interop: Both info and aad must
match on sender and receiver side for anything to work. Furthermore,
external_aad only makes sense in layer 0, it is message-global
property. external_aad at layer 1 should be empty.
Section 3.4. Info Structure says:
"This section provides a suggestion for constructing the info structure,
when used with SealBase() and OpenBase()."
Suggestion? This construction is interop-critical.
And then there are issues with multiple fields of the proposed
construction:
- AlgorithmID: HPKE always includes algorithm info, so this is
redundant.
- PartyUInfo: HPKE base mode does not support authentication, so this
needs to be pulled from enveloping structure if any. However:
+ Identity is not the same as kid, and suggestion to use kid as
identity looks pretty strange to me. There are dedicated PartyU
header fields anyway.
+ The construction talks about pulling values out of COSE_Sign_Tagged
and COSE_Mac_Tagged. The problem is that these can have multiple
signatures/MACs, and then it is unclear which one should be used.
- PartyVInfo:
+ Same kind of using kid as identity as in PartyU case.
+ There are dedicated PartyV header fields. If those are in protected
attributes, this is redundant as protected attributes are included
anyway.
- SuppPubInfo.keyDataLength: What on earth is one supposed to put here?
HPKE has no coherent number of bits to extract from KDF (it currently
always invokes KDF twice with different output lengths).
+ Using main key length would be unnecressary layering violation.
+ Obviously, HPKE always includes this info.
- SuppPubInfo.other/SuppPrivInfo: These look like nice ways to ruin
interop, but base RFC8152/RFC8152bis-algs already has those anyway.
And then one thing to beware when signing/MACing HPKE ciphertexts is
that none of the HPKE encryption algorithms are committing (GCM and
Poly1305 are infamous for being non-committing). Which means that HPKE
ciphertexts may decrypt with multiple keys to different plaintexts.
Another minor concern is that if something goes wrong with key
derivation in one-layer COSE-HPKE, the result is trying to decrypt the
content with wrong key, which might be unpleasant if content is large.
However, if content is large, overhead of two-layer structure (which
does not decrypt anything large with potentially wrong keys) is minor.
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
