]> VERAX TEKNOLOJI LIMITED SIRKETI

Turkey e.dogru@cedulon.com

sec Cedulon re-attestation crypto-agility SCITT Audit evidence is only useful for as long as it can be verified. Cedulon produces COSE spend receipts and epoch checkpoints whose signature algorithms will eventually be deprecated or broken; the recent transition from polymorphic EdDSA to fully-specified Ed25519 algorithm identifiers shows that even identifiers change within a decade. This document proposes a re-attestation profile for Cedulon evidence: a signed statement, produced while the original algorithm is still trustworthy, that binds the original evidence bytes to a successor algorithm and is registered in a SCITT transparency service. Chains of such statements allow a verifier decades later to trust evidence whose original cipher has been retired. Structures are meant to outlive ciphers. This is an extension proposal to the Cedulon core document; its normative language is provisional and the companion implementation does not implement it yet.

Introduction A Cedulon Spend Receipt is a COSE_Sign1 object 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 . 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.

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 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 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.

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

Claim	Meaning
originalHash	SHA-256 of the Original Evidence COSE bytes, lowercase hex
originalAlg	COSE algorithm identifier of the Original Evidence
originalKid	Key identifier the Original Evidence verified against
verifiedAtMs	POSIX milliseconds at which the re-attester verified the original signature
successorAlg	COSE algorithm identifier of this statement's signature
anchorRef	Reference to the SCITT registration of the Original Evidence or of a prior chain link, or null
prevAttestationHash	SHA-256 of the previous Re-Attestation Statement in the chain, or null

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

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 , obtaining a COSE receipt ; 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.

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.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Federal Information Processing Standard, FIPS Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFCs 7518, 8037, and 9053. It deprecates polymorphic algorithms defined by RFCs 8037 and 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFCs 7518 and 9053. CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust over time and has been applied to certificates, end-to-end encrypted messaging systems, and supply chain security. This specification enables concise transparency-oriented systems by building on Concise Binary Object Representation (CBOR) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. Informative References

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