Hi Hannes,
Thanks for updating the draft to -04. It appears much improved to me. I'd
like to share a few comments.
* COSE_Encrypt => COSE_Encrypt/COSE_Mac
COSE-HPKE can be applied to not only COSE_Encrypt but also COSE_Mac for
the two layer structure. I think it would be better to include an
explanation about COSE_Mac ( and provide an example for COSE_Mac).
* Info
At the very least, until now, I believed that the `info` value for HPKE
should be an empty string. The reason is that HPKE interface used in COSE
is essentially the Single-shot API, and a single HPKE encryption context is
not used across multiple encryption/decryption processes. In other words,
`aad` alone is sufficient. As I mentioned before, RFC9180 Section 8.1 also
says "Implementations which only expose single-shot APIs should not allow
applications to use both Setup info and Context aad or exporter_context
auxiliary information parameters". I will also give it some more
consideration though.
* kid
Although I believe we have an option to make `kid` mandatory for
COSE-HPKE (many other standards(ECH, OHTTP, ODoH) using HPKE make key
identifiers mandatory), I can agree with Laurence opinion because I also
think that COSE should have flexibility to be able to reduce the message
size as much as possible. Honestly speaking, I don't know which is better.
Best regards,
AJITOMI Daisuke
2023年3月16日(木) 3:36 Laurence Lundblade <[email protected]>:
>
> On Mar 15, 2023, at 8:41 AM, <[email protected]> <
> [email protected]> wrote:
>
> The kid parameter is always optional in COSE. It shouldn’t be mandatory in
> 3.1.1 and 3.1.2. I think this is a mandatory change for this draft. Section
> 5.2 of 9052 even discourages use of kid in and Encrypt0:
>
>
> The COSE_Encrypt0 encrypted structure does not have the ability to specify
> recipients of the message. The structure assumes that the recipient of the
> object will already know the identity of the key to be used in order to
> decrypt the message. If a key needs to be identified to the recipient, the
> enveloped structure ought to be used.
>
>
> Key identification is something that COSE leaves up to the layers above as
> far as I can see. It should probably have been mentioned as one of the
> things a COSE profile should specify in section 10 of RFC 9052. I have
> found this a bit odd, particularly compared to CMS, but I can see the value
> in leaving it open.
>
> [Hannes] I can make the kid parameter optional.
>
> IMHO the advice in RFC 9052 regarding the kid is a bit strange. I don’t
> understand why there is no value in using some parameter, like the kid, to
> give the recipient a idea what they it should be using to decrypt the
> message. Of course, if it is available from the context then that’s fine
> but that this may not always be the case. Of course, having this discussion
> about RFC 9052 is not so useful and we have to look forward. If a profile
> needs the kid (or some other parameter) then they have to use it.
>
>
> It’s primary for smaller message size.
>
> UEID as the key identifier in EAT and Instance ID in PSA Attestation are
> examples with no kid.
>
> LL
>
> _______________________________________________
> COSE mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/cose
>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
