On Mon, Oct 24, 2022 at 10:16:24AM +0000, Hannes Tschofenig wrote:
> Hi all,
>
> I have updated the PR containing the alternative proposal discussed in
> https://mailarchive.ietf.org/arch/msg/cose/oI_cRYbxTEo2Uwn7aXQV0dCmYtA/
>
> Here is the PR:
> https://github.com/cose-wg/HPKE/pull/9
Some small tweaks (for future extensibility and simplification):
- Instead of registering hpke_sender to Common Header Parameters,
register encapsulated_key:
Name: encapsulated key
Label: TBD2 (Assumed: -4)
Value type: bstr / [*any] / {* any => any }
Value registry: N/A
Description: Encapsulated key for KEM-like algorithms
For algorithm HPKE, encapsulated key MUST be present in unprotected
bucket and its value SHALL be of type COSE_HPKE_Sender.
Rationale: This parameter would be reusable for dedicated Kyber
algorithm, or any other future KEM-like things. This does not alter
what goes on the wire in any way, just what registeries say about
the values.
The weird value type is meant to say: Any bstr, array or dictionary
as appropriate for the algorithm. E.g., I expect Kyber to put a
bstr here. And of course, HPKE uses COSE_HPKE_Sender here.
- COSE_HPKE_Sender could be simplified to:
COSE_HPKE_Sender = [
kdf: uint,
aead: uint,
enc: bstr,
? kem: uint
];
If kem field is present, the recipient MUST verify that the indicated
KEM is consistent with the private key and the length of enc, and then
use that KEM in decryption attempt. Otherwise the recipient MUST fail
decryption.
If kem field is absent, the recipient MUST verify that there is only
a single KEM consistent with the private key and the length of enc,
and then use that KEM in decryption attempt. Otherwise the recipient
MUST fail decryption.
In case there is only a single supported KEM consistent with the
private key and the length of enc, then this could be implemented by
first computing the sole candidate and then verifying the kem field
is either absent or contains the guessed value. In case there is none,
an implementation can immediately fail, as decryption is not possible.
Rationale: This structure is not safely extensible and there are
3 mandatory parameters and one optional one.
No current recipient is able to deal with any extensions, so future
extensions can be accomodiated by having "hpke2" that uses
COSE_HPKE_Sender_v2 structure.
The kem field is only needed in the unlikely case that the recipient
can not guess the KEM based on the private key and length of enc.
Note that even if compact NIST curves get added and recipient operates
on generic long-term EC2 keys, the length of enc still allows
correctly guessing the KEM (e.g., for P-256 key, 32 byte enc means it
is CP-256, 65 byte enc means it is is KEM 16).
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
