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]
