Cedulon Re-Attestation: Carrying Spend Evidence Across Algorithm Retirement

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 27 February 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

A Cedulon Spend Receipt is a COSE_Sign1 object [RFC9052] verified against a signature algorithm. When that algorithm is deprecated, verification of old evidence degrades from a cryptographic check into an act of faith. Archives that must answer questions many years later (regulators, insurers, courts, and historians of automated commerce) need a defined ceremony for carrying evidence forward, not an ad-hoc migration.¶

The proposal is deliberately narrow: re-attestation does not re-issue, amend, or reinterpret evidence. It states, under a successor algorithm, that specific original bytes existed and verified at a specific time, and it anchors that statement in an append-only transparency log.¶

This document is an extension seed for the Cedulon core specification [CEDULON]. It is not an IETF working-group item, its keyword usage is provisional, and the reference implementation does not yet implement it. It is published to define the shape of the mechanism early and to invite review.¶

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Original Evidence:

A COSE_Sign1 object produced under the Cedulon core profile (a Spend Receipt, an epoch checkpoint, a Trade Manifest, or a Decision Token).¶

Re-Attestation Statement:

A COSE_Sign1 object, signed with a successor algorithm, whose claims bind the hash of the Original Evidence, the original algorithm, the verification result observed at re-attestation time, and a reference to a transparency-log entry.¶

Successor Algorithm:

A fully-specified COSE algorithm [RFC9864] selected to outlive the algorithm of the Original Evidence.¶

Attestation Chain:

The sequence formed when a Re-Attestation Statement itself becomes Original Evidence for a later re-attestation.¶

3. Re-Attestation Statement

A Re-Attestation Statement is a COSE_Sign1 object over a deterministic CBOR claim map. The provisional claim set is:¶

Label values are to be assigned from the CWT private-use range in a later revision, alongside the Cedulon core label blocks.¶

4. Processing Rules (provisional)

1. A re-attester MUST verify the Original Evidence signature under its original algorithm before issuing a Re-Attestation Statement, and MUST record the verification time in verifiedAtMs.¶

2. A Re-Attestation Statement SHOULD be produced while the original algorithm is still considered trustworthy by current guidance. Re-attesting an already-broken algorithm proves nothing unless the Original Evidence was registered in a transparency log before the break; in that case the log inclusion proof, not the signature, is the basis of trust and the statement MUST reference it in anchorRef.¶

3. Each Re-Attestation Statement SHOULD be registered in a SCITT Transparency Service [RFC9943], obtaining a COSE receipt [RFC9942]; the resulting Transparent Statement is the archival unit.¶

4. A verifier evaluating old evidence walks the Attestation Chain from the newest statement backwards. The chain is acceptable when every link's signature verifies under an algorithm trusted at evaluation time and every originalHash/prevAttestationHash matches the presented bytes.¶

5. Security Considerations

Re-attestation moves trust from an aging cipher to the combination of a newer cipher and an append-only log. The critical window is the period before the original algorithm's break: evidence that reaches a transparency log inside that window survives; evidence that does not cannot be resurrected afterwards, and no statement defined here claims otherwise. A malicious re-attester can refuse to re-attest (denial of archival service) but cannot forge history that a log inclusion proof contradicts. Timestamp claims are assertions by the re-attester; deployments needing stronger time should anchor promptly so the log's observed registration time bounds verifiedAtMs.¶

6. IANA Considerations

This document has no IANA actions.¶

7. References

Acknowledgments

This seed accompanies the Cedulon core document and its companion implementation at https://github.com/dogrucanemek-alt/cedulon.¶

Author's Address