Looking at the examples:
https://datatracker.ietf.org/doc/html/draft-ietf-cose-countersign#appendix-A.2.1
[
/ protected h'A201260300' / << {
/ alg / 1:-7, / ECDSA 256 /
/ ctyp / 3:0 *<-- ... for example "application/spdx-sbom" *(not
currently a real ctyp)
} >>,
/ unprotected / {
/ kid / 4: "11",
/ countersign / 11: [
/ protected h'A1013823' / << {
/ alg / 1:-36 / ECDSA 512 /* <--- counter signature alg...
already reserved.*
...
*we could inject the merkle proof here as well.*
*"receipt_alg" : SCITT-CCF,* *"receipt": {}*
} >>,
/ unprotected / {
/ kid / 4: "[email protected]"
},
/ signature / h'01B1291B...'
]
},
/ payload / 'This is the content.',* <-- For example **SPDX SBOM.*
/ signature / h'BB...'
]
Does this match what you were saying above?
Regards,
OS
On Tue, Oct 4, 2022 at 8:56 AM Maik Riechert <[email protected]>
wrote:
> 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]> 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]> 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]> 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]
> 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
> <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
>
>
>
>
> <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]
> 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
<https://www.transmute.industries>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
