On Wed, Oct 05, 2022 at 08:16:44AM +0000, Hannes Tschofenig wrote:
> Hi all,
>
> I have prepared a PR:
> https://github.com/cose-wg/HPKE/pull/9
>
> Please let me know what you think.
>
Some quick comments:
- Why the optional KEM field in the message structure? The recipient
has to be able to dig the KEM from the private key anyway.
One situation where having KEM id in message could be useful would be
if recipient supports both P-* and CP-* with COSE_Key EC2 private key.
Altough that is not absolutely mandatory, as one can successfully
tiebreak using ek length.
(When decrypting with P-* and CP-* KEMs using EC2 private key, taking
d value as byte string from key and stuffing it raw into HPKE private
key input should work. With future CP-* KEMs, doing similar thing with
x value when encrypting should also work).
- Not concatenating KDF and AEAD would likely save a bit of space.
The concatenated form takes 6 bytes, but split form would likely
take 4.
+ There is no AEAD 0, so the composite id is pushed to 32 bit
range. And encoding 32 bit integer takes 5 bytes. Plus there is
the key byte for total of 6.
+ Whereas presently assigned AEAD and KEM ids are in the 4.5
bit range, which takes 1 byte to encode. Two of those plus
two key bytes for total of 4.
- I do not see the reason why the COSE HPKE Sender Parameter Registry
is defined.
It seems to me that any possible extension has to be incompatible
(the present structure seems to be enough to completely use the
HPKE base mode).
Such incompatible extensions can not be ignored: The decryption
will fail. Therefore such extensions should presumably have their
own alg values, with redefined context structure.
- I do not see a way to generically represent long-term HPKE
keys.
Two ways this could be done:
+ Define new HPKE kty, with fields:
* kem (integer)
* priv (bstr)
* pub (bstr)
+ Reserve 16-bit aligned range from positive 32-bit elliptic
curve identifiers to HPKE, and then use that with OKP.
E.g., range 1212481536 to 1212547071 inclusive (0x48450000
to 0x4845FFFF, 0x4845 is "HE").
Then if HPKE defines say KEM 0x0030, keys for that can be
represented as OKP keys with curve 1212481584.
- I think having compact NIST curves in HPKE is such importance (saving
quite a bit of space) that COSE-HPKE specification should attempt to
register those (dropping the registrations if someone else does that
first).
Some draft text for IANA considerations:
HPKE KEM DHKEM(CP-256, HKDF-SHA256):
* Value: TBD1
* KEM: DHKEM(CP-256, HKDF-SHA256)
* Nsecret: 32
* Nenc: 32
* Npk: 32
* Nsk: 32
* Auth: Yes
* Reference: [THIS]
DHKEM(CP-256, HKDF-SHA256) is like DHKEM(P-256, HKDF-SHA256)
except SerializePublicKey() returns the 32 octet big endian
serialization of the smallest nonnegative representative of the
x coordinate of the elliptic curve point. DeserializePrivateKey() is
the converse, with the tie broken in arbitrary way (both choices lead
to the same ultimate result).
[Note: This is identical to DHKEM(CP-256, HKDF-SHA256) from
draft-harkins-cfrg-dnhpke-02.]
HPKE KEM DHKEM(CP-384, HKDF-SHA384):
* Value: TBD2
* KEM: DHKEM(CP-384, HKDF-SHA384)
* Nsecret: 48
* Nenc: 48
* Npk: 48
* Nsk: 48
* Auth: Yes
* Reference: [THIS]
DHKEM(CP-384, HKDF-SHA384) is like DHKEM(P-384, HKDF-SHA384)
except SerializePublicKey() returns the 48 octet big endian
serialization of the smallest nonnegative representative of the
x coordinate of the elliptic curve point. DeserializePrivateKey() is
the converse, with the tie broken in arbitrary way (both choices lead
to the same ultimate result).
[Note: This is identical to DHKEM(CP-384, HKDF-SHA384) from
draft-harkins-cfrg-dnhpke-02.]
HPKE KEM DHKEM(CP-521, HKDF-SHA512):
* Value: TBD3
* KEM: DHKEM(CP-521, HKDF-SHA512)
* Nsecret: 66
* Nenc: 66
* Npk: 66
* Nsk: 66
* Auth: Yes
* Reference: [THIS]
DHKEM(CP-521, HKDF-SHA512) is like DHKEM(P-521, HKDF-SHA512)
except SerializePublicKey() returns the 66 octet big endian
serialization of the smallest nonnegative representative of the
x coordinate of the elliptic curve point. DeserializePrivateKey() is
the converse, with the tie broken in arbitrary way (both choices lead
to the same ultimate result).
[Note: This is identical to DHKEM(CP-521, HKDF-SHA512) from
draft-harkins-cfrg-dnhpke-02.]
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
