Ilari, just to summarize, your suggestion is that if we must use existing COSE structures with a new signature algorithm, then this is only acceptable if the signature structure and verification algorithm is sufficiently simplified such that it counts as generic and not application-specific. In this case, root-type metadata would still be part of the leaf data. Is that correct?
I think at this point we have to make a decision whether having a single generic format is feasible or not. At the moment I'm not too optimistic that this will work and I probably would prefer a custom structure (not standard COSE) instead. -----Original Message----- From: SCITT <[email protected]> On Behalf Of Ilari Liusvaara Sent: Donnerstag, 6. Oktober 2022 16:26 To: [email protected]; [email protected] Subject: Re: [SCITT] [EXTERNAL] Re: [COSE] SCITT receipts as COSE V2 countersignatures [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] On Wed, Oct 05, 2022 at 02:21:37PM +0000, Maik Riechert wrote: > Let me address your points in a question/answer style (hopefully > covering your points well enough). > > Q: Is this all application-specific? > In the current spec > (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .ietf.org%2Farchive%2Fid%2Fdraft-birkholz-scitt-receipts-01.html&d > ata=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd86e79ad67f246c0a4f408da > a7af1760%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6380066677455547 > 89%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI > 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mrWEDCQNXWJDVX1K%2Bo > XxMhNpF8PdOfSl6H06GX3swvc%3D&reserved=0) > we tried to have a minimal generic top-level structure (3.) and then > depending on the "tree algorithm" an inner application-specific / > tree-specific structure, currently with a single one defined to > support CCF-compatible implementations. > > Q: Is a COSE algorithm always a cryptographic primitive? > Likely. I'm assuming this is where some of the pushback comes from, as > we would regard SCITT-CCF-ES256 as a cryptographic primitive in that > sense, even though it is not. Well, if the intention is to map CCF into signature algorithm, a lot of pushback is coming from excess complexity making it application- specific. Specifically, the leaf stuff and node_certificate stuff in the signature. All the leaf stuff should be moved to signature protected headers and the node certificate should be moved to signature headers. Furthermore, node certificate should be simplified to COSE_Key in COSE_Sign1 instead of X.509, perhaps with some additional headers if needed. Then the signature encoding should be simplfied to dedicated binary encoding. E.g.: - 0 or more of: 01/02 <hash> - 00 to signal inclusion proof ends. - 64-bit leaf count. - root signature. And what the signature algorithm verification would do: - Hash the message with context A. - While reading 01/02, hash last hash and hash from signature inorder/reversed with context B. - Read the 00 and leaf count, and hash leaf count and last hash with context C. - Verify that root signature is valid signature for the last hash using the given key. Apart from leaf count (which is there to support consistency proofs), this is pretty much standard batch signature. And while leaf count is unnecressary for pure batch signatures, it is very cheap. -Ilari -- SCITT mailing list [email protected] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscitt&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd86e79ad67f246c0a4f408daa7af1760%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638006667745554789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4nShMZxfUBhkntM0kHoZ4kAggWIMkZRj9kkLu34tUbg%3D&reserved=0 _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
