Inline: On Tue, Oct 4, 2022 at 10:17 AM Maik Riechert <[email protected]> wrote:
> The repo you linked to uses JWP, which is a new proposed envelope format. > That’s exactly what we’re discussing here: use a new custom format, or > represent it as signature algorithm. > > > I don't understand why either is needed. Your CDDL proposal below doesn’t work. The TBS of the signature value below > is over Countersign_structure. But what we need is the TBS to be the Merkle > tree root. > Is it not possible to put the merkle root in the Countersign_structure (protected header) ? > And that can be achieved by nesting the actual signature within an outer > “meta”-signature through a custom signature algorithm that would know how > to verify that structure using additional information like the Merkle tree > path. > > > Where does the "Merkle tree path" go? This sounds like a hint to a verifier about how to interpret the "Countersign_structure" header claims... which I assume would be signalled in the protected section of the Countersign_structure. It reminds me of "crit".. https://www.rfc-editor.org/rfc/rfc7515.html#section-4.1.11 > The "crit" (critical) Header Parameter indicates that extensions to > this specification and/or [JWA] are being used that MUST be > understood and processed. See it in use: https://www.rfc-editor.org/rfc/rfc7797#section-6 > I’d like to call attention again to Russ’ message just so we don’t loose > sight of it: > > > 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. > Certainly we could create new registry entries for this, mapping from: https://www.iana.org/assignments/cose/cose.xhtml For all signature algorithms, and all merkle proof encoding algorithms (only SCITT-CCF proposed today) , let a new registry entry be: MERKLE_PROOF_FORMAT + - + SIGNATURE_ALG. ^ Is this the proposal? > > > > > *From:* Orie Steele <[email protected]> > *Sent:* Dienstag, 4. Oktober 2022 16:06 > *To:* Maik Riechert <[email protected]> > *Cc:* Mike Prorock <[email protected]>; Russ Housley <[email protected]>; > [email protected]; cose <[email protected]> > *Subject:* Re: [EXTERNAL] Re: [COSE] SCITT receipts as COSE V2 > countersignatures > > > > > > [ > / 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. > *"merkle_alg" : SCITT-CCF,* > *"merkle_root": "merkle_root".* > } >>, > / unprotected / { > / kid / 4: "[email protected]" > > *"merkle_receipt": "path from the original leaf (original > COSE Sign1) to the merkle root... encoded in CBOR".* > }, > / signature / h'01B1291B...' > ] > }, > / payload / 'This is the content.', <-- For example SPDX SBOM. > / signature / h'BB...' > ] > > I've tested this and it works with JOSE, for example: > > > https://github.com/w3c-ccg/Merkle-Disclosure-2021/tree/main/packages/json-web-proof/ref-impl > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c-ccg%2FMerkle-Disclosure-2021%2Ftree%2Fmain%2Fpackages%2Fjson-web-proof%2Fref-impl&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd140befa48ab4a42009f08daa619ea80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004928424261188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=l8hLkA8xfvdQ39hmbfQ2RQKmCuvZfnQaHWpJi0zqzMQ%3D&reserved=0> > > ^ This package uses a "signed merkel root" + "merkle receipts" to create a > selective disclosure scheme, where a prover can prove a message is in a > merkle root that was signed by an issuer. > > In your construction, I don't think we care to support selective > disclosure, and the counter sign issuer is the one who signs over the root, > the original issuer is part of the COSE Sign1 that becomes the leaf. > > Maybe I am not understanding the objective. > > I don't understand what a "ledger transaction" looks like... is that a > "merkle receipt" (a proof of leaf inclusion in a merkle root) ? > > Regards, > > OS > > > > On Tue, Oct 4, 2022 at 9:54 AM Maik Riechert <[email protected]> > wrote: > > No, this wouldn’t work, as this would assume that each ledger transaction > is signed individually. The signature is over the Merkle tree root. And > only the extra information binds it to the actual leaf we care about (the > original COSE envelope plus the countersigner protected header). > > > > *From:* Orie Steele <[email protected]> > *Sent:* Dienstag, 4. Oktober 2022 15:21 > *To:* Maik Riechert <[email protected]> > *Cc:* Mike Prorock <[email protected]>; Russ Housley <[email protected]>; > [email protected]; cose <[email protected]> > *Subject:* Re: [EXTERNAL] Re: [COSE] SCITT receipts as COSE V2 > countersignatures > > > > Looking at the examples: > > > https://datatracker.ietf.org/doc/html/draft-ietf-cose-countersign#appendix-A.2.1 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-cose-countersign%23appendix-A.2.1&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd140befa48ab4a42009f08daa619ea80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004928424261188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=S%2BFpQKHrfKd3EyF8G%2FcSTX9JqAd3aR3F4hUFa9vJ7dI%3D&reserved=0> > > [ > / 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 > <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%7Cd140befa48ab4a42009f08daa619ea80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004928424261188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=5Ug%2FZHxoe0AI3HCe79bgrX2AF1ROUO%2BOPywQcp2qKqg%3D&reserved=0> > . > > > > *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%7Cd140befa48ab4a42009f08daa619ea80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004928424261188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=HmJEMgXv4X7kDT9aTUJHRizQOMr1FLS8nmrKuFUe0GE%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%7Cd140befa48ab4a42009f08daa619ea80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004928424261188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=oMAUktjjw0u7ylUne7aB0vfpW1cEIbB%2Bly0eF7Y%2Bjuo%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%7Cd140befa48ab4a42009f08daa619ea80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004928424261188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=5Ug%2FZHxoe0AI3HCe79bgrX2AF1ROUO%2BOPywQcp2qKqg%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%7Cd140befa48ab4a42009f08daa619ea80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004928424261188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=RFaWof%2BcLR9PQjk48Ph2xq%2B7Hrfk21rG42RX0qIdMv4%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%7Cd140befa48ab4a42009f08daa619ea80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004928424261188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=xIWYxTW6OzhQPFOESBUfaYZl1G2i9Oiszez5jGVdZQU%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%7Cd140befa48ab4a42009f08daa619ea80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004928424417430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=tKJSuRyPOpBQoM1sFBRPJSGHwG9FrStXFDGHZjaqIwE%3D&reserved=0> > > > > > -- > > *ORIE STEELE* > > Chief Technical Officer > > www.transmute.industries > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd140befa48ab4a42009f08daa619ea80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004928424417430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=74Jwr29wD19XifD%2FEqF4n5tF0IwtK0PnGTZB2dR%2BG80%3D&reserved=0> > > > > > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd140befa48ab4a42009f08daa619ea80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004928424417430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=RvHcLy35IbQPmPW5ovwvVdiDVvcBrG6qc%2Fy42uXJqLQ%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%7Cd140befa48ab4a42009f08daa619ea80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004928424417430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=tKJSuRyPOpBQoM1sFBRPJSGHwG9FrStXFDGHZjaqIwE%3D&reserved=0> > > > > > -- > > *ORIE STEELE* > > Chief Technical Officer > > www.transmute.industries > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd140befa48ab4a42009f08daa619ea80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004928424417430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=74Jwr29wD19XifD%2FEqF4n5tF0IwtK0PnGTZB2dR%2BG80%3D&reserved=0> > > > > > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd140befa48ab4a42009f08daa619ea80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004928424417430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=RvHcLy35IbQPmPW5ovwvVdiDVvcBrG6qc%2Fy42uXJqLQ%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%7Cd140befa48ab4a42009f08daa619ea80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004928424417430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=RvHcLy35IbQPmPW5ovwvVdiDVvcBrG6qc%2Fy42uXJqLQ%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
