On Mon, Mar 18, 2024 at 10:09:01AM +1000, Orie Steele wrote: > I agree with comments from illari and Lawrence on scenarios where headers > have no algorithm... I think a few spanning use cases will make the enc > structure proposals easier to consider. > > A case that uses the apu/apv... A case that has no algorithms in headers.
I do not think it is possible to use apu/apv in a way that is both safe and interoperable. And headers always have an algorithm, it is just that it might not be in protected bucket. And also that the topmost layer (content encryption) has nothing above it. > I don't find the size arguments compelling since any context that includes > a protected header will have to handle variable length. There are two arguments about size: - If binding across layers, applications need to keep upper layer headers in memory. This can be very significant amount of memory. (Applications also must form the upper layer headers beforehand, which can be extremely problematic.) - Protected headers need to fit into whatever field limit, so things might not work if field limit is small (e.g., 64 bytes). > I do find the generalized depth and next algorithm proposal interesting, > but possibly overkill for COSE HPKE... But maybe a good general purpose > solution for COSE. COSE already does limited form of depth with four cases: 1) COSE_Encrypt0 2) Depth 0 3) Depth 1 4) Depth 2 and below. And I have no sensible usecase for the fourth one. All the sensible structures I can come up with fall into following categories: 1) L0 only (e.g., symmetric encryption) 2) L1 push (e.g., Direct Key Agreement) 3) L1 pull (e.g., Key Transport) 4) L1 pull, L2 push (e.g., decomposed Key Agreement with Key Wrap) The first two are inherently single-recipient, the last two may be multi-recpient (for comparison, JWE only supports the second and third: JWE logically performs Direct Encryption as key push). The reason why COSE does not have next algorithm is that it assumes that all content encryption (and key wrap) algorithms are authenticated. However, it did not explicitly write down that requirement (for comparison JWE does explicitly require AEAD content encryption), and then somebody added one that is not, and broke things. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
