> On Nov 28, 2022, at 2:16 AM, Hannes Tschofenig <[email protected]> > wrote: > > Hi Daisuke, > > I am not happy about adding anything other than the base mode since it > duplicates functionality already available in COSE unless there is a good use > case for it. So far I have not seen this use case.
(replicated and improved from my post in other thread) Here’s a few reasons I can think of for supporting mode_auth. These are all for encryption + authentication. - Less bytes on the wire because you don’t need a COSE_Sign (probably only 10-30 less, but something) - Less CPU because of one-pass processing of the bulk payload (Just the AEAD, not an AEAD and a hash) (May not work out as an advantage for firmware because of characteristics related to the need for counter non-AEAD mode). - Simpler implementation and less code — no need to decode COSE_Sign or for ECDSA algorithm - Potentially a lot less memory because you might avoid a big intermediate payload buffer between the encryption and the hash - Lines up better for the HPKE crowd that really want to do HPKE for as much as possible - May line up better for algorithm and key selection for some use cases that are more HPKE oriented. Keys and algorithms are all HPKE, no need for ECDSA or EdDSA. - Seems like an incomplete integration of HPKE with COSE without it This could be in a separate draft, but we should at least anticipate how mode_auth is distinguished from mode_base. LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
