> > (HPKE is both bulk and aad capable, so it is its own class in COSE, > not Key Transport class. This also gives it correct properties w.r.t. > sections 5.3 and 5.4.)
Under the premise of prohibiting the use of AE algs at layer0 and using HPKE algs for key wrapping at layer1, should we really introduce next_alg? I just want to understand the reason correctly. Daisuke 2024年3月19日(火) 4:03 Ilari Liusvaara <[email protected]>: > On Mon, Mar 18, 2024 at 05:31:34PM +0000, lgl island-resort.com wrote: > > > > On Mar 18, 2024, at 6:05 AM, AJITOMI Daisuke <[email protected]> wrote: > > > > What I think should be done is to prohibit using non-authenticated > > content encryption and key wrap algorithms in COSE. > > > > I agree. In the COSE-HPKE draft, we should stop supporting legacy > > non-AEADs and offer the simplest and safest solution. > > > > Even if the WG agrees to prohibit non-AEADs, I think we should get rid > > of COSE_KDF_Context and should authenticate the algorithm ID across > > layers with a new Enc_structure. > > RFC9052 explicitly defines both AE (section 5.4) and AEAD (section 5.3) > ciphers. What is obviously intended is that all symmetric ciphers are > authenticated. > > This causes really nasty issues with algorithm binding: > > AE algorithms have no Enc_structure, making it difficult to bind the > algorithms. Worse, all the pre-composed KAwKW algorithms are AE. > > Then to make matters even more complicated, Key Transport class is > not aad capable. That also causes major issues with binding. > > (HPKE is both bulk and aad capable, so it is its own class in COSE, > not Key Transport class. This also gives it correct properties w.r.t. > sections 5.3 and 5.4.) > > > > > -Ilari > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
