| Internet-Draft | Identifying SCITT Signed Statements | October 2026 |
| Gruszka | Expires 13 April 2027 | [Page] |
This document describes proposed requirements and test cases for identifying SCITT Signed Statements. It distinguishes reference matching from statement retrieval, signature verification, issuer authorization, and evidence of registration. It examines how alternative identification schemes treat changes to statement encodings and registration context. The requirements are input to technical discussion and do not represent working group consensus. This document does not define a common reference format, allocate a COSE header parameter, or establish a relationship vocabulary. Its examples illustrate selected properties rather than demonstrate interoperability between deployed transparency services.¶
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 13 April 2027.¶
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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
A Transparency Service in the Supply Chain Integrity, Transparency, and Trust (SCITT) architecture [RFC9943] registers Signed Statements and returns Receipts. Applications increasingly need to refer to a specific Signed Statement: an audit statement that refers to the statement it audited, a correction that refers to the statement it corrects, an evidence bundle that lists the statements it was built from. For such a reference to be usable, two implementations given the reference and a candidate statement must reach the same conclusion about whether they match.¶
This is harder than hashing some bytes. The same logical Signed Statement can be re-encoded, can gain or lose an unprotected header, and can be registered in more than one Transparency Service, each producing its own entry handle and Receipt. A reference that is meant to survive those changes must say exactly which differences preserve identity and which do not, and must be interpretable without first understanding the application payload of the statement that carries it.¶
The need is not specific to any one product. On 22 September 2026 one of the SCITT working group chairs asked on the scitt@ietf.org list, "On statement IDs please bring all requirements you may have for statement identification", and raised as an open question "whether or not the statement ID should be cryptographically derived from its log insertion or not" [SCITT-CHAIRS-20260922]. The chair added that it has "pros and cons" and "will need real engagement to get right". This document is input to that discussion.¶
This document states proposed requirements (Section 4), compares candidate identification objects (Section 5), and works through a small set of fully explained test cases (Section 6). It takes a position, independence of the reference-matching result from any particular registration, and argues it with use and trade-offs rather than asserting it as settled. It does not propose a wire format, a COSE header parameter, or a relationship vocabulary for standardization.¶
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.¶
This document uses the SCITT terms Signed Statement, Transparency Service and Receipt as defined in [RFC9943]. It adds the following working terms and keeps them apart deliberately:¶
Data that designates a target Signed Statement together with the rule by which a candidate is judged to be that target.¶
The rule a reference is read under: which bytes are covered, which differences preserve identity, and, for a digest-based scheme, the hash algorithm and the exact input bytes.¶
The operation of deciding, given a reference and a candidate statement, whether the candidate is the reference's target under the named scheme.¶
A Transparency-Service-local identifier of a registration, such as an entry identifier returned by an API [I-D.ietf-scitt-scrapi]. It locates an entry in one service; it is not a portable statement identity.¶
A Receipt [RFC9942] that a statement was registered. It is distinct from a reference match.¶
Matching a reference is not the same as retrieving a statement, verifying its signature, authorizing its Issuer, or proving it was registered. Keeping these apart is the central discipline of this document.¶
This document is a requirements and test-case text, not a new mechanism. The following work is adjacent; the References identify the revisions used.¶
The architecture [RFC9943] defines the Signed Statement envelope: Section 6.1 requires CBOR tag 18, and Section 6.3 requires the unprotected header to be an empty map before a statement is included in a Statement Sequence. It defines the statement, not a portable identifier for one statement or the bytes a statement digest covers.¶
The Receipts document [RFC9942] defines Verifiable Data Structures and their proofs; its Section 4.4.1 gives the registration requirements for a VDS, and its Section 5.2.1 is the RFC9162_SHA256 Receipt of Inclusion. Identity through a Receipt is scoped to a log and a VDS construction, and Section 4.4.1 leaves each VDS to define its own encoding and proofs.¶
The payload-binding draft [I-D.mih-sokolov-scitt-payload-binding] gives, in its Section 8, a general typed-digest-reference information model (type, purpose, digest_alg, digest) in which a carried digest and a recomputed digest are comparable only under one established referenced-artifact digest context, and in Sections 5 and 7 a derived identifier and a statement-to-Receipt binding. This document asks the narrower question of the concrete context a SCITT Signed Statement reference needs.¶
The protected-object-binding draft [I-D.nobuo-scitt-protected-object-binding] defines Statement References, Receipt References and Relationship Edges with an initial relationship vocabulary (for example describes, measures, authorizes, supersedes and revokes); it couples identification with that vocabulary, whereas this document keeps matching separate from the relationship it carries.¶
In SCRAPI [I-D.ietf-scitt-scrapi] Section 2.4, a GET on /entries/ followed by an EntryID answers with the Receipt (200), with 204 while registration is still running, or with 404; that EntryID is an API locator for one service, not a portable, registration-independent statement identity.¶
The SCITT charter (charter-ietf-scitt-01, last updated 2026-03-18, retrieved 2026-10-10) lists among its non-goals to "define data formats for payload content" and asks the group to "reuse existing work from IETF WGs such as COSE and RATS, as appropriate". Where a statement-identification requirement or a small profile belongs is itself an open question (Section 10).¶
The following cases need different identification properties; they motivate the requirements without selecting a scheme.¶
Audit reference. An auditor registers a statement that refers to the statement it audited. A reader must match the reference to the audited statement even if the audited statement has since been re-registered elsewhere.¶
Correction reference. An Issuer registers a later statement that corrects an earlier one, keeping the same subject. The subject groups the two; the reference must still select the specific earlier statement, not merely the subject.¶
Offline evidence bundle. A bundle lists the statements it was built from and is checked by a relying party that holds the bytes but queries no service. Matching must not require a service round-trip.¶
Cross-service presence. The same statement is registered in two Transparency Services. A reference that is meant to be portable must designate the same statement across both, distinguishing identity-bearing changes from encoding changes the scheme excludes.¶
These requirements are proposed input, not working group consensus. They are taken from an existing requirements note (see Section 11) and are stated here with their differing roles made explicit: A1 and A2 are properties of a reference, A3 is a design position, A4 is its acceptance test, and A5 is a conditional dependency of schemes that rely on a Receipt, not a fifth independent rule on every reference.¶
The BCP 14 keywords in A1 to A5 address a future identification scheme or profile; they are not obligations this document places on an existing protocol. Where a requirement restates an existing obligation it says so and cites it: the CBOR tag 18 of [RFC9943] Section 6.1, the empty unprotected header of [RFC9943] Section 6.3, and the VDS registration requirements of [RFC9942] Section 4.4.1 are existing obligations this document relies on, not new ones.¶
Given a reference and a candidate Signed Statement, a verifier can decide whether they match under a named identification scheme. The scheme states which differences preserve identity, including differences in signatures, headers and encodings. For a digest-based scheme it also defines the hash algorithm, the input bytes, and their encoding. These definitions MAY be supplied by a profile rather than repeated in each reference.¶
The Issuer and Subject pair groups related statements but does not select an
individual statement from that group ([RFC9943] Section 6 uses iss and sub
to identify the Artifact; the architecture defines no statement identifier). Acceptance: two implementations
using the same scheme agree on matching and non-matching candidate vectors;
missing inputs or unsupported rules cannot produce a successful match; a
ToBeSigned scheme must specify external_aad and the source of any detached
payload.¶
A verifier can locate and interpret a reference without interpreting the application payload of the Signed Statement that carries it. Recomputing a target digest MAY still require the target's payload bytes; that is a property of the target, not of reading the reference from the carrier. This is a proposed scope choice: without it, extracting a reference could require payload-specific parsing or decryption of the carrier.¶
Proposed requirement: matching a reference to a candidate does not depend on registration with a particular Transparency Service or on a particular insertion event. Service-local entry handles and Receipts may coexist with the reference and may differ.¶
This is one proposed answer to that open question. It is a design position, argued from the offline-bundle and cross-service use cases, not a claim that a log-derived identifier cannot work. A log-dependent identifier does not by itself prevent offline verification when the needed bytes, keys and trust anchors are already held; the property asked for here is independence from the registration context, not offline capability in general (Section 5.2).¶
Under the same identification scheme, registration in either of two Transparency Services preserves the identity A1 defines. The test must distinguish identity-bearing changes from changes the scheme explicitly excludes. No two-service registration is measured in this document (Section 6 and Section 11); the illustrative cases instead apply local transformations that a registration may cause (an added unprotected parameter; a changed outer encoding) and show which leave the chosen identity unchanged. The tag-removal case (C9) is a negative format control, not evidence of successful registration in two services.¶
Where identification depends on a leaf hash or a Receipt, the selected Verifiable Data Structure specification MUST define the entry-to-leaf transformation, serialization and tree hashing sufficiently for independent implementations to reproduce the result. This is a dependency of such schemes and of interoperable Receipt verification, not a fifth independent requirement on every reference. [RFC9942] Section 4.4.1 states that "Each VDS specification applying for inclusion in this registry MUST define how to encode the VDS identifier and its Proof Types in CBOR" and that "Each specification MUST define how to produce and consume the supported Proof Types"; its Section 5.2.1 is the Receipt of Inclusion of the specific RFC9162_SHA256 construction, which begins "In a signed proof, the payload is the Merkle Tree root that corresponds to the log at size tree-size". Different VDS constructions differ in their leaf and node hashing (for example the 0x00/0x01 prefixes of [RFC9162] Section 2.1.1); that difference does not make either construction ambiguous. This document does not test leaf hashing or Receipts.¶
The central design decision is not the hash algorithm but the identification object: which differences count as identity-changing. The following is the authors' analysis of candidate objects; it is not a selection.¶
| Identification object | Possible benefit | Price to be settled |
|---|---|---|
| Whole transmitted object bytes | Simple exact byte identity | Transport or envelope changes produce different values even when other checks still pass |
| An explicitly defined canonical object encoding | Equal treatment of selected encoding variants | Extra rules, cost, and the risk of diverging normalization |
| The COSE signing input ToBeSigned | Binds to the actually signed content and its signature context | Does not itself identify the signature value or the unprotected envelope; external inputs must be available and fixed |
| The payload only | Fits when the content, not the signed assertion, is meant | Issuer, header and signature differences are not necessarily distinguished |
| A VDS leaf or service entry | Close tie to a concrete registration | Depends on the VDS construction or the service context |
For COSE, [RFC9052] Section 4.3 (externally supplied data) and Section 4.4 (the Sig_structure) are the relevant definitions, and Section 9 constrains the CBOR encoding. A successful signature verification does not by itself fix which universal statement identity an application should use.¶
The examples in Section 6 use SHA-256 over ToBeSigned, the Sig_structure
["Signature1", body_protected, external_aad, payload] of [RFC9052] Sections
4.4 and 9, with the payload embedded. The scheme names external_aad as an
explicit input: it is the empty byte string unless a specific case states
otherwise, and a case that signs over a non-empty external_aad lists those
exact bytes (Appendix A) and applies them to both matching and signature
verification. The body_protected value is the original protected-header byte
string, not a decoded and re-encoded map. This object names a class of signed inputs: it excludes the
signature value, the unprotected header and the outer wrapper, so changes confined
to those parts preserve it, and it does not normalize the bytes inside the
protected header or payload. It is used here as one illustrative rule. This
document does not propose it as the statement identity defined by the architecture;
[RFC9943] defines no such identity, and a later profile is free to choose a
different object.¶
A scheme can be checked offline when the needed bytes, keys and trust assumptions are already held; a service-dependent identifier is not online merely because it is service-dependent. A3 therefore argues for independence from the registration context, not for a blanket impossibility of offline checking of other models.¶
Each check is reported on separate axes: ref_usable indicates whether the reference is well-formed and
compatible with the named scheme; match is MATCH or NO_MATCH when the comparison can be completed, and
INDETERMINATE when the reference is unusable or a required input is absent; sig_valid indicates whether
the candidate's signature verifies under the stated key; and is_scitt indicates whether the candidate is
a tagged COSE_Sign1 ([RFC9943] Section 6.1 requires CBOR tag 18). A match establishes
none of signature validity, issuer trust, payload truth, or registration.¶
A candidate is read as a COSE_Sign1 ([RFC9052] Section 4.2), bare or with tag
18: an array of exactly four elements: the protected header, a byte string that
is empty or encodes one map; the unprotected header, a map; the payload, a byte string or nil; and the
signature, a byte string. For these illustrative axes, this read check covers
only the outer tag, the array shape, the stated element types and the basic CBOR
validity rules below. It does not validate header labels or header parameter
semantics. The is_scitt axis reports this structural check with tag 18, not
complete conformance to the SCITT envelope profile. The candidate and its
protected header are each one
CBOR data item that is well-formed and valid under [RFC8949] Section 5.3.1:
every text string is valid UTF-8, and no map holds two keys that are
equal under the key equivalence of [RFC8949] Section 5.6.1, so that the
integer 1 and true are two keys and 0.0 and -0.0 are one. Whether the content
of a tag inside the COSE_Sign1 is valid for that tag ([RFC8949] Section 5.3.2)
is not checked; the
data items inside a tag are checked like any other data item. The deterministic
encoding is not required. A candidate
that breaks any of this, for example with a text string that is not valid UTF-8
in either header, is not a statement: its is_scitt is False and its
sig_valid is None, not evaluated; its match is NO_MATCH under a usable
reference and INDETERMINATE under an unusable one.¶
The sig_valid axis is computed with one rule for every case. n*P is the
point P multiplied by the integer n. A is the 32-byte public key of the stated
key, derived from its seed in Appendix A.2 as in [RFC8032] Section 5.1.5; R is
the first and S the second 32 bytes of the 64-byte signature, S read as a
little-endian integer; B' is the base point and L the order of B'
([RFC8032] Section 5.1); and ToBeSigned is the object of Section 5.1 of this document with
the case's external_aad and payload. sig_valid is True if and only if all
four rules hold:¶
A and R are canonical encodings: decoding each as in [RFC8032] Section 5.1.3 succeeds.¶
A and R have order L: L*A and L*R are the neutral element, and A and R
are not the neutral element.¶
S is below L.¶
With k = SHA-512(R || A || ToBeSigned) read as a little-endian integer and
reduced modulo L, the cofactorless equation S*B' = R + k*A holds. R enters
the hash exactly as received, A as its 32-byte encoding.¶
After the candidate passes the read checks above, a signature that is not 64
bytes gives sig_valid False. Otherwise, if the payload is absent and not
supplied, there is no ToBeSigned and sig_valid is None, not evaluated (C8).
Otherwise, evaluate the four rules above.¶
Because A and R have order L, the cofactorless equation of rule 4 and the
cofactored equation 8*S*B' = 8*R + 8*k*A of [RFC8032] Section 5.1.7 accept
exactly the same signatures. This document defines individual verification
only. A randomized batch result MUST NOT substitute for checking all four rules
for each signature. Case C11 has an R
of mixed order, for which the two equations differ; rule 2 refuses it before
either is checked. The rule fixes the sig_valid axis of these cases only; the
match axis does not depend on it.¶
The cases use three synthetic signed statements about one subject and the reference between them, under the ToBeSigned scheme of Section 5.1. Each case is checked against the reference digest given in Appendix A.1. The full bytes, keys and per-case results are in Appendix A; the keys are pure test keys. The fixtures use the fully specified Ed25519 algorithm (COSE algorithm -19); the source package uses EdDSA (-8). Identification is independent of the signature algorithm.¶
| ID | Req | ref_usable | match | is_scitt | sig_valid | What it shows |
|---|---|---|---|---|---|---|
| C1 | A1 | True | MATCH | True | True | positive control |
| C2 | A1 | True | NO_MATCH | True | True | subject grouping is not single identity |
| C3 | A1 | True | NO_MATCH | True | True | changed target payload |
| C4 | A1 | True | NO_MATCH | True | True | changed protected header |
| C5 | A4 | True | MATCH | True | True | added unprotected parameter (envelope) |
| C6 | A1 | True | MATCH | True | False | signature replaced, same signed input |
| C7 | A1 | True | NO_MATCH | True | True | non-empty external_aad |
| C8 | A1 | True | INDETERMINATE | True | None | detached payload not supplied |
| C9 | A1 | True | MATCH | False | True | tag 18 removed |
| C10 | A1 | False | INDETERMINATE | True | True | scheme/algorithm mismatch |
| C11 | A1 | True | MATCH | True | False | R of mixed order |
The following cases illustrate the scope and limits of the chosen identity rule. Case C5 adds one unprotected parameter after signing: the ToBeSigned digest and the signature are unchanged while the whole-object digest changes, so a whole-bytes identifier and a ToBeSigned identifier disagree exactly where a registration may rewrite the envelope. C9 reports MATCH under the illustrative ToBeSigned rule and is_scitt = False because tag 18 is absent; it is a negative format control, not evidence of successful registration in two services. Case C8 withholds a detached payload: a missing input yields INDETERMINATE, never a match. Case C6 replaces the signature with one from another key over the same signing input: the ToBeSigned reference still matches, but the signature does not verify under the stated key, which is why the two axes are reported separately.¶
An empty check set is not a PASS: a case for which no axis could be evaluated is reported as INDETERMINATE, not as a match.¶
This section considers the attacker and the risks this work raises, in the spirit of [RFC3552]. A successful reference match is not a trust decision. It does not establish that the candidate's signature is valid, that its Issuer is authorized, that its payload is true, or that it was registered. Relying parties MUST keep these results separate and MUST NOT treat a match as any of them. Collapsing them into a single boolean is the main foreseeable misuse.¶
The identification object determines the attack surface. A whole-bytes identifier
changes under any envelope rewrite, so a party expecting stability may fail to
match a legitimately re-registered statement. A ToBeSigned identifier is stable
across such rewrites but, by construction, does not distinguish two objects that
share a signing input and differ only in the signature value or unprotected
header; a party that needs to pin the exact signature instance needs a
whole-object identifier instead. A scheme MUST state external_aad and the source
of any detached payload; a missing input MUST NOT silently become an empty input
or a successful match, and a mismatch between a scheme's declared algorithm and a
reference's algorithm MUST NOT fall back silently.¶
Tag discipline matters: a generic COSE_Sign1 without CBOR tag 18 is not a SCITT Signed Statement ([RFC9943] Section 6.1), and a test that drops the tag MUST NOT be presented as a valid SCITT case. A stable reference shows only that a designated statement exists and matches; it does not show that no newer relevant statement has appeared, so a reference match MUST NOT be read as current validity or as completeness of a history.¶
A verifier that recomputes a target digest reads externally supplied bytes; large, deeply nested, or cyclically referenced inputs can exhaust resources. An implementation should bound the input size and nesting it will process rather than hashing unbounded input, and should treat a set of references as a list to check, not a graph to traverse.¶
Digest-based identification depends on the collision and second-preimage resistance of the selected hash algorithm.¶
A stable, portable reference is a correlator. The same identifier appearing in two contexts links them. Schemes and deployments SHOULD consider whether a reference needs to be stable across services at all, and whether salted or context-scoped references are more appropriate where linkage is a concern. The subject identifier in a statement groups statements about one Artifact and is itself a correlator independent of the reference scheme.¶
A digest is not by itself a confidentiality mechanism. When the covered content is drawn from a small or well-known set of possibilities, a party that holds the reference can confirm a guess by hashing each candidate and comparing, even if the target statement is never disclosed. A scheme that intends a reference to hide its target needs enough entropy in the covered content (for example a salt) that this guessing attack is infeasible.¶
This document has no IANA actions. It allocates no COSE header parameter and defines no registry. The COSE header label -70001 used by the examples in Appendix A is in the Private Use range of the COSE Header Parameters registry (integer values less than -65536); it is a local convention of the example package, not a requested or assigned value.¶
Concrete feedback is sought on the following.¶
The identification object. Should a SCITT statement reference bind to ToBeSigned, to a canonical object encoding, to the whole object bytes, or to a VDS leaf; and should the choice be fixed by the architecture or left to profiles?¶
Registration derivation. That open question stands: should a statement identifier be cryptographically derived from its log insertion, and what are the trade-offs against a registration-independent identifier (A3)?¶
Venue. Whether statement-identification requirements, or a small profile, belong in the SCITT architecture, in a Receipts or payload-binding document, or in a separate document; the charter's payload-format non-goal (Section 2.1) bears on this.¶
Relationship vocabulary. This document deliberately excludes one; whether the identification work needs any relationship terms at all is open.¶
This section is given per [RFC7942] and is to be removed by the RFC Editor before publication.¶
An open-source project, proofbundle, carries the requirements note this document is drawn from and a small synthetic example package, at commit eb1b7eeb28a4f77a4fe9fb1eadc21be0fb03746d (files docs/scitt/statement_identification/requirements.md and the package under docs/scitt/statement_identification/package/). That package signs three synthetic statements and checks the ToBeSigned references between them offline with a CBOR library and a general cryptography library. The illustrative examples here sign with the fully-specified Ed25519 algorithm -19 of [RFC9864]; the package at that commit uses EdDSA -8, which [RFC9864] lists as deprecated, and the ToBeSigned identification does not depend on the signature algorithm. The three example signatures were decoded and verified independently in this work by decoding the COSE_Sign1 with a CBOR library and verifying the Ed25519 signature over the Sig_structure with a general cryptography library. pycose 1.1.0, the COSE library present in the run environment, cannot decode algorithm -19; no other independent COSE library was available, so whether a second COSE library decodes and verifies -19 was not tested. The examples were generated and checked with cbor2 5.4.6 and cryptography 41.0.7. The illustrative cases of Section 6 and Appendix A were generated and checked in this work; the fixtures are synthetic and the keys are test keys.¶
One own measurement motivates the choice of hash input under A1 and is reported here as a measured fact, not an endorsement. Against a locally run transparency ledger (microsoft/scitt-ccf-ledger at commit 00101f76, CCF 7.0.17), of 62 registered rows, 39 had a SHA-256 of the submitted bytes that differed from the data-hash in the returned Receipt, because the service sets the unprotected header to an empty map and rewrites the outer encoding before inclusion. This measurement shows why a reference scheme must specify whether it covers submitted bytes or the representation included in the Statement Sequence; it does not by itself show that the identifier depends on the service or insertion event. The corpus matrix is in the proofbundle repository at tools/scitt_ccf_external/differential_corpus_round3/README.md (freeze commit c5ff0a72e28aa087eecd3e2b426577be3cf2a80f) and the replay at tools/scitt_ccf_external/replay_earlier_build/results_table.md (commit 3ca368164b68a09a863f7ec12b2f9fa1b21123ec). Only the repository evidence is cited here.¶
This information is given per [RFC7942] and does not constitute endorsement.¶
All byte strings are hex. Each of the three base statements is a tagged COSE_Sign1 (first byte 0xd2, CBOR tag 18) signed with
the fully-specified Ed25519 algorithm (COSE algorithm -19, [RFC9864]). The private-use label carries a list of references; in these
examples the list holds exactly one, the array [-16, "ToBeSigned", digest], which
references statement 01, and the digest is SHA-256 over the ToBeSigned of statement
01. The test keys are pure test keys given as fixed seeds
and MUST NOT be used for any real statement.¶
All three statements share the subject pkg:generic/example-widget@1.0.0. COSE header label -70001 (Private Use) carries a list of references; in these examples the list holds exactly one, [-16, "ToBeSigned", digest], which references statement 01, and its digest is SHA-256 over the ToBeSigned of 01.¶
Reference digest (SHA-256 over ToBeSigned of 01): c3f5f13764679b9f77918bb52782480bc222be5ae4bce37f51384a6b1faa9dbc¶
01 ToBeSigned SHA-256: c3f5f13764679b9f77918bb52782480bc222be5ae4bce37f51384a6b1faa9dbc¶
Statement 01 (iss https://issuer.example; 330 bytes; SHA-256 9c7253617b9fe51ba25eb0f957dadea493ca03e98c4a81806237757f13d054c6):¶
d284587ba4013203706170706c69636174696f6e2f6a736f6e0458200e6e86cd 20c07df4e95cb4a07a286192d29fc74567b41e726f1c7f7bd202eb5b0fa30176 68747470733a2f2f6973737565722e6578616d706c65027820706b673a67656e 657269632f6578616d706c652d77696467657440312e302e30061a68ce7b20a0 58867b226172746966616374223a226578616d706c652d7769646765742d312e 302e302e7461722e677a222c226c6963656e7365223a224d4954222c22736861 323536223a223630376536633165366333356463633962373730646535646139 3262393639373034613336366434363839373261386235356431613063333264 623334613732227d58401fb31a6df345f1c1840d878bd4b4acedb6612956916e 4b4550c5b6479289ed36f41cb604c8ab743dc2eb9fbda7fecfb896b3d444ba30 e591e663093a4eeb8104¶
Statement 02 (iss https://auditor.example, refers to 01; 365 bytes; SHA-256 c4758ea9ae4d85461a93ee1dbb302fb698c922b1fbcb4139ebc706e3aeccbebd):¶
d28458aba50132036a746578742f706c61696e045820a2820b29631a0e52ec5d be41f948a9e5725c6b8d8c0346bd3ef5483cab27de580fa3017768747470733a 2f2f61756469746f722e6578616d706c65027820706b673a67656e657269632f 6578616d706c652d77696467657440312e302e30061a68ce7b203a0001117081 832f6a546f42655369676e65645820c3f5f13764679b9f77918bb52782480bc2 22be5ae4bce37f51384a6b1faa9dbca058795468652061727469666163742064 696765737420696e20746865207265666572656e6365642073746174656d656e 7420776173207265636f6d707574656420616e64206d6174636865732e205468 697320617564697420636f7665727320746865207265666572656e6365642062 79746573206f6e6c792e0a5840702de547d0247fd14444d31f0130c7d9b16c01 68f43988c19320e5a6e37264c617a086d8a117a8c4e44ece4fe17da69ae2527d b8cbb9a709be4a271047016b03¶
Statement 03 (iss https://issuer.example, refers to 01; 450 bytes; SHA-256 f5afbb3b0c7d822b00741e5eacd9128b723922bf3cad6ed5a3ab00e884b58e99):¶
d28458b0a5013203706170706c69636174696f6e2f6a736f6e0458200e6e86cd 20c07df4e95cb4a07a286192d29fc74567b41e726f1c7f7bd202eb5b0fa30176 68747470733a2f2f6973737565722e6578616d706c65027820706b673a67656e 657269632f6578616d706c652d77696467657440312e302e30061a68ce7b203a 0001117081832f6a546f42655369676e65645820c3f5f13764679b9f77918bb5 2782480bc222be5ae4bce37f51384a6b1faa9dbca058c97b2261727469666163 74223a226578616d706c652d7769646765742d312e302e302e7461722e677a22 2c226c6963656e7365223a224170616368652d322e30222c226e6f7465223a22 546865206c6963656e736520696e20746865207265666572656e636564207374 6174656d656e74207761732077726f6e672e222c22736861323536223a223630 3765366331653663333564636339623737306465356461393262393639373034 613336366434363839373261386235356431613063333264623334613732227d 584032cc26dcf624b14ff15e1f307898d9a287559ca388b78227283e4dee5fea 9b04a3fb86cf0b12d553b791a210bff7e7478efe147f99c05f69b0d11e6a0766 ae0b¶
PURE TEST KEYS given as fixed seeds. They MUST NOT be used for any real statement.¶
issuer:¶
Ed25519 seed (hex, 32 bytes): 51bdccce75df50a4bcee21a2f730ccdcd4917a0a4d20dd2ab3d2e5ffad3f6fd3¶
kid (hex, SHA-256 of the SubjectPublicKeyInfo): 0e6e86cd20c07df4e95cb4a07a286192d29fc74567b41e726f1c7f7bd202eb5b¶
auditor:¶
Each case below gives the candidate's full bytes and its SHA-256, so a reader can confirm the exact bytes the case was run on. The expected axes are in the table of Section 6; the measured axes are given here.¶
Unchanged reference and candidate (the reference target 01).¶
candidate SHA-256 (whole COSE_Sign1): 9c7253617b9fe51ba25eb0f957dadea493ca03e98c4a81806237757f13d054c6 (330 bytes)¶
measured: ref_usable = True, match = MATCH, is_scitt = True, sig_valid = True¶
d284587ba4013203706170706c69636174696f6e2f6a736f6e0458200e6e86cd 20c07df4e95cb4a07a286192d29fc74567b41e726f1c7f7bd202eb5b0fa30176 68747470733a2f2f6973737565722e6578616d706c65027820706b673a67656e 657269632f6578616d706c652d77696467657440312e302e30061a68ce7b20a0 58867b226172746966616374223a226578616d706c652d7769646765742d312e 302e302e7461722e677a222c226c6963656e7365223a224d4954222c22736861 323536223a223630376536633165366333356463633962373730646535646139 3262393639373034613336366434363839373261386235356431613063333264 623334613732227d58401fb31a6df345f1c1840d878bd4b4acedb6612956916e 4b4550c5b6479289ed36f41cb604c8ab743dc2eb9fbda7fecfb896b3d444ba30 e591e663093a4eeb8104¶
Same issuer and subject, different statement (03): subject grouping does not select 01.¶
candidate SHA-256 (whole COSE_Sign1): f5afbb3b0c7d822b00741e5eacd9128b723922bf3cad6ed5a3ab00e884b58e99 (450 bytes)¶
measured: ref_usable = True, match = NO_MATCH, is_scitt = True, sig_valid = True¶
d28458b0a5013203706170706c69636174696f6e2f6a736f6e0458200e6e86cd 20c07df4e95cb4a07a286192d29fc74567b41e726f1c7f7bd202eb5b0fa30176 68747470733a2f2f6973737565722e6578616d706c65027820706b673a67656e 657269632f6578616d706c652d77696467657440312e302e30061a68ce7b203a 0001117081832f6a546f42655369676e65645820c3f5f13764679b9f77918bb5 2782480bc222be5ae4bce37f51384a6b1faa9dbca058c97b2261727469666163 74223a226578616d706c652d7769646765742d312e302e302e7461722e677a22 2c226c6963656e7365223a224170616368652d322e30222c226e6f7465223a22 546865206c6963656e736520696e20746865207265666572656e636564207374 6174656d656e74207761732077726f6e672e222c22736861323536223a223630 3765366331653663333564636339623737306465356461393262393639373034 613336366434363839373261386235356431613063333264623334613732227d 584032cc26dcf624b14ff15e1f307898d9a287559ca388b78227283e4dee5fea 9b04a3fb86cf0b12d553b791a210bff7e7478efe147f99c05f69b0d11e6a0766 ae0b¶
Changed target payload (re-signed): ToBeSigned differs.¶
candidate SHA-256 (whole COSE_Sign1): 63723353fdf05662cfcc618e8b47fd4142dce4a71e84b61a6bdbdde988e837ab (339 bytes)¶
measured: ref_usable = True, match = NO_MATCH, is_scitt = True, sig_valid = True¶
d284587ba4013203706170706c69636174696f6e2f6a736f6e0458200e6e86cd 20c07df4e95cb4a07a286192d29fc74567b41e726f1c7f7bd202eb5b0fa30176 68747470733a2f2f6973737565722e6578616d706c65027820706b673a67656e 657269632f6578616d706c652d77696467657440312e302e30061a68ce7b20a0 588f7b226172746966616374223a226578616d706c652d7769646765742d312e 302e302e7461722e677a222c226c6963656e7365223a224253442d332d436c61 757365222c22736861323536223a223630376536633165366333356463633962 3737306465356461393262393639373034613336366434363839373261386235 356431613063333264623334613732227d5840a7cd3cb04606ed9a99f7105b48 9cd67f424fcc0993964eefc170600d37214794ded3d2e84d1309727cb4a9d550 ea0729af7a283453794ea2ad0d023d1e824307¶
Changed protected header (content type), re-signed: ToBeSigned differs.¶
candidate SHA-256 (whole COSE_Sign1): 65eb1e45177add009aef819b438c910aae934c3a05b7966ef73614e11ff07bcc (330 bytes)¶
measured: ref_usable = True, match = NO_MATCH, is_scitt = True, sig_valid = True¶
d284587ba4013203706170706c69636174696f6e2f63626f720458200e6e86cd 20c07df4e95cb4a07a286192d29fc74567b41e726f1c7f7bd202eb5b0fa30176 68747470733a2f2f6973737565722e6578616d706c65027820706b673a67656e 657269632f6578616d706c652d77696467657440312e302e30061a68ce7b20a0 58867b226172746966616374223a226578616d706c652d7769646765742d312e 302e302e7461722e677a222c226c6963656e7365223a224d4954222c22736861 323536223a223630376536633165366333356463633962373730646535646139 3262393639373034613336366434363839373261386235356431613063333264 623334613732227d58406e32c4cb930f0a80529f3c9494ddcf140e0cefa61d5e 26a16f8959cbddd6dc3b7555affb55bec79d8cef0a4d710cd16057aa364924e3 e7867966bb03e5764c04¶
Added one unprotected parameter after signing (tag 18 kept): ToBeSigned and signature unchanged, whole-object digest changes.¶
candidate SHA-256 (whole COSE_Sign1): fbab2b2b1c572ca374458ba2590fa5ca0da056a6ce47666f7220f1bca4250ab8 (355 bytes)¶
measured: ref_usable = True, match = MATCH, is_scitt = True, sig_valid = True¶
d284587ba4013203706170706c69636174696f6e2f6a736f6e0458200e6e86cd 20c07df4e95cb4a07a286192d29fc74567b41e726f1c7f7bd202eb5b0fa30176 68747470733a2f2f6973737565722e6578616d706c65027820706b673a67656e 657269632f6578616d706c652d77696467657440312e302e30061a68ce7b20a1 3a00011171736164646564206166746572207369676e696e6758867b22617274 6966616374223a226578616d706c652d7769646765742d312e302e302e746172 2e677a222c226c6963656e7365223a224d4954222c22736861323536223a2236 3037653663316536633335646363396237373064653564613932623936393730 3461333636643436383937326138623535643161306333326462333461373222 7d58401fb31a6df345f1c1840d878bd4b4acedb6612956916e4b4550c5b64792 89ed36f41cb604c8ab743dc2eb9fbda7fecfb896b3d444ba30e591e663093a4e eb8104¶
Same ToBeSigned, signature replaced with one from a different key: matches the ToBeSigned reference, but does not verify under the issuer key.¶
candidate SHA-256 (whole COSE_Sign1): f8bf927260ae6d9c6edadeb79e0295e39dc30341b21b1a61d6cf31b35d778bf8 (330 bytes)¶
measured: ref_usable = True, match = MATCH, is_scitt = True, sig_valid = False¶
d284587ba4013203706170706c69636174696f6e2f6a736f6e0458200e6e86cd 20c07df4e95cb4a07a286192d29fc74567b41e726f1c7f7bd202eb5b0fa30176 68747470733a2f2f6973737565722e6578616d706c65027820706b673a67656e 657269632f6578616d706c652d77696467657440312e302e30061a68ce7b20a0 58867b226172746966616374223a226578616d706c652d7769646765742d312e 302e302e7461722e677a222c226c6963656e7365223a224d4954222c22736861 323536223a223630376536633165366333356463633962373730646535646139 3262393639373034613336366434363839373261386235356431613063333264 623334613732227d584015d271c055a0f391bcec610607a951fa312ef917892f f6528dc362a074b63a4867d95424ae1904e7b353bf11fb13e05a276032747c52 d7db0ddb953f89e3c60e¶
Target signed over a non-empty external_aad. The scheme applies the supplied AAD bytes (given below) to both reference matching and signature verification, so the empty-external_aad reference does not match while the signature verifies. The same candidate bytes under the fixed empty-external_aad rule are reported separately below. A missing external context is not assumed empty.¶
candidate SHA-256 (whole COSE_Sign1): 0a5390069e431e6dd83764ee276b28f69d34986a9e64d82f05ef3322bc66d61c (330 bytes)¶
external_aad (hex, 17 bytes): 6374783a6465706c6f796d656e742d3432¶
measured: ref_usable = True, match = NO_MATCH, is_scitt = True, sig_valid = True¶
the same candidate bytes under the fixed empty external_aad rule: match = MATCH, sig_valid = False¶
d284587ba4013203706170706c69636174696f6e2f6a736f6e0458200e6e86cd 20c07df4e95cb4a07a286192d29fc74567b41e726f1c7f7bd202eb5b0fa30176 68747470733a2f2f6973737565722e6578616d706c65027820706b673a67656e 657269632f6578616d706c652d77696467657440312e302e30061a68ce7b20a0 58867b226172746966616374223a226578616d706c652d7769646765742d312e 302e302e7461722e677a222c226c6963656e7365223a224d4954222c22736861 323536223a223630376536633165366333356463633962373730646535646139 3262393639373034613336366434363839373261386235356431613063333264 623334613732227d584057a8f8450fa4e8449619d980fc34d38ad07f02f2c618 029be54102abfe430f905522a26a4013dae2ed3e093f199e127dc8e1a558a071 192eac406a813ab97f04¶
Detached payload (payload field is nil) and the detached bytes are not supplied: the match is INDETERMINATE, never a success.¶
candidate SHA-256 (whole COSE_Sign1): 7ceb07265f8b803a1ff96924da0b3a48b8355ec9daed0a9a31cd36cddaf34fdb (195 bytes)¶
measured: ref_usable = True, match = INDETERMINATE, is_scitt = True, sig_valid = None¶
note: detached payload not supplied; a missing input is never a match¶
d284587ba4013203706170706c69636174696f6e2f6a736f6e0458200e6e86cd 20c07df4e95cb4a07a286192d29fc74567b41e726f1c7f7bd202eb5b0fa30176 68747470733a2f2f6973737565722e6578616d706c65027820706b673a67656e 657269632f6578616d706c652d77696467657440312e302e30061a68ce7b20a0 f65840efdb7c7670bd56d96454ded2a7d92934b75edc092e9e9538aa16dd088a b74c1d2831555b36abf6f9c13549d25eb07951880731bf2b52acd42c4e98237b dbdb0e¶
Tag 18 removed, nothing else changed: the ToBeSigned digest still matches, but the object is not a tagged COSE_Sign1, so it is not a valid SCITT Signed Statement (RFC 9943 Section 6.1 requires tag 18).¶
candidate SHA-256 (whole COSE_Sign1): c205d745619c3087ad1f83f6c1f7883f4fff616f8f90ecbe64c4aa08854b28e6 (329 bytes)¶
measured: ref_usable = True, match = MATCH, is_scitt = False, sig_valid = True¶
84587ba4013203706170706c69636174696f6e2f6a736f6e0458200e6e86cd20 c07df4e95cb4a07a286192d29fc74567b41e726f1c7f7bd202eb5b0fa3017668 747470733a2f2f6973737565722e6578616d706c65027820706b673a67656e65 7269632f6578616d706c652d77696467657440312e302e30061a68ce7b20a058 867b226172746966616374223a226578616d706c652d7769646765742d312e30 2e302e7461722e677a222c226c6963656e7365223a224d4954222c2273686132 3536223a22363037653663316536633335646363396237373064653564613932 6239363937303461333636643436383937326138623535643161306333326462 3334613732227d58401fb31a6df345f1c1840d878bd4b4acedb6612956916e4b 4550c5b6479289ed36f41cb604c8ab743dc2eb9fbda7fecfb896b3d444ba30e5 91e663093a4eeb8104¶
The scheme names SHA-512 (-44), while the reference carries SHA-256 (-16), so ref_usable is False and match is INDETERMINATE; no fallback is performed.¶
candidate SHA-256 (whole COSE_Sign1): 9c7253617b9fe51ba25eb0f957dadea493ca03e98c4a81806237757f13d054c6 (330 bytes)¶
measured: ref_usable = False, match = INDETERMINATE, is_scitt = True, sig_valid = True¶
d284587ba4013203706170706c69636174696f6e2f6a736f6e0458200e6e86cd 20c07df4e95cb4a07a286192d29fc74567b41e726f1c7f7bd202eb5b0fa30176 68747470733a2f2f6973737565722e6578616d706c65027820706b673a67656e 657269632f6578616d706c652d77696467657440312e302e30061a68ce7b20a0 58867b226172746966616374223a226578616d706c652d7769646765742d312e 302e302e7461722e677a222c226c6963656e7365223a224d4954222c22736861 323536223a223630376536633165366333356463633962373730646535646139 3262393639373034613336366434363839373261386235356431613063333264 623334613732227d58401fb31a6df345f1c1840d878bd4b4acedb6612956916e 4b4550c5b6479289ed36f41cb604c8ab743dc2eb9fbda7fecfb896b3d444ba30 e591e663093a4eeb8104¶
Statement 01 with its 64 signature bytes replaced: R is a canonical encoding of a point of mixed order, and S is below L. Rule 2 refuses R, so sig_valid is False while the ToBeSigned reference matches. With rule 2 left out, the cofactored equation holds and the cofactorless equation does not.¶
candidate SHA-256 (whole COSE_Sign1): d1e77e708d759c9b393e93708968887df1ef0e56872166877f68d4ff9e43afe1 (330 bytes)¶
measured: ref_usable = True, match = MATCH, is_scitt = True, sig_valid = False¶
with rule 2 left out: the cofactorless equation gives sig_valid = False, the cofactored equation gives sig_valid = True¶
d284587ba4013203706170706c69636174696f6e2f6a736f6e0458200e6e86cd 20c07df4e95cb4a07a286192d29fc74567b41e726f1c7f7bd202eb5b0fa30176 68747470733a2f2f6973737565722e6578616d706c65027820706b673a67656e 657269632f6578616d706c652d77696467657440312e302e30061a68ce7b20a0 58867b226172746966616374223a226578616d706c652d7769646765742d312e 302e302e7461722e677a222c226c6963656e7365223a224d4954222c22736861 323536223a223630376536633165366333356463633962373730646535646139 3262393639373034613336366434363839373261386235356431613063333264 623334613732227d584095999999999999999999999999999999999999999999 999999999999999999992d5ac5acb4933c1790098a56557795abf48a9f65f463 6552659e0a89d2a3110d¶
The author used AI tools to help draft this document and to generate and cross-check its examples. The author reviewed the entire text and is responsible for it.¶
Citing adjacent work in the References does not imply that its authors endorse this document.¶
The requirements in Section 4 are drawn from the requirements note at the commit cited in Section 11. The illustrative cases in Appendix A were generated for this document; Section 11 separately identifies the sources of the reported measurement.¶
Reference verification. The references were checked against the published documents on 2026-10-10; re-check at submission time, including whether [I-D.ietf-scitt-scrapi] has been published as an RFC, and run idnits with network access.¶
List note. If the observation note behind Open Question 2 is published on the SCITT list before submission, add its archive link to the Implementation Status section.¶