Hi all, I took some time to do a second implementation of this draft, and confirm the draft is compatible with tiled transparency logs, as described here:
https://research.swtch.com/tlog I also had some conversations with the folks in the transparency dev ( https://transparency.dev/) slack about compatibility with sigsum / trillian logs, and the proof formats we define in COSE. TLDR; I think what we have is ready for publication, but I am second guessing that last MUST conversation regarding attached payloads in consistency proofs. I was able to make my implementation support detached payload consistency proofs, where you must recompute the new tree root before verifying the consistency proof, as we discussed previously, this is smaller and safer, and ... it can be symmetric to inclusion proofs. Here are a few EDN examples my implementation generates for the relevant cases: A SCITT Transparent Signed Statement with Multiple Receipts (from different software notaries): / cose-sign1 / 18([ / protected / <<{ / key / 4 : "vCl7UcS0ZZY99VpRthDc-0iUjLdfLtnmFqLJ2-Tt8N4", / algorithm / 1 : -7, # ES256 / hash / -6800 : -16, # SHA-256 / content / -6802 : "application/spdx+json", / location / -6801 : "https://cloud.example/sbom/42", / claims / 15 : { / issuer / 1 : "https://green.example", / subject / 2 : "https://green.example/[email protected]", }, }>>, / unprotected / { / receipts / 394 : { <</ cose-sign1 / 18([ / protected / <<{ / key / 4 : "mxA4KiOkQFZ-dkLebSo3mLOEPR7rN8XtxkJe45xuyJk", / algorithm / 1 : -7, # ES256 / notary / 395 : 1, # RFC9162 SHA-256 / claims / 15 : { / issuer / 1 : "https://blue.example", / subject / 2 : "https://green.example/[email protected]", }, }>>, / unprotected / { / proofs / 396 : { / inclusion / -1 : [ <<[ / size / 9, / leaf / 8, / inclusion path / h'7558a95f...e02e35d6' ]>> ], }, }, / payload / null, / signature / h'02d227ed...ccd3774f' ])>>, <</ cose-sign1 / 18([ / protected / <<{ / key / 4 : "ajOkeBTJou_wPrlExLMw7L9OTCD5ZIOBYc-O6LESe9c", / algorithm / 1 : -7, # ES256 / notary / 395 : 1, # RFC9162 SHA-256 / claims / 15 : { / issuer / 1 : "https://orange.example", / subject / 2 : "https://green.example/[email protected]", }, }>>, / unprotected / { / proofs / 396 : { / inclusion / -1 : [ <<[ / size / 6, / leaf / 5, / inclusion path / h'9352f974...4ffa7ce0', h'54806f32...f007ea06' ]>> ], }, }, / payload / null, / signature / h'36581f38...a5581960' ])>> }, }, / payload / h'0167c57c...deeed6d4', / signature / h'2544f2ed...5840893b' ]) A signed inclusion proof: / cose-sign1 / 18([ / protected / <<{ / algorithm / 1 : -7, # ES256 / notary / 395 : 1, # RFC9162 SHA-256 }>>, / unprotected / { / proofs / 396 : { / inclusion / -1 : [ <<[ / size / 20, / leaf / 17, / inclusion path / h'fc9f050f...221c92cb', h'bd0136ad...6b28cf21', h'd68af9d6...93b1632b' ]>> ], }, }, / payload / null, / signature / h'de24f0cc...9a5ade89' ]) A signed consistency proof: / cose-sign1 / 18([ / protected / <<{ / algorithm / 1 : -7, # ES256 / notary / 395 : 1, # RFC9162 SHA-256 }>>, / unprotected / { / proofs / 396 : { / consistency / -2 : [ <<[ / old / 20, / new / 104, / consistency path / h'e5b3e764...c4a813bc', h'87e8a084...4f529f69', h'f712f76d...92a0ff36', h'd68af9d6...93b1632b', h'249efab6...b7614ccd', h'85dd6293...38914dc1' ]>> ], }, }, / payload / null, / signature / h'94469f73...52de67a1' ]) The diagnostic notation I generate is flavored for what I wanted to show, and the labels are generated from the iana registry values, but customized to match my preferences (they are not exact matches for the registry labels). I also had to account for drafts requesting registrations which are not yet present for cose-receipts and cose-hash-envelop. Regards, OS On Wed, Sep 25, 2024 at 1:52 AM Felix Linker <[email protected]> wrote: > The draft is ready for publication. > > Felix > > On 24 Sep 2024, at 15:31, Michael Prorock <[email protected]> wrote: > > I believe this is ready for publication. > > Mike Prorock > > > On Mon, Sep 23, 2024 at 3:16 PM Michael Jones <[email protected]> > wrote: > >> Hi all, >> >> This message starts the Working Group Last Call (WGLC) for >> https://www.ietf.org/archive/id/draft-ietf-cose-merkle-tree-proofs-05.html. >> The editors believe that they have addressed the remaining open issues. >> The WGLC will run for two weeks, ending on Monday, October 7, 2024. >> >> Please review and send any comments or feedback to the working group. >> Even if your feedback is “this is ready for publication”, please let us >> know. >> >> Thank you, >> >> -- Mike and Ivaylo, COSE >> Chairs >> >> >> _______________________________________________ >> COSE mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
