]> b7n0de

kontakt@b7n0de.com

Security evaluation receipt DSSE in-toto SCITT COSE A Signed Evaluation Receipt records one evaluation result as signed payload bytes B. This document describes how existing envelopes cite such a receipt by the SHA-256 digest of B, and how a DSSE envelope carries B with the receipt's own signature. It fixes those bytes and a matching rule, maps the parts of a receipt onto DSSE, the in-toto Statement with the test-result predicate and the SLSA Verification Summary Attestation, shows that the signature of a receipt is already a valid DSSE signature, gives an example of a SCITT Signed Statement that names a receipt only by its digest, declares the receipt digest as an artifact type for typed digest references, and relates a receipt to a pre-run criteria set written in PRML. It defines no new format and no new predicate.

Introduction A Signed Evaluation Receipt (receipt) holds one assertion, whether a threshold held for a metric of a test suite, as payload bytes B. B is signed with Ed25519 over a pre-authentication encoding with a fixed type. A receipt carries no inclusion proof and does not prove registration with a Transparency Service. In SCITT, transparency additionally requires registering a Signed Statement that names the receipt and verifying the resulting SCITT Receipt (). Other parties will want to refer to a receipt from the envelopes they already use: a DSSE envelope, an in-toto Statement, a SLSA Verification Summary, or a SCITT Signed Statement. This document is the third part of one line of work: asks how a signed statement is named unambiguously, fixes the bytes of a receipt, and this document shows how existing envelopes cite such a receipt by digest. It also relates a receipt to a criteria set fixed before the run in PRML (), and says where it meets the requirements of for exchanging evaluation evidence (). This document defines no second receipt format, no new in-toto predicate and no new COSE header parameter. What a receipt does not prove stays unproven when an envelope cites it ().

Conventions and 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. The terms receipt, B, Issuer, Receiver and type are used as in . The type is the fixed string

The type identifies B ( Section 10.1). The receipt object uses the same fixed string as its schema discriminator, but is a different JSON representation.

Receipt digest:

SHA-256 over B ().

Citation:

A hash algorithm and a digest value that an envelope carries to name a receipt.

Citing envelope:

An in-toto Statement or a COSE Signed Statement that carries a citation. A DSSE envelope carries B itself, not a citation ().

The Receipt Digest

Definition The receipt digest is SHA-256 over B, the payload bytes of the receipt as defined in Section 3.4: the bytes that steps 1 to 3 of Section 5 obtain from payload_b64. A candidate for which one of those steps fails has no B, even if a lenient decoder would produce bytes from it (cases C6 and C7). It is not computed over the receipt bytes or over PAE(type, B). An envelope that carries the digest as text uses its 64 lowercase hexadecimal digits; one that carries it as bytes uses the 32 bytes. This document defines no other hash algorithm.

Why B The digest runs over B for two reasons. B is what is signed. The signing input PAE(type, B) depends on B alone, because the type is fixed ( Section 4.2). A digest over B therefore names exactly the signed content; a digest over the signing input would carry no further information. The receipt bytes are not stable. The receipt object around B is not canonicalized, and its key hint is not signed. Vectors P1, P4 and P6 of are three different receipt byte strings that all verify and all carry the same B (cases C1 to C3 of ). A digest over the receipt bytes would give one signed statement three names, and it would change whenever the receipt object is written again. In-toto resource descriptors and the COSE Hash Envelope each name content by the digest of its bytes, and a DSSE envelope carries the bytes themselves. The price of this choice: the receipt digest identifies the signed content, not the signature and not the key. Two receipts with the same B under different keys have the same digest. The iss and kid of a citing Signed Statement () identify its signer, which need not be the receipt signer. This mapping does not encode a constraint on the receipt signer. A Receiver verifies the cited receipt under the receipt key it fixed independently.

Matching Rule Given a citation and a candidate receipt, the result is computed as follows. If the citation's algorithm is not SHA-256, or its value is not 32 bytes (64 lowercase hexadecimal digits in text form), the result is INDETERMINATE. SHA-256 is named sha256 as the key of an in-toto digest set , -16 as the value of COSE header parameter 258, and sha-256 as the algorithm label of the examples (); each name counts only in its own carrier, and names are compared exactly, so SHA256 is none of them. A typed digest reference names it SHA-256 (). A digest set with several entries is matched on its sha256 entry alone; this document does not judge the other entries. This is narrower than the matching guidance of , under which two digest sets match if any acceptable field matches: here a digest set without a sha256 entry gives INDETERMINATE, and one whose sha256 entry passes step 1 but differs from SHA-256 over B gives NO_MATCH, whatever its other entries are. If steps 1 through 3 of Section 5 do not all complete successfully, including when processing stops at a resource limit, B is not obtained and the result is INDETERMINATE. Otherwise the result is MATCH when SHA-256 over B equals the cited value, and NO_MATCH when it does not. A MATCH establishes neither that the candidate verifies, nor who signed it, nor that its assertion is true. A Receiver that relies on a cited receipt runs the full procedure of Section 5 under a key it fixed. Case C5 is a candidate that matches and fails that procedure at step 11. Case Candidate Result Verification of the candidate What it shows C1 P1 MATCH PASS the receipt the citation was made from C2 P4 MATCH PASS other receipt bytes (an escaped character in schema), same B C3 P6 MATCH PASS other receipt bytes (no key hint), same B C4 P2 NO_MATCH PASS another receipt with another B C5 N7 MATCH FAIL, step 11 (profile 4) same B, signature made over another type: a match is not a verification C6 N13 INDETERMINATE FAIL, step 3 payload_b64 is not canonical base64: B is not obtained C7 N14 INDETERMINATE FAIL, step 1 the receipt has duplicate member names: B is not obtained C8 P1 INDETERMINATE PASS the citation names an algorithm this document does not define

Against the Identification Requirements proposes requirements A1 to A5 for references to signed statements. This section checks the receipt digest against them. It is the author's analysis, not a conformance claim; no registration in a Transparency Service is measured.

A1, unambiguous target and matching rule:

The scheme names the hash algorithm (SHA-256), the input bytes (B, as steps 1 to 3 of Section 5 obtain it from payload_b64) and the encoding (64 lowercase hexadecimal digits or 32 bytes). is the matching rule. An unsupported algorithm or a candidate without B gives INDETERMINATE, never MATCH (C6 to C8). Identity is preserved under every difference outside B that leaves steps 1 to 3 of Section 5 succeeding: the receipt's whitespace and escapes, its key hint, and its signature value. In the terms of Section 5 the receipt digest is a digest of the payload. Because the type is fixed and nothing else enters the signature, it also determines the signing input; neither names the signer.

A2, readable without interpreting the carrier's payload:

In the COSE Hash Envelope of the citation is read from header parameters 258 and 259 and the payload, as defines them, without interpreting application content. In an in-toto Statement the citation lies inside the predicate, which is the Statement's application content; a reader has to know the predicate to find it. A2 is met by the first and not by the second.

A3, matching independent of registration:

B does not change when the receipt is registered anywhere or its object is written again. Cases C2 and C3 carry other receipt bytes and still match.

A4, acceptance test for A3:

Cases C2 and C3 apply local changes that a re-encoding may cause (another JSON escape, a key hint left out), and the result stays MATCH. This is not a measurement of registration in two services.

A5, receipt-verification dependency:

Matching does not depend on a leaf hash or a COSE Receipt. A receipt has no inclusion proof of its own; a Transparency Service that registers a statement naming it fixes its own leaf construction, and matching does not use it.

Mapping to Existing Envelopes shows, for each part of a receipt, where it has a place in three envelopes and what that envelope does not have: DSSE , the in-toto Statement v1 with the test-result predicate v0.1 (test-result in the table), and the SLSA Verification Summary Attestation v1 (VSA). "None" means that the envelope has no field for it. This document defines no predicate of its own. Receipt part Envelope Field there, or what is missing B DSSE payload, base64 of B   test-result none; a Statement that restates the members is other bytes   VSA none; inputAttestations[].digest names B by its digest type DSSE payloadType   test-result none; the Statement's envelope carries an in-toto type   VSA inputAttestations[].mediaType signature.sig DSSE signatures[].sig, the same bytes (vector M1)   test-result none; the Statement's envelope carries a new signature   VSA none; the VSA is signed by its verifier signature.alg DSSE none; DSSE names no signature algorithm   test-result, VSA none signature.key DSSE keyid, optional and not signed   test-result, VSA none passed DSSE inside B   test-result result PASSED or FAILED; WARNED has no receipt counterpart   VSA none; verificationResult is the verifier's result payload schema DSSE inside B   test-result none; predicateType names test-result, not the payload schema   VSA none suite, suite_version DSSE inside B   test-result no field of its own; configuration or url can name the suite   VSA none metric, comparator, threshold, score, n DSSE inside B   test-result, VSA none criteria_digest, when present DSSE inside B   test-result, VSA none model_id_commit, dataset_id_commit, commit_alg DSSE inside B   test-result none; subject wants a digest of the artifact, and a commitment is not one   VSA none; subject and resourceUri name the verified artifact timestamp DSSE inside B   test-result none   VSA none; timeVerified is the verifier's time In the other direction, a receipt has no counterpart for the required VSA fields verifier, resourceUri, policy and verifiedLevels, for its optional timeVerified, or for the subject of an in-toto Statement.

DSSE The signature of a receipt is a valid DSSE signature without any new signature. DSSE signs PAE(payloadType, payload) with the same pre-authentication encoding that Section 4.1 defines. The envelope

, "payload": , "signatures": [{"sig": }]} ]]>

therefore verifies as DSSE under the Issuer's key when payloadType is exactly the type and payload decodes to B. Vector M1 () gives the bytes; its signature is the signature of vector P1 of , byte for byte. M1 leaves out keyid, which DSSE treats as an optional, unauthenticated hint. A successful DSSE signature check alone is not a receipt verdict. DSSE also requires a supported payloadType and parsing the authenticated payload according to that type. To obtain a receipt verdict, a Receiver decodes the payload and the selected signature once, uses those same bytes to construct the receipt object with canonical base64 as required by Section 3.1, and runs Section 5 under its independently selected receipt verification key. The signature is expected to be valid as DSSE only under this payloadType, because Ed25519 binds the exact signing input; this is not measured beyond sample types. Vector N7 of shows the converse for the receipt itself: its signature, made over PAE with the type application/vnd.example.other+json, fails under the fixed type.

in-toto Statement with test-result The test-result predicate records result (PASSED, WARNED or FAILED), configuration (a required list of resource descriptors), url, and the lists passedTests, warnedTests and failedTests. A Statement that restates a receipt maps passed to result PASSED or FAILED. No member of the predicate carries the metric, the comparator, the threshold, the score, the sample count or the timestamp; passedTests and failedTests are lists of test names, not a count. The Statement's subject names the tested artifact by digest; a commitment is not a digest of the artifact's bytes, so the model commitment cannot stand as subject without changing what subject means. Such a Statement is a new statement by whoever signs its envelope . It does not carry the receipt's signature and the predicate has no member for the evidence a result rests on. This document therefore does not cite receipts from test-result; the mapping states what a party loses when it restates a receipt in that form.

SLSA Verification Summary A Verification Summary Attestation states that a verifier verified an artifact against a policy. Its inputAttestations is a list of resource descriptors , each of which carries a digest of the attestation it names. A verifier that used a receipt as evidence when it verified an artifact, for example the evaluated model, and verified the receipt under Section 5, cites the receipt there; the artifact itself is the VSA's subject:

"}, "mediaType": "application/vnd.signed-evidence.eval-receipt+json"} ]]>

The mediaType identifies B. verificationResult is the verifier's result under its policy, not the receipt's passed: a receipt that verifies and records passed false (vector P2 of ) can be the input of a VSA whose verificationResult is PASSED, when the verifier's policy asks only for a valid receipt.

COSE and SCITT A Signed Evaluation Receipt is not a COSE Receipt. Its format is JSON with Ed25519 over PAE, not COSE; it carries no inclusion proof, and no Transparency Service or Registration Policy takes part in making it. In SCITT, a Transparency Service registers a Signed Statement and returns a COSE Receipt proving its inclusion. Two existing constructions carry the receipt digest without a new field: a typed digest reference () and a Signed Statement whose payload is the digest (). Both name the receipt; neither carries it.

A Typed Digest Reference Section 8 defines a typed digest reference with the members type, purpose, digest_alg and digest, and leaves the declaration of artifact types to the profiles that accept them ( Section 8.1). This document declares one artifact type for the receipt digest: type is application/vnd.signed-evidence.eval-receipt+json, the type, which identifies B; there is one digest context, so purpose is absent; the canonicalization algorithm is as-transmitted ( Section 4.4), with the byte-boundary selector Section 3.4, "The Bytes B"; the hash function is SHA-256, and digest_alg is exactly SHA-256; digest is the receipt digest as its 64 lowercase hexadecimal digits, a text value; in the cpb-refs header parameter of Section 8.3 it is a text string. A reference under this declaration can stand in the cpb-refs header parameter of a Signed Statement, or in a payload that carries references in its own serialization, for example in the references of . A verifier obtains B by steps 1 to 3 of Section 5, computes SHA-256 over it and compares the hexadecimal text. A candidate without B cannot be obtained as the cited artifact, which Section 8.1 calls Unresolved; it corresponds to INDETERMINATE in . A consuming profile that does not name this declaration by normative reference leaves every such reference Unresolved ( Section 8.1); no profile names it at the time of writing. Only the digest crosses, as for the Signed Statement below. A reference that is Verified shows that the cited bytes are B; it does not show that the receipt verifies, who signed it, or that its assertion is true ( Section 8.5).

A Signed Statement that Cites a Receipt A Signed Statement that cites a receipt is a COSE_Sign1 with CBOR tag 18 in the form of a COSE Hash Envelope . Its form is fixed, so that one receipt digest, one statement key, one issuer and one algorithm value give one byte string. Vector M2 () is such a statement. The protected header holds exactly these five parameters and no other: 1 (alg): -19, Ed25519 as fully specified in , or -8, EdDSA . A party that makes a statement MUST write -19. A Receiver MUST accept both values and applies every other check of to either; under the Ed25519 statement keys that step 3 selects, both values select the same signature algorithm. Changing alg changes the protected header bytes and requires a new signature (); 4 (kid): the COSE Key Thumbprint with SHA-256 of the statement key, a byte string of 32 bytes. For an Ed25519 public key x, kid is SHA-256 over the core-deterministically encoded COSE_Key map {1: 1, -1: 6, -2: x}; no optional COSE_Key parameter enters the thumbprint; 15 (CWT Claims) : a map with exactly 1 (iss), an absolute URI ( Section 4.3) that names the party that makes the statement, and 2 (sub), the text value of model_id_commit of B; 258 (payload hash algorithm): -16 (SHA-256); 259 (preimage content type): the type, as a text string. The unprotected header is the empty map. The payload is the receipt digest, 32 bytes. The COSE_Sign1, its protected header included, is encoded with the core deterministic encoding of Section 4.2.1. The value of sub is a choice of this example; the receipt digest does not depend on it. The statement key and the receipt key can be the same key or different keys. The statement carries its own signature over its own Sig_structure; it is not the receipt's signature, even when one key makes both. Registering M2 with a Transparency Service yields a COSE Receipt for M2, not for the evaluation receipt.

Making a Statement A party makes a statement for a receipt only after the receipt has passed the verification procedure of Section 5 under a key that party fixed. A receipt that fails it gives no statement. The party computes the receipt digest over B, takes sub from the model_id_commit of B, writes the protected header above, signs the Sig_structure of Section 4.4 with an empty external_aad under the statement key, and encodes the COSE_Sign1.

Checking a Statement The Receiver holds the statement, a candidate receipt, its independently selected receipt verification key, and configured pairs of an issuer URI and an Ed25519 statement key. The received iss value does not establish that association. It applies the following steps in order. The first step that fails gives the status named in it, and the statement is refused; only a statement that passes every step is accepted. A Receiver that stops because it reached a resource limit, in any step, reports a resource-limit error; that is no status, and the statement is not accepted. If the bytes are not one CBOR data item in the deterministic encoding, if the item is not a COSE_Sign1, or if its protected header is not a map in the deterministic encoding, the status is malformed. A data item that is well-formed but not valid under Section 5.3.1, such as a text string that is not valid UTF-8 or a map with duplicate keys, is malformed; two keys are duplicates only when they are equal under the key equivalence of Section 5.6.1, so the integer 1 and true are two keys and 0.0 and -0.0 are one. Step 1 does not check whether the content of a tag inside the COSE_Sign1 is valid for that tag ( Section 5.3.2); the data items inside a tag are checked like any other data item. For step 1, the COSE_Sign1 check concerns only the outer tag, the four-element array and its element types: a wrapping in a CBOR tag other than 18 is not a COSE_Sign1 and is malformed, and an otherwise valid COSE_Sign1 without a tag goes on to step 2 and is outside_profile there. The protected-header byte string is decoded as a CBOR map, with the empty byte string treated as an empty map ( Section 3), which fails in step 2. CBOR validity and deterministic encoding are checked before step 2. Header label types are checked only in step 2; a header label that is not one of the five required integer labels gives outside_profile if step 1 succeeds. If the item is not tagged 18, the unprotected header is not empty, the protected header does not hold exactly the five parameters above with the types and values given there, the payload is detached or is not 32 bytes, or the signature is not 64 bytes, the status is outside_profile. sub MUST be a text string matching sha256: followed by exactly 64 lowercase hexadecimal digits; otherwise the status is outside_profile. Step 7 then compares that string byte for byte with model_id_commit of B. A configured pair counts only if its statement key is 32 octets and its point A meets rules 1 and 2 of Section 4.4: A is a canonical encoding of a point of order L. A point of small order or of mixed order does not count. If no configured pair that counts has both an issuer URI exactly equal to iss and a statement key whose SHA-256 COSE Key Thumbprint equals kid, the status is untrusted_key. Subsequent signature verification uses only keys selected by this pairwise match. If the signature does not meet the four rules of Section 4.4 under a key that step 3 selected, with the Sig_structure of Section 4.4 in place of PAE(type, B) in rule 4, the status is signature_invalid. Run the verification procedure of Section 5 under the Receiver's receipt key. Continue to step 6 only if it returns PASS. If it returns FAIL, the status is receipt_not_verified. If it stops with a resource-limit error, propagate that error and stop without accepting the statement. If the payload is not the receipt digest of the candidate, the status is digest_mismatch. If sub is not the model_id_commit of B, the status is subject_mismatch. If every step passes, the status is accepted. Steps 1 to 4 do not use the receipt. A general COSE verifier that implements the statement's alg value checks the signature under the rules of its own Ed25519 implementation, which can accept a signature that step 4 refuses, for example one whose R is a point of small order. It does not apply steps 5 to 7, and its success does not show that the statement cites a receipt that verifies.

What Crosses and What Is Lost Receipt Signed Statement B only its receipt digest, as the payload model_id_commit of B sub (2) of the CWT Claims the type parameter 259 the other members of B (schema, suite, suite_version, metric, comparator, threshold, score, passed, n, dataset_id_commit, commit_alg, timestamp), including criteria_digest when present not carried; named only through the digest the receipt's signature and its key hint not carried (none) iss, kid and alg, the statement of the party that signs it A Receiver that relies on the assertion of a receipt needs the receipt itself; the statement only names it.

Choice of alg Value -19 is the fully specified Ed25519 identifier of , which sets the polymorphic EdDSA identifier -8 of to Deprecated. A party that makes a statement therefore writes -19 only. Every Receiver accepts -8 as well, for statements made before a producer moved to -19 and for general COSE verifiers that implement -8 but not -19 (), so that one statement gives one status. -8 names EdDSA for any curve; step 3 of counts only Ed25519 statement keys, so a statement with -8 under any other key is untrusted_key. The payload follows the pattern of the hash-only mode of : the 32 raw octets of a SHA-256, carried as a byte string and not as hexadecimal text. That profile leaves open how a verifier tells such a payload from a full one, and names a COSE header parameter that declares the digest algorithm as one candidate. Header parameters 258 and 259 of , used here, are such a declaration.

Criteria Sets in PRML PRML serializes an evaluation claim fixed before the run: a metric, a comparator, a threshold, a dataset content hash and a seed, in canonical YAML whose SHA-256 is the manifest hash. A receipt records one result after the run. A receipt names a criteria set at most through its optional criteria_digest ( Section 3.5). When the criteria set is a PRML manifest, the bytes that PRML fixes for it are its canonical bytes, whose SHA-256 is the manifest hash, and criteria_digest over them is sha256: followed by the manifest hash. maps the members of a PRML manifest, version 0.1, onto a receipt. PRML Receipt Lost or changed version none which PRML rules apply claim_id none the claim and its amendment chain; only one manifest is named, by criteria_digest created_at none timestamp is when the Issuer states the evaluation ran, not when the criteria were written metric metric nothing when the string is copied exactly comparator comparator == has no counterpart; such a claim has no receipt threshold threshold a number becomes a decimal string; the rule below compares values dataset.id, dataset.hash dataset_id_commit the content hash; the receipt commits to an identifier with a salt, not to the content seed none the seed producer none the producer; the receipt names no issuer, the Receiver fixes the key model model_id_commit the clear identifier; checking an opening requires the salt and identifier prior_hash, metric_args, code, notes none all of them none suite, suite_version, score, passed, n, timestamp a manifest has no result A Receiver that holds a receipt and a PRML manifest compares them as follows and reports the two results separately. Run the procedure of Section 5 under the Receiver's receipt key. Continue only if it returns PASS. If it returns FAIL, do not perform the comparison. If it stops with a resource-limit error, propagate that error and stop without reporting binding or agreement results. The manifest is canonicalized as Section 3 requires, and its manifest hash is computed. A manifest that PRML rejects is not compared. Binding. The result is BOUND when the receipt carries criteria_digest and it equals sha256: followed by the manifest hash, and UNBOUND otherwise. Agreement. The result is AGREE when metric is the same string in both, comparator is the same and is not ==, and the receipt's threshold and the manifest's threshold are the same decimal number, the manifest's value read as the decimal that its canonical rendering denotes (so 0.8 in the manifest and 0.800 in the receipt agree, and 0.80000000000000001 in the receipt does not). Otherwise it is DIFFER. BOUND says that the Issuer states this result belongs to that manifest; AGREE says that the two documents state the same metric, comparator and threshold. Neither result shows that the manifest existed before the run, which needs a time-anchored record of the manifest, such as a registration under , and evidence of when the run began. Neither shows that the dataset with the manifest's content hash was the one evaluated, or that the seed was used.

Relation to Claim-Preservation Requirements states format-neutral requirements for converting and consuming evaluation evidence. This document addresses parts of these requirements for the conversions it describes; the correspondences below are not a conformance claim. and name what each envelope or document loses, in the sense of its requirement R-CP-9. gives INDETERMINATE when B cannot be obtained or the algorithm is unknown, never a match (R-CP-8, R-CP-10). keeps the result of a verifier or of a registration apart from the receipt's passed, and claims no order of criteria and run (R-CP-5, R-CP-11). It does not meet the requirements on coverage and attempts (R-CP-6) or on records of a mapping instance (R-CP-1): a receipt has no field for them, and this document defines none.

What Is Not Proven The list of Section 6 applies unchanged to a cited receipt. It is repeated here word for word; its one cross-reference is written as a reference to Section 5 of . Verification establishes that the receipt passes the format, consistency and signature checks in Section 5 of under the Receiver's selected key. It does not establish that the Issuer's claims are true. In particular: The score can be false. The evaluation can be wrong, badly designed or not run at all; the receipt records what the Issuer states. The run need not have been the only run. An Issuer can evaluate many times and record only the run it prefers. The Issuer can lie. A valid signature binds the statement to the key, not to the truth. A receipt does not show that it was published, logged or shown to anyone else. A receipt does not prove registration with a Transparency Service. In SCITT, transparency additionally requires registering a Signed Statement carrying the receipt or its digest with a Transparency Service and verifying the resulting SCITT Receipt. Registration and verification of the resulting SCITT Receipt are outside this document. The receipt bytes are not a stable name for the receipt. Only B is signed; the receipt object around it is not canonicalized, and its key hint can be present or absent. A party that cites a receipt cites SHA-256 over B. A commitment is computationally binding under the collision resistance of SHA-256. A Receiver can check a claimed opening only after receiving the salt and identifier. Hiding depends on keeping an unpredictable salt secret. The timestamp is the Issuer's statement, not a time attested by another party. The receipt says nothing about individual samples: n is the Issuer's statement, and no sample result is committed or can be disclosed against the receipt. A sample-level audit is outside this document and is left to a separate document. A receipt does not show that the threshold was fixed before the run. criteria_digest binds only the Issuer's statement that this result belongs to the criteria set with that digest. It shows neither that the criteria set existed before the run nor that the metric, comparator and threshold in it equal those in the receipt. Even with salt and identifier disclosed, the receipt does not show that the named model or dataset was the one actually evaluated. Each envelope adds what it does not prove: A citation. A MATCH does not show that the candidate verifies, who signed it, or that its assertion is true (case C5). The digest names B; it names neither a signature nor a key. DSSE. A successful DSSE signature check authenticates PAE(type, B) under the selected key. A receipt verdict additionally requires the verification profile and all checks of Section 5. The unauthenticated keyid is only a key-selection hint. in-toto test-result. A Statement that restates a receipt is the statement of its signer. It does not show that a receipt exists, and its result does not show that the receipt's passed is true; both are statements. SLSA VSA. A VSA shows that its verifier states that it verified its subject under its policy, with the cited receipt among its inputs. verificationResult is not passed, and the VSA does not make the receipt's assertion true. The digest in inputAttestations names B, not the signature or the key the verifier used. SCITT Signed Statement and COSE Receipt. The Hash Envelope carries only the digest. Its registration shows that a Transparency Service registered a statement naming that digest under its Registration Policy. It does not show that a receipt with that B exists or that it verifies, and sub binds nothing beyond the commitment it repeats. Typed digest reference. A Verified reference shows that the cited bytes are B, nothing about the signature, the key or the assertion. PRML. BOUND and AGREE () do not show that the criteria were fixed before the run. No envelope in this document carries sample data: a receipt commits to no sample result ( Section 6), and a citation names only B.

Security Considerations This section follows the guidance of . The attacker can read, create, modify, replay and reorder receipts and citing envelopes, and controls every input except the Receiver's choice of verification key. Collisions. A citation names B only as well as SHA-256 resists collisions and second preimages. Signer not bound. The receipt digest does not name a key. An attacker who signs the same B with its own key produces a receipt that matches every citation of B. It fails verification under the Receiver's key (). Signature reuse across envelopes. By design the signature of a receipt is a valid DSSE signature under payloadType equal to the type (). A DSSE consumer that accepts that payloadType holds the B and the signature of a receipt, and applies Section 5 before it relies on them. Under any other payloadType the signature is expected to be invalid (). It is not a COSE signature, because COSE signs a Sig_structure and not PAE. Digest confusion. For one receipt, the receipt digest, the SHA-256 of the receipt bytes and the SHA-256 of a DSSE envelope are three different values. A Receiver compares only the receipt digest with a citation. lists the first two for vector P1 and the third for M1. The type identifies B, but a receipt object carries the same string as its schema: a Receiver that fetches a receipt object for a citation takes B from it by steps 1 to 3 of Section 5 and compares the digest of that B, never the digest of the object. Algorithm. Only SHA-256 is defined. A citation with another algorithm gives INDETERMINATE (case C8), so it cannot be satisfied by a weaker digest.

Privacy Considerations The receipt digest lets anyone who holds a candidate B confirm it. B carries salted commitments, so B cannot be guessed without them; a party that knows them can test guesses for the remaining members, such as score and threshold. A citation registered with a Transparency Service publishes the digest for as long as that service keeps its log. The sub of M2 repeats the model commitment of B in clear; registered, it links every receipt and statement that commit to the same model identifier with the same salt ( Section 9). The same holds for a criteria_digest that a receipt carries.

IANA Considerations This document has no IANA actions.

Implementation Status This section records the status of known implementations at the time of writing, following , and is to be removed before publication. The examples of were produced by a generator script whose two runs are byte-identical, and checked by a separate script that re-derives every value of from the bytes, including the match result of every case, with its own implementation of steps 1 to 3 of Section 5. An implementation of both directions of , the open-source package proofbundle (module receipt_cose, experimental), reproduces M2 byte for byte from vector P1 of and returns each status of for a set of 49 statements and 6 receipts. It writes -19 only and reads -8 only under an Ed25519 statement key. Measured on 2026-10-08 with these pinned versions: pycose 1.1.0 (with cbor2 5.9.0) and go-cose v1.3.0 verified the statement with alg -8, refused the same statement with one signature bit changed, and reported alg -19 (vector M2) as an unknown algorithm; microsoft/scitt-verifier 0.4.0 evaluated the signature of neither statement (its result for both was cannot-evaluate, with the statement signature not evaluated). The signature of M2 (alg -19) is checked from the text alone, without a COSE library: a script written from the texts of this document and of builds the Sig_structure by hand and verifies the signature over it with a general Ed25519 implementation (its checks M2-17 and M2-18).

Secure Systems Lab in-toto project in-toto project in-toto project OpenSSF SLSA project in-toto project in-toto project

Examples The values below are derived from vectors of (P1, and the candidates named in ) and from the issuer test key of that document, whose seed is given there; the issuer URI of the Signed Statement is a constant of this example. PURE TEST KEY. It MUST NOT be used for anything real.

Constants Type:

Issuer test key, public key (base64 and hex):

Issuer URI of the Signed Statement (iss):

Digests of Vector P1 B, 458 bytes (hex):

Receipt digest, SHA-256 over B:

SHA-256 over the receipt bytes of P1; not the receipt digest:

Citation Cases Every case cites B of P1. Cases C1 to C7 cite, with the algorithm sha-256, the receipt digest given in . C8 cites, with the algorithm sha-512, this value over the same B:

The candidates are the vectors of named in , whose bytes are given there. Case and SHA-256 over the candidate's receipt bytes:

The expected results are those of ; the reasons are: C1: SHA-256 over the candidate's B equals the cited digest. C2: SHA-256 over the candidate's B equals the cited digest. C3: SHA-256 over the candidate's B equals the cited digest. C4: SHA-256 over the candidate's B differs from the cited digest. C5: SHA-256 over the candidate's B equals the cited digest. C6: B not obtained, step 3 of Section 5 fails. C7: B not obtained, step 1 of Section 5 fails. C8: Citation algorithm not defined.

M1, DSSE Envelope with the Receipt's Signature The envelope is a JSON object with the members payloadType, payload and signatures, serialized without insignificant whitespace and with members sorted by name. Its only signature is signature.sig of P1, unchanged; it verifies as Ed25519 over PAE(payloadType, payload) under the issuer test key. PAE(type, B), 522 bytes (hex):

Envelope, 806 bytes (hex):

SHA-256 over the envelope bytes; not the receipt digest:

M2, SCITT Signed Statement Citing the Receipt by Digest A COSE_Sign1 with CBOR tag 18 in the form of a COSE Hash Envelope. The protected header holds these parameters, in this order: 1 (alg): -19 4 (kid): a 32-byte string, given below 15 (CWT Claims): a map with 1 (iss), the URI of , and 2 (sub), the text string given below 258 (payload hash algorithm): -16 259 (preimage content type): the type, as a text string kid, the COSE Key Thumbprint (SHA-256) of the issuer test key (hex):

sub, the model commitment of B:

Protected header, 202 bytes (hex):

The unprotected header is the empty map. The payload is the receipt digest given in . Sig_structure (ToBeSigned), 251 bytes (hex), with external_aad the empty byte string:

Signature, Ed25519 over the Sig_structure (hex):

COSE_Sign1, 307 bytes (hex):

SHA-256 over the COSE_Sign1 bytes:

Open Items (to be removed before publication) References. The in-toto references are pinned to release v1.2.0 of the in-toto Attestation Framework. The draft names of and are to be updated once those documents are published. The artifact-type declaration of is named by no consuming profile yet.