On Tue, Nov 01, 2022 at 08:00:00PM +0900, AJITOMI Daisuke wrote:
> Hi Ilari and Hannes,
>
> Sorry, I finally checked all of Ilari's comments and proposals today.
>
> - Instead of registering hpke_sender to Common Header Parameters,
> > register encapsulated_key:
>
>
> Why is it necessary to define the encapsulated key (enc) independent
> of HPKE in this COSE-HPKE spec?
To avoid having to define new header later if some dedicated KEM (e.g.,
Kyber1024) gets added.
Note that for HPKE, the encapsulated key is always COSE_HPKE_Sender.
This does not add any complexity to COSE-HPKE implemenation.
> In the context of HPKE, enc should be bstr and nothing more. We should
> focus on the bstr encapsulated key in the context of HPKE.
In context of HPKE, one also needs to know the AEAD and KDF used (plus
KEM, if there are somehow multiple choices). Those could be carried
alongside HPKE enc, or mashed into the same bstr.
> In the Kyber case, we can consider only the Kyber mapped onto the HPKE
> framework, in which case enc would still be bstr (or the alternative might
> be to not use the enc field, assuming that enc is included in the
> ciphertext though).
Kyber mapped into HPKE framework is no different from any random KEM
mapped into HPKE framework.
However, there is possibility that Kyber will be added to COSE outside
HPKE framework.
> For algorithm HPKE, encapsulated key MUST be present in unprotected
> > bucket and its value SHALL be of type COSE_HPKE_Sender.
>
>
> Hmm..., it seems a bit odd to put the COSE_HPKE_Sender information into a
> generic encapsulated key attribute, given the fact that the encapsulated
> key itself is just one of the attributes of COSE_HPKE_Sender.
Like HPKE, some KEMs might require additional information, or have even
nontrivial ciphertext structure.
> Anyway, I believe that if you want to define generic encapsulated key
> information (for PQC? and so on), that you should make a separate I-D.
Any use for that header other than for HPKE will be separate I-D.
There are basically two choices for a new header for HPKE encapsulated
key:
1) Define header specific for HPKE. If there is future KEM outside HPKE,
it has to define a new header.
2) Define a generic header. HPKE uses it for COSE_HPKE_Sender structure,
the future KEM for another structure (bstr?).
There is no complexity difference for COSE-HPKE implementation. In both
cases, the implementation just sees a header that takes a fixed
structure.
> - COSE_HPKE_Sender could be simplified to:
>
>
> > COSE_HPKE_Sender = [
> > kdf: uint,
> > aead: uint,
> > enc: bstr,
> > ? kem: uint
> > ];
>
>
> I think this approach using the array type is also good, but I was going to
> suggest the following additions to the HPKE sender information as the next
> step of draft-03. Specifically, I was thinking of the need to specify the
> HPKE version information and support other HPKE modes other than Base mode
> in the long run.
>
> There are 3 optional attributes in this structure and I think it is not
> suitable to be represented as an array.
>
> ```
> COSE_HPKE_Sender = {
> ? 0 => uint, ; HPKE version (default: 1) *
> ? 1 => uint, ; kem id
> 2 => uint, ; kdf id
> 3 => uint, ; aead id
> 4 => bstr, ; enc
> ? 5 => bstr, ; sender public key (for Auth mode or AuthPSK
> mode) **
> }
>
> * Need to confirm the HPKE version can be expressed in uint.
> ** Need to discuss whether bstr or COSE_Key.
> ```
I don't think it is a good idea to speculate what next version of HPKE
(if there ever will be one) is like.
And including raw sender public key is rarely desirable. Mostly for
dynamic account registration, otherwise it tends to mostly just invite
nasty security bugs.
COSE has already a header for identifying sender key (static key id)
it also has header for sender key (static key), if one wants to use
that for some reason (it is long-term key, so it being COSE_Key is not
a problem).
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
