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?
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 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).
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.
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.
- 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.
```
Best regards,
Daisuke
2022年10月31日(月) 20:30 Hannes Tschofenig <[email protected]>:
> Hi Ilari,
>
> I updated the PR based on your feedback.
>
> I still have a few question regarding the processing rules. I wonder
> whether this procedure introduces fragility just for a very small byte
> saving (namely saving the kem id value).
> It also makes the implementations more difficult since multiple cases have
> to be considered.
>
> ~snip~
>
> > * you introduce rules for processing that are dependent upon the
> > presence/absence of the kem field. You are asking the developer to
> > determine whether "the KEM is consistent with the private key".
> >
> > I fear that this rule is too loose to understand. We will have to
> > specify what "consistent" means i.e. what checks a developer is
> > supposed to make. This also changes the text that is currently in the
> > draft, which says that the kem is optional one the value of this field
> > is inferred already by the key identifier.
>
> This processing is already needed, it is just left unspecified. And my
> wording was apparently very poor.
>
>
> The question is, what does your implementation do if it receives:
>
> a) A message with no KEM, but there are multiple KEMs that all can
> be used with the private key and have Nenc = |enc|.
>
> I think it is reasonable to fail to decrypt.
>
> b) A message with no KEM, there are multiple KEMs that all can be
> used with the private key, but only one has Nenc = |enc|.
>
> I think it is reasonable to attempt decryption with the one
> KEM.
>
> (checking for Nenc = |enc| is needed in case both compact and
> uncompressed curves are supported with the same private key.)
>
> c) A message with KEM that can not be used with the private key.
>
> I think it is reasonable to fail to decrypt.
>
> (If the KEM can be used with private key, but Nenc != |enc|,
> then HPKE will fail anyway.)
>
>
> Ciao
> Hannes
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> _______________________________________________
> COSE mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/cose
>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
