Summary

  • The 23 September revision of the IETF SCITT CCF receipt profile asks IANA to register two proof types as well as a verifiable-data-structure algorithm.
  • Revision -04 requested the algorithm alone. The current draft seeks value 2 for CCF_LEDGER_SHA256, with inclusion label -1 and consistency label -2 under that value.
  • These are requests, not assignments. IANA's public COSE tables still contain only algorithm 1 and its two proof entries, while the revised draft awaits review.

The missing items were not extra decoration on a registry form. A verifier that recognizes a verifiable-data-structure number still needs to know which proof types the number permits and how their CBOR values are to be read. On 23 September the SCITT working group published revision -05 of its CCF Profile for COSE Receipts with an IANA request that supplies both coordinates. The June -04 text had asked only for the algorithm entry. A September IANA expert review called out that absence before the replacement appeared.

The new section requests CCF_LEDGER_SHA256 as an algorithm with value 2 and asks for two proof records tied to it: inclusion at label -1 and consistency at label -2. Those negative labels are not globally self-describing shortcuts. The existing IANA table already uses -1 and -2 for algorithm 1, RFC9162_SHA256; the verifiable data-structure identifier determines which proof definition applies. Revision -05 also describes a protected vds identifier and an unprotected vdp map keyed by proof type, following the COSE receipts framework in RFC 9942. A reader can now inspect the proposed decoding path as a pair of registry requests rather than infer it from an algorithm name.

There is a sharp status limit. The draft calls 2 a requested assignment and uses a placeholder until IANA allocates it. The Datatracker history records an earlier IANA - Not OK state and a 23 September transition to Version Changed - Review Needed when -05 arrived. Its displayed expert-review state still says Issues identified. The public IANA Algorithms and Proofs tables have not gained the CCF entries. A posted revision is evidence of a repair attempt, not evidence of clearance or an RFC.

The proof descriptions themselves set a second boundary. For consistency, the draft requires a verifier to compare a recomputed old root with a root it already verified, not one supplied in the same exchange. It says a consistency receipt alone proves nothing about ledger contents or whether registration policies were correctly applied. That caveat matters, but it is not the registration defect: the defect was asking the shared number space to name a structure without registering the proof vocabulary that makes independent verification intelligible.

Sources