> In that sense, COSE ensures validity in the moment, while REM ensures > persistence beyond the moment
I'd also consider the scitt arch (scitt wg), and in particular its definition of a statement sequence - https://ietf-wg-scitt.github.io/draft-ietf-scitt-architecture/draft-ietf-scitt-architecture.html#name-terminology. That views "append only logs" as a way to address that And of course there is this project - https://github.com/google/trillian I understand the idea behind using a blockchain as a clock, I'm not arguing that either way. just pointing at recent work I'm aware of that seems related On Tue, 23 Sept 2025 at 15:31, lawrence reilly <[email protected]> wrote: > > Hi Robin, > > Thank you for pointing me to the COSE drafts, I’ve started reviewing them and > I can see where they intersect with my work. > > From my perspective, COSE and REM address different but complementary layers: > > COSE provides cryptographic proof of authenticity and integrity at the time > of creation (signatures, Merkle proofs, receipts). > > REM focuses on dual-layer permanence, anchoring artifacts through DOI > assignment and blockchain timestamping so that, once created and verified, > they remain immutable, citable, and discoverable over the long term. > > In that sense, COSE ensures validity in the moment, while REM ensures > persistence beyond the moment. Together, they reinforce one another: COSE > provides the proof structure, and REM preserves the proof itself so it can’t > be lost or erased with time. > > I’d be glad to explore how REM’s permanence layer could align with or extend > the COSE receipts work. > > Best regards, > Lawrence Reilly > > On Tue, Sep 23, 2025, 10:20 AM Robin Bryce <[email protected]> wrote: >> >> Hi Lawrence, >> >> If you haven't found them already, these ID's are pretty active and >> you will likely find some common interest with at least some of the >> collaborators: >> >> * https://datatracker.ietf.org/doc/draft-ietf-cose-merkle-tree-proofs/ >> >> And two draft profiles >> * https://datatracker.ietf.org/doc/draft-birkholz-cose-receipts-ccf-profile/ >> * https://datatracker.ietf.org/doc/draft-bryce-cose-receipts-mmr-profile/ >> >> On Mon, 22 Sept 2025 at 18:37, lawrence reilly >> <[email protected]> wrote: >> > >> > Hi Michael, >> > >> > Thank you for taking the time to share such detailed feedback and >> > references. I appreciate the context on LTANS, SCITT WG, and the existing >> > IEC/ISO work around time-stamping services. I’ll review those links more >> > closely to better understand the prior art and fit. >> > >> > My motivation with the REM Protocol is not to portray blockchain as >> > “magical,” but rather to explore how existing constructs (DOIs, hashes, >> > TXIDs) can be formally packaged and archived with long-term verifiability. >> > I see blockchain timestamping as one component, alongside notaries and >> > receipts, rather than a wholesale replacement for established trust models. >> > >> > Your point about CPU cycles and practical verification is well-taken. >> > That’s why I’m experimenting with layered proofs (DOI + hash + TXID) to >> > minimize reliance on any single ledger or entity. My aim is to complement, >> > not duplicate, existing timestamping solutions, while leaving an open door >> > for interoperability via COSE/CBOR formats. >> > >> > I’ll dig further into LTANS and SCITT, but your note helps me clarify the >> > scope: REM may have a role in bridging scholarly/archival artifacts with >> > trusted time-stamping models already in play. >> > >> > Thanks again for pointing me in the right direction. Any additional >> > guidance on where discussions of archival permanence + receipts would be >> > most welcome would be greatly appreciated. >> > >> > Thanks again, >> > Lawrence Reilly >> > >> > >> > On Mon, Sep 22, 2025, 1:30 PM Michael Richardson <[email protected]> >> > wrote: >> >> >> >> >> >> lawrence reilly <[email protected]> wrote: >> >> > Would you suggest an alternative working group or area within IETF >> >> that >> >> > might be a better fit for this draft? I’d like to make sure I’m >> >> > engaging with the right forum for further discussion and refinement. >> >> >> >> I think you should find an organization who believes proof-of-work >> >> blockchain >> >> has some ethical purpose. >> >> >> >> Even if changed to a shared-ledger (like Hyperledger), time-stamp >> >> services >> >> do not generally involve mutually suspicious entities with sufficient >> >> interest to spend the cpu cycles to verify the ledger. I don't think >> >> anyone >> >> wouldr spend the cpu cycles to download gigabytes of data, and verify >> >> a block chain in order to be sure some code-signature was time-stamped >> >> correctly before applying the patch. >> >> >> >> So it reduces to an entity running the time-stamping service, which singly >> >> rooted systems such as described 20 years ago at >> >> https://datatracker.ietf.org/wg/ltans/documents/ >> >> would apply. Such services exist today (I see Entrust, Sectigo, Adacom >> >> with >> >> a trivial search). IEC/ISO did some work more recently. >> >> So, you want COSE/CBOR format for receipts, then I'd start from LTANS, >> >> and you'll need at least two notaries to partipate. >> >> Here at the IETF, the SCITT WG might be interested, but I seem to think >> >> that >> >> they already have a solution. >> >> >> >> I understand that many people think that blockchain is magical, without >> >> cost, >> >> and will "free" you from having to make busiess relationships. >> >> I also want a unicorn. >> >> >> >> -- >> >> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) >> >> Sandelman Software Works Inc, Ottawa and Worldwide >> > >> > _______________________________________________ >> > 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]
