I see that the discussion has been going on while I was away.
The following are my thoughts after seeing the opinions on this thread:
I thought it was not a bad idea to put mode info in alg. I agree with this
idea. I don't understand Ilari's concern but at least, if the mode
information can be included in the alg, the message size will be smaller.
I also agree with the idea that HPKE version information can be included in
alg whether implicitly ("HPKE-BASE") or explicitly ("HPKEv1-BASE"). In
HPKE, an encrypted message does not contain the version information and the
recipient needs to know it in advance to decrypt it. However, that doesn't
mean we need to include the version information in the COSE message to be
sent.
If we decide to include the mode and version information in alg, the HSI
(HPKE Sender Information) no longer requires extendability. It appears that
the array is better.
However,
> It is COSE_HPKE_Sender only for alg=hpke, otherwise it is some bstr,
array or dictionary.
I cannot agree with this polymorphic approach. Again, it would be better to
define it specifically as "HPKE Sender Information", not abstracted
"encapsulated key info" that can take bstr and whatnot.
In terms of Laurence's proposal, I believe that Irari's proposal is
superior for the following reasons:
- The message size of Laurence's proposal is bigger than that of the sender
array.
- As I mentioned before, I don't think it is a good idea to have multiple
pieces of information that need to be used together separated into
different header values.
- It consumes 4 first class (<24) header values only for HPKE.
- The advantage in terms of the object code size is unclear.
Regards,
Daisuke
2022年11月29日(火) 18:26 Hannes Tschofenig <[email protected]>:
> Hi Stephen,
>
> > (Aside: I'm surprised how much discussion use of HPKE has caused here
> and wonder two things: 1) how that's going to be brought to a close? and 2)
> what's the underlying cause that's made the discussion tricky?)
>
> I was surprised too. How can the use of a cryptographic algorithm lead to
> so much excitement?
>
> My approach was to document the different proposals as PRs and then have
> the group to decide what they prefer.
> It turns out that the approaches so far are somewhat similar. That's good.
>
> On the negative side, new design ideas keep showing up and hence I have
> been trying to understand the use cases motivating them.
>
> 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
