Orie, sure, that can be done by moving the base alg in the signature structure, similar to the referenced RFC. Then alg would be "SCITT-CCF", and for non-CCF implementations it may be another custom alg or an existing alg (e.g., "ES256" if every COSE envelope is countersigned individually, rather than signing a Merkle tree root periodically).
Note that "cty" doesn't exist for COSE countersignatures, since there is no payload of the countersigner. Instead, any metadata from the countersigner would be part of the protected header. See also https://datatracker.ietf.org/doc/html/draft-ietf-cose-countersign. From: Mike Prorock <[email protected]> Sent: Dienstag, 4. Oktober 2022 14:48 To: Orie Steele <[email protected]> Cc: Russ Housley <[email protected]>; Maik Riechert <[email protected]>; [email protected]; cose <[email protected]> Subject: [EXTERNAL] Re: [COSE] SCITT receipts as COSE V2 countersignatures Likewise I am with Orie on this one cty or similar would make things a whole lot cleaner for Interop reasons and prevents a lot of potential confusion and complexity Mike Prorock mesur.io<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmesur.io%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cbf0bfc3db17245beb81d08daa60f0755%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004880764233003%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2j2a0cLWXgDtXiN1SAsnX8uZvMxOj5jTiZn08Ah1dN8%3D&reserved=0> On Tue, Oct 4, 2022, 07:01 Orie Steele <[email protected]<mailto:[email protected]>> wrote: I'm a -1 to needing to register a new alg for every existing registered alg when used with counter signatures... specifically: - SCITT-CCF-ES256 - SCITT-CCF-EdDSA - SCITT-CCF-ES384 - SCITT-CCF-FANCY_NEW_PQC_1 - SCITT-CCF-FANCY_NEW_PQC_2 - SCITT-CCF-FANCY_NEW_PQC_3 Can we move the "application specific" component of the "alg" value to a separate field? Example: alg: ES256 // support existing alg values with no changes cty: 'application/scitt-ccf' // signal the content type ? Regards, OS On Tue, Oct 4, 2022 at 7:44 AM Russ Housley <[email protected]<mailto:[email protected]>> wrote: If I understand this proposal correctly, a value for SCITT-CCF-ES256 would be added to the IANA-maintained COSE Algorithms registry. Right now, all of the entries are for cryptographic algorithms. I'd like to hear what the Designated Experts think about using the registry to identify an application-specific structure in addition to the cryptographic algorithm. Russ On Oct 4, 2022, at 8:00 AM, Maik Riechert <[email protected]<mailto:[email protected]>> wrote: Hi all, In the SCITT community call yesterday we had a discussion on receipts (https://datatracker.ietf.org/doc/html/draft-birkholz-scitt-receipts-01<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-birkholz-scitt-receipts-01&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cbf0bfc3db17245beb81d08daa60f0755%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004880764233003%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OW%2BkxRRTU3MqPKUinuwr3GAiK%2BETPa4k3u2iMjrk45I%3D&reserved=0>) and whether they should be represented as standard COSE V2 countersignatures (https://datatracker.ietf.org/doc/html/draft-ietf-cose-countersign<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-cose-countersign&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cbf0bfc3db17245beb81d08daa60f0755%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004880764389227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BjkQmItOaUSym3rxyLEjPPwcG%2BdtlRIDDIGfx5myFyo%3D&reserved=0>). The current receipt format's CDDL is as follows: [ service_id: tstr contents: any ] where `contents` depends on the "tree" algorithm (with the requirement that it has to contain a protected header somewhere in it) identified via parameters associated to the service_id. Currently there is only a single tree algorithm (based on a CCF ledger implementation) where the CDDL is as follows: [ signature: bstr node_certificate: bstr inclusion_proof: [+ ProofElement] leaf_info: [ internal_hash: bstr internal_data: bstr protected: bstr .cbor { issuedAt: uint } ] ] In order to support more schemes around key discovery (e.g., DID), it makes sense to move the protected header to the front and make it part of the common top-level structure: [ protected: bstr .cbor { service_id: tstr issuedAt: uint }, contents: any ] The new `contents` would then look like this: [ signature: bstr node_certificate: bstr inclusion_proof: [+ ProofElement] leaf_info: [ internal_hash: bstr internal_data: bstr ] ] If you then squint a bit more, you can re-imagine this as a COSE V2 countersignature: [ protected: bstr .cbor { alg: tstr service_id: tstr issuedAt: uint }, unprotected: { * label => values } signature: bstr ] For the CCF tree algorithm, this would equate to `alg` being a new identifier (e.g., "SCITT-CCF-ES256") and the signature being the `contents` structure wrapped as bstr. Russ raised concerns that carrying all of the additional bits in the signature bytes may be hard to justify when it comes to registration of the new signature algorithm in COSE's IANA registry. There seems to be precedent though, for example https://datatracker.ietf.org/doc/html/rfc8778<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8778&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cbf0bfc3db17245beb81d08daa60f0755%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004880764389227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FCUKRp6jkaVkS8IYqrA024aE5H9rZMnkIzBdJvjTsTs%3D&reserved=0> where for Leighton-Micali the signature value (see 2.2) is a structure containing a leaf number, an LM-OTS signature, a type code indicating a subalgorithm, and a tree path from leaf to root. We discussed two alternatives: 1. Keeping it a separate format specific to SCITT. 2. Establishing receipts as new COSE message type, though this may be more challenging. Any discussions and opinions on this topic are highly appreciated. Maik _______________________________________________ COSE mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/cose<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcose&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cbf0bfc3db17245beb81d08daa60f0755%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004880764389227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1Z1HKY7%2FERQ8tuJLUVdrJCPibGPUUPvxLoj4hV87qc8%3D&reserved=0> _______________________________________________ COSE mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/cose<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcose&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cbf0bfc3db17245beb81d08daa60f0755%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004880764389227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1Z1HKY7%2FERQ8tuJLUVdrJCPibGPUUPvxLoj4hV87qc8%3D&reserved=0> -- ORIE STEELE Chief Technical Officer www.transmute.industries<http://www.transmute.industries> [https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cbf0bfc3db17245beb81d08daa60f0755%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004880764389227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ow1eVvpwvaCxusMXBuFLRQkLaQs8EwO3MN4XRgGRFTI%3D&reserved=0> _______________________________________________ COSE mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/cose<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcose&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cbf0bfc3db17245beb81d08daa60f0755%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004880764389227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1Z1HKY7%2FERQ8tuJLUVdrJCPibGPUUPvxLoj4hV87qc8%3D&reserved=0>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
