]> b7n0de

Germany 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 a SCITT Signed Statement that names a receipt only by its digest, in a key profile and a certificate profile, 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. For the JSON representation in , first apply that section's extraction rule; it either gives INDETERMINATE or supplies the algorithm and value for the steps below. The matching result is independent of the typed reference's processing state.

1. 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 (). The value is 64 lowercase hexadecimal digits in text form in a digest set (), in a typed digest reference () and in the examples (), and 32 bytes as the payload of a statement whose parameter 258 is -16 (). 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.
2. 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.
3. 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. Citation cases

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.

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 parts in three envelopes

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 context has no purpose label, so a well-formed reference that carries purpose is Unresolved ( Section 8.1);
• 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.

For the JSON representation defined here and used in , a reference is one JSON object with the required members type, digest_alg and digest, and the optional member purpose. Each of these members, when present, has a JSON string value. No other member is allowed. Member names of this object are compared after JSON string unescaping, without case folding or Unicode normalization; repeated names are detected before any conversion that could discard them. Input that violates the JSON grammar, is not an object, has a repeated member name, lacks a required member, has a non-string value for one of the named members, or has another member is Malformed ( Section 3). A byte order mark before the JSON text is not part of the JSON grammar, so such input is Malformed, although Section 8.1 allows a parser to ignore it. This form check precedes reference resolution and verification. The rules assigning Unresolved, Failed or Verified apply only to well-formed references. These form requirements define this JSON representation; they do not replace the rules for cpb-refs or another profile's own serialization. For this JSON representation, the independent matching result of is INDETERMINATE unless the input conforms to the JSON grammar, its top-level value is an object, and that object contains exactly one digest_alg member and exactly one digest member, both with string values. Otherwise applies to those two values regardless of the reference state. No occurrence is chosen from repeated digest_alg or digest members, even if their values agree, and non-string values are not converted to strings. A matching result does not change the reference state or make a Malformed reference Verified. 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 . For a well-formed reference, context selection and verification follow Section 8.1. A consuming profile that does not name this declaration by normative reference leaves a well-formed reference to it Unresolved; no profile names it at the time of writing. Once this digest context has been selected, a digest_alg other than SHA-256 or a digest outside the declared text representation of 64 lowercase hexadecimal digits makes the reference Failed. gives INDETERMINATE for either case. After those checks, a verifier obtains B by steps 1 to 3 of Section 5. If B is not obtained, the reference is Unresolved and the matching result is INDETERMINATE. Otherwise the verifier computes SHA-256 over B and compares its hexadecimal text with digest: equality gives Verified and MATCH, and inequality gives Failed and NO_MATCH. Vectors R1 to R14 () illustrate these states and Malformed. 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 . It has one of two profiles, which differ in how the statement names its signer. In the key profile, kid names an Ed25519 statement key that the Receiver has configured for the issuer. In the certificate profile, the protected header carries an X.509 certificate chain whose last certificate is a trust anchor that the Receiver has configured for a did:x509 issuer . The labels of the protected header select the profile (step 2 of ). Vector M2 () is a statement in the key profile, vector X1 one in the certificate profile. Both profiles share these rules:

• The protected header holds exactly the parameters of its profile, given below, and no other. Three of them are the same in both profiles:
  • 15 (CWT Claims) : a map with exactly 1 (iss), whose form each profile gives, 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.

Key profile. The protected header holds exactly the five parameters 1, 4, 15, 258 and 259:

• 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): iss is an absolute URI ( Section 4.3) that names the party that makes the statement.

Its form is fixed, so that one receipt digest, one statement key, one issuer and one algorithm value give one byte string. Certificate profile. The protected header holds exactly the six parameters 1, 4, 15, 33, 258 and 259:

• 1 (alg): -7, ECDSA with SHA-256 ( Section 2.1); the signature is r and s, 32 bytes each, under the P-256 public key of the leaf certificate ();
• 4 (kid): SHA-256 over the DER encoding of the SubjectPublicKeyInfo of the leaf certificate, a byte string of 32 bytes;
• 15 (CWT Claims): iss is a did:x509 identifier of exactly the form did:x509:0:sha256: F ::eku: O, where F is SHA-256 over the DER bytes of the last certificate of x5chain, encoded in base64url without padding (43 characters), and O is an object identifier in dotted decimal form: the first arc is 0, 1 or 2, it is followed by one or more further arcs, the second arc is at most 39 when the first arc is 0 or 1, the arcs are separated by full stops, and each arc is a decimal number without leading zeros;
• 33 (x5chain) : an array of exactly two byte strings, each a DER-encoded X.509 certificate : first the leaf certificate, whose P-256 public key verifies the statement signature, then the trust anchor certificate, whose RSA public key signed the leaf certificate with sha256WithRSAEncryption (RSASSA-PKCS1-v1_5 with SHA-256, ).

This profile names one trust anchor and no intermediate certificate. The profile is limited to this form, two certificates with an RSA trust anchor, because it is the form measured to work (). An x5chain array with more or fewer than two elements, an x5chain that is a single byte string, and an iss with a predicate other than one eku give outside_profile in step 2 of . Certificate contents, key restrictions and their bindings are checked in step 3, which gives untrusted_key when one of those checks fails. An ECDSA signature depends on a per-signature nonce, so one statement in this profile can have more than one byte string; the vectors use the deterministic nonce of , which a Receiver does not check. The value of sub is a choice of this example; the receipt digest does not depend on it. The key that signs a statement 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 or X1 with a Transparency Service yields a COSE Receipt for that statement, 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 of one profile, signs the Sig_structure of Section 4.4 with an empty external_aad, under the statement key in the key profile and under the private key of the leaf certificate in the certificate profile, 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. A pair for the key profile is an issuer URI with an Ed25519 statement key; a pair for the certificate profile is a did:x509 identifier with a trust anchor certificate. The received iss value does not establish either 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.

1. 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. For the choices that Section 4.2.2 leaves to a protocol, step 1 uses these: a NaN is in the deterministic encoding only as the half-precision quiet NaN 0xf97e00, and any other encoding of a NaN is malformed; no tag, the bignum tags 2 and 3 included, adds a rule of its own. 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 a label of either profile gives outside_profile if step 1 succeeds.
2. A Transparent Statement carries COSE Receipts in its unprotected header under label 394. If the unprotected header holds label 394 and no other label, and the value of 394 is an array of one or more byte strings, the Receiver removes label 394 and applies the rest of this step and the following steps with the empty unprotected header; the protected header, the payload and the signature stay as they are. These steps do not read the receipts. The labels of the protected header select the profile: exactly the integer labels 1, 4, 15, 258 and 259 select the key profile, and exactly the integer labels 1, 4, 15, 33, 258 and 259 select the certificate profile. If the item is not tagged 18, the unprotected header is not empty, or the labels select neither profile, the status is outside_profile. In both profiles, kid is a byte string of 32 bytes; 15 is a map with exactly the integer labels 1 (iss) and 2 (sub), both text strings; 258 is the integer -16; and 259 is the type as a text string. In the key profile, alg is the integer -19 or -8, and iss is an absolute URI. In the certificate profile, alg is the integer -7, iss has the syntactic form given in , and x5chain is an array of exactly two byte strings. This step checks only the syntax of iss and the container form of x5chain; the certificate contents, key properties, and the bindings of iss and kid are checked in step 3. A violation of these structural rules, a detached payload, a payload that is not 32 bytes, or a signature that is not 64 bytes gives outside_profile. sub MUST match sha256: followed by exactly 64 lowercase hexadecimal digits; otherwise the status is outside_profile. Step 7 compares sub byte for byte with model_id_commit of B.
3. Key profile. 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. Certificate profile. A configured pair counts only if its identifier is exactly equal to iss, its trust anchor certificate is byte for byte the second certificate of x5chain, and F of iss is SHA-256 over that certificate. The status is untrusted_key if no configured pair counts, or if any of the following does not hold: both certificates are DER-encoded X.509 certificates; the public key of the trust anchor is an RSA key with a modulus of at least 2048 bits; the leaf certificate is signed by that key with sha256WithRSAEncryption; the issuer name of the leaf certificate is byte for byte the subject name of the trust anchor; the extended key usage of the leaf certificate contains O of iss; the public key of the leaf certificate is a P-256 key; and kid is SHA-256 over its SubjectPublicKeyInfo. This step is not certification path validation ( Section 6) and does not resolve iss as a DID: it evaluates no validity period, revocation status, name constraint, certificate policy or other extension. requires path validation for resolution. An application that additionally performs path validation reports its result separately from the status of this procedure and may refuse to use a statement whose status is accepted.
4. Key profile. 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. Certificate profile. Read r and s as unsigned big-endian integers from the first and the last 32 bytes of the signature. If r or s is not in the range 1 to n-1, where n is the order of the P-256 base point, or the signature is not a valid ECDSA signature with SHA-256 over the Sig_structure under the public key of the leaf certificate, the status is signature_invalid.
5. 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.
6. If the payload is not the receipt digest of the candidate, the status is digest_mismatch.
7. If sub is not the model_id_commit of B, the status is subject_mismatch.

If every step passes, the status is accepted. Vector M2 with vector P1 of is accepted, and gives a statement for each other status. Vector X1 with P1 is accepted under the certificate pair of , and X2 to X6 fail at steps 2, 3 and 4 in the certificate profile. Vectors T1 to T5 () are Transparent Statements: T1 and T2 are accepted, and T3 to T5, whose unprotected headers hold more than the receipts or the receipts in another form, are outside_profile. Steps 1 to 4 do not use the receipt. For the key profile, 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. For either profile, a COSE signature check alone 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 What a Signed Statement carries of a receipt

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, alg and, in the certificate profile, x5chain: 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 In the key profile, 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. Vector S1 () is M2 with alg -8, signed again under the same key; it is accepted. The certificate profile fixes -7. also sets -7 to Deprecated and registers -9 (ESP256) for ECDSA with SHA-256 on P-256. The certificate profile does not admit -9: the Transparency Service measured in refuses a statement with -9 at registration, also when its configuration names ESP256, and neither the offline verifier nor the two general COSE libraries named there implement -9. A statement with -9 is outside the certificate profile (vector X2). -7 does not name a curve; step 3 counts only a P-256 leaf key, so -7 selects one signature algorithm here. 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. A PRML manifest and 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.

1. 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.
2. The manifest is canonicalized as Section 3 requires, and its manifest hash is computed. A manifest that PRML rejects is not compared.
3. Binding. The result is BOUND when the receipt carries criteria_digest and it equals sha256: followed by the manifest hash, and UNBOUND otherwise.
4. 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.
• A receipt does not show where B came from. B carries no reference to another receipt or record that it was made from, for example when an Issuer translates the result of another format into a receipt; this format has no member for it.

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. A MATCH alone does not establish that the reference is well formed or that its digest context has been resolved.
• 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. Reference parsing. For the JSON representation in , duplicate detection precedes any conversion that could discard member names. Selecting a first or last occurrence can change the reference state or matching result. A MATCH is not a substitute for Verified: a Malformed, Unresolved or Failed reference is not relied on as evidence of a content binding ( Section 8.1). Receipts not read. Step 2 of removes the receipts of a Transparent Statement without reading them; vector T1 carries a receipt made for another statement and is accepted. An accepted status therefore says nothing about registration. A Receiver that relies on registration verifies each receipt under with a Transparency Service key that it fixed itself. It fixes the key, not the issuer name in the receipt: two instances of a Transparency Service can carry the same issuer name and differ only in their keys (). Digest not checked by registration alone. The Signed Statement carries a digest, not B. Registration under a Transparency Service's policy does not by itself establish that the payload equals SHA-256 over B; records the registration of a statement whose payload was not that digest. The Receiver recomputes the receipt digest in step 6 of . Configured trust. A Receiver trusts a statement key or a trust anchor because it configured it. In the certificate profile, the procedure checks the leaf under the configured anchor but evaluates no validity period or revocation status. A compromised leaf key can therefore continue to pass this procedure while the configured pair remains. Additional path validation or other acceptance policy can refuse its use separately. Removing a configured pair makes statements that would pass step 2 and whose only matching pair was removed fail at step 3 with untrusted_key.

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: the match result of every case, with its own implementation of steps 1 to 3 of Section 5; the status of M2, of every status vector and of every certificate-profile vector, with its own implementation of the steps of in both profiles; and the state and the matching result of each of R1 to R14, with its own implementation of the form rules of . An implementation of both directions of the key profile 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. M2 and the status vectors of are, byte for byte, statements of that set, made independently by the generator of . 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 certificate profile and the typed digest references of are implemented only by the scripts of . Registration with a Transparency Service was measured on 2026-10-10 with a local instance of microsoft/scitt-ccf-ledger at commit 00101f76 (CCF 7.0.17, virtual mode); no hosted service took part. No statement in the exact form of the key profile was registered: the service refused its https issuer ("CWT_Claims issuer is unsupported") with alg -19 and with alg -8, and, under a did:x509 issuer with x5chain, refused alg -19 ("COSE algorithm -19 is not supported") and an Ed25519 key with alg -8 ("Unsupported key type"). A statement in the form of the certificate profile, with an RSA-3072 test root, a P-256 test leaf and alg -7, was registered, and microsoft/scitt-verifier 0.4.0 verified the Transparent Statement it returned offline, with the network unavailable, under a policy that fixed the receipt issuer, the statement issuer and the statement subject and compared the payload with SHA-256 over B. On 2026-10-12 the same service, built again at commit 00101f76 and configured for the test root, registered X1 again and refused X2, which is X1 with alg -9 signed again under the test leaf, with "COSE algorithm -9 is not supported", also when ESP256 was named among its accepted algorithms; its source at that commit and at commit d68579b5, the head of its main branch inspected that day, maps no -9. pycose 1.1.0 and go-cose v1.3.0 refused -9 as an unknown algorithm before verifying, and the source of microsoft/scitt-verifier at commit bd6fb8ba (package version 0.4.0) maps no -9 for the statement signature. The steps of , applied on 2026-10-11 to the registered statement under the certificate pair of its test root, give accepted, and so they do for the Transparent Statement that the service returned for it. In the earlier registration and offline-verification measurement, the service registered a statement whose payload was not SHA-256 over the B it named, and two local instances of the service carried the same receipt issuer name (127.0.0.1:8000) and differed only in their service keys. microsoft/scitt-verifier 0.4.0 reported a receipt taken from another entry, a receipt with one byte changed and a receipt of the other instance as cannot-evaluate (exit status 3), not as untrusted (exit status 1); this document maps no verdict of another tool to a status of . scitt-verifier 0.4.0 did not anchor a chain whose leaf certificate was signed with ECDSA (exit status 3) and verified the chain with an RSA root. Vector T2 is the Transparent Statement that a local instance of the same service returned on 2026-10-11 for X1: X1 with one receipt under label 394, byte for byte. 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).

References Normative References Secure Systems Lab in-toto project in-toto project in-toto project OpenSSF SLSA project n.d. Informative References in-toto project in-toto project

Examples The values below are derived from vectors of (P1, and the candidates named in and ) 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:

Status Vectors Each vector is a Signed Statement presented with a candidate receipt of , whose bytes are given there. The Receiver's receipt key is the issuer test key, and its one configured pair is the issuer URI of with the issuer test key. With M2, the vectors give one statement for each status of ; S1 is the statement with alg -8 that every Receiver accepts (). Status vectors

Vector	Candidate	Status	First failing step
M2	P1	accepted	(none)
S1	P1	accepted	(none)
S2	P1	malformed	1
S3	P1	outside_profile	2
S4	P1	untrusted_key	3
S5	P1	signature_invalid	4
S6	N7	receipt_not_verified	5
S7	P1	digest_mismatch	6
S8	P1	subject_mismatch	7

What each vector shows:

• M2: the statement of , with the receipt it was made from.
• S1: M2 with alg -8 in place of -19, signed again under the issuer test key.
• S2: the bytes of M2 with CBOR tag 98 (COSE_Sign) in place of tag 18.
• S3: alg -7 (ES256), signed again under the issuer test key.
• S4: kid names the foreign test key, which signs it; no configured pair has that key.
• S5: kid names the issuer test key, the foreign test key signs it.
• S6: M2, presented with N7, which fails step 11 of Section 5.
• S7: a statement on B of P2, with sub its model commitment, presented with P1.
• S8: M2 with sub the dataset commitment of P1, signed again.

S4 and S5 are signed by a foreign test key whose seed is SHA-256 over the UTF-8 bytes of "receipt-cose foreign statement key, PURE TEST KEY"; it MUST NOT be used for anything real. Its public key (base64 and hex): S1, 307 bytes (hex): S2, 308 bytes (hex): S3, 307 bytes (hex): S4, 307 bytes (hex): S5, 307 bytes (hex): S6, 307 bytes (hex): S7, 307 bytes (hex): S8, 307 bytes (hex): Vector and SHA-256 over its bytes:

Typed Digest References Each vector supplies an input to the typed digest reference processing of . R1 is a JSON object with exactly three members: type, the type; digest_alg, SHA-256; and digest, the receipt digest of as 64 lowercase hexadecimal digits. Each other vector is R1 with the change in ; "names B of P2" means SHA-256 over B of vector P2 of , as 64 lowercase hexadecimal digits. The candidate is the vector of named in the table. For State, assume a consuming profile that accepts the declaration in by normative reference. State is the reference processing state in the terms of Sections 3 and 8.1. Matching rule is the independent result of , including the JSON extraction rule in . Typed digest references

Vector	Change to R1	Candidate	State	Matching rule
R1	(none)	P1	Verified	MATCH
R2	purpose evaluation added	P1	Unresolved	MATCH
R3	digest_alg sha-256	P1	Failed	INDETERMINATE
R4	digest in uppercase	P1	Failed	INDETERMINATE
R5	digest names B of P2	P1	Failed	NO_MATCH
R6	(none)	N13	Unresolved	INDETERMINATE
R7	member x added, value 1	P1	Malformed	MATCH
R8	second digest member, names B of P2	P1	Malformed	INDETERMINATE
R9	digest_alg removed	P1	Malformed	INDETERMINATE
R10	R1 as the only element of a JSON array	P1	Malformed	INDETERMINATE
R11	purpose added, value null	P1	Malformed	MATCH
R12	sole digest name written as "\u0064igest"	P1	Verified	MATCH
R13	second name "\u0064igest", same value	P1	Malformed	INDETERMINATE
R14	R1 preceded by the UTF-8 byte order mark	P1	Malformed	INDETERMINATE

What each vector shows:

• R1: a reference under the declaration, with the receipt it names.
• R2: R1 with a purpose member; the context has no purpose label.
• R3: R1 with digest_alg sha-256, not the exact token SHA-256.
• R4: R1 with the digest in uppercase hexadecimal digits.
• R5: a reference that names B of P2, presented with P1.
• R6: R1 presented with N13, from which B is not obtained.
• R7: R1 with a member that the declaration does not name.
• R8: R1 with a second digest member that names B of P2; neither value is chosen.
• R9: R1 without digest_alg.
• R10: R1 inside a JSON array, which is not a JSON object.
• R11: R1 with purpose set to null, not a JSON string. Unlike R2, this is a form error before context selection.
• R12: R1 with the sole digest member name written as "\u0064igest" in the JSON text; the decoded name is unchanged.
• R13: R1 with an additional member named "\u0064igest" whose value equals the original digest. The decoded names are equal; equal values do not make a repeated name acceptable.
• R14: R1 with the UTF-8 byte order mark EF BB BF before the JSON text; this representation does not ignore it.

The matching rule compares an unambiguously extracted algorithm and digest independently of the reference state. Thus R2 gives MATCH while Unresolved, and R7 and R11 give MATCH while Malformed. Neither result makes the reference Verified.

Certificate-Profile Vectors Each vector is a Signed Statement in the form of the certificate profile, or one change away from it, presented with vector P1 of . The Receiver's receipt key is the issuer test key, and its one configured certificate pair is the did:x509 identifier below with the test root certificate. The test root holds an RSA-3072 key and the test leaf a P-256 key; both certificates, and the other P-256 key that signs X6, are test material made by the generator of , and they MUST NOT be used for anything real. The signatures use the deterministic nonce of . iss of X1, the identifier of the configured pair, is did:x509:0:sha256: F ::eku: O with F, SHA-256 over the test root certificate in base64url without padding, and O, the object identifier of code signing: Test leaf certificate, 819 bytes (hex): Test root certificate, the trust anchor of the configured pair, 1120 bytes (hex): SHA-256 over the test leaf and over the test root certificate: kid of X1, SHA-256 over the SubjectPublicKeyInfo of the test leaf (hex): The protected header of X1 holds these parameters, in this order:

• 1 (alg): -7
• 4 (kid): the kid above
• 15 (CWT Claims): a map with 1 (iss), the identifier above, and 2 (sub), the sub of
• 33 (x5chain): an array of the test leaf and the test root certificate
• 258 (payload hash algorithm): -16
• 259 (preimage content type): the type, as a text string

The unprotected header is the empty map, and the payload is the receipt digest of . X1, 2313 bytes (hex): Each of X2 to X6 is a COSE_Sign1 with tag 18 whose protected header is the deterministic encoding of the protected header of X1 with the change below, whose unprotected header is the empty map, whose payload is that of X1, and whose signature is given below, ECDSA with SHA-256 over its own Sig_structure, under the test leaf key except for X6, which the other P-256 test key signs. X2: X1 with 1 (alg) -9 in place of -7. Signature (hex): X3: X1 without parameter 33 (x5chain). Signature (hex): X4: X1 with iss in the form of , whose F is SHA-256 over the test leaf certificate. Signature (hex): X5: X1 with one more parameter, 16 (typ), the text string "application/cose". Signature (hex): X6: X1's protected header unchanged. Signature (hex): Certificate-profile vectors

Vector	Bytes	Candidate	Status	First failing step
X1	2313	P1	accepted	(none)
X2	2313	P1	outside_profile	2
X3	365	P1	outside_profile	2
X4	2313	P1	untrusted_key	3
X5	2331	P1	outside_profile	2
X6	2313	P1	signature_invalid	4

What each vector shows:

• X1: the certificate profile: alg -7, x5chain of the test leaf and the test root, iss a did:x509 identifier that names the test root.
• X2: X1 with alg -9 (ESP256) in place of -7, signed again under the test leaf; the Transparency Service of refuses it at registration.
• X3: X1 without x5chain, signed again under the test leaf: its labels are those of the key profile, and -7 is not an alg value of that profile.
• X4: X1 with an iss whose fingerprint names the test leaf certificate and not the test root, signed again under the test leaf.
• X5: X1 with one more protected parameter, 16 (typ), signed again under the test leaf.
• X6: X1 signed by another P-256 test key; kid and x5chain still name the test leaf.

Vector and SHA-256 over its bytes:

Transparent Statements T2 is the Transparent Statement that a local instance of a Transparency Service returned on 2026-10-11 when X1 was registered (see ). It is X1 with one COSE Receipt R under unprotected label 394; nothing else differs from X1. R was made by the service with the key of that test instance and is given here as recorded. Each vector below is a COSE_Sign1 with tag 18 in the deterministic encoding, made of the parts named, and is presented with vector P1 of . The Receiver's configured pairs are the pair of and the certificate pair of . The steps of do not read R. R, 472 bytes (hex):

• T1: the protected header, payload and signature of M2; unprotected header {394: [ R ]}.
• T2: the protected header, payload and signature of X1; unprotected header {394: [ R ]}.
• T3: as T2; unprotected header {4: the kid of X1, 394: [ R ]}.
• T4: as T2; unprotected header {394: R}, the byte string not in an array.
• T5: as T2; unprotected header {394: []}.

Transparent Statements

Vector	Bytes	Candidate	Status	First failing step
T1	786	P1	accepted	(none)
T2	2792	P1	accepted	(none)
T3	2827	P1	outside_profile	2
T4	2791	P1	outside_profile	2
T5	2317	P1	outside_profile	2

What each vector shows:

• T1: M2 with the receipt of T2 under unprotected label 394; that receipt is one for X1, and the steps of the checking procedure do not read it.
• T2: the Transparent Statement that a local Transparency Service returned for X1: X1 with one receipt under unprotected label 394.
• T3: T2 with one more unprotected parameter, 4 (kid), the kid of X1.
• T4: T2 with the receipt under label 394 as a byte string and not in an array.
• T5: T2 with an empty array under label 394.

Vector and SHA-256 over its bytes:

Changes (to be removed before publication)

Since draft-gruszka-evaluation-receipt-mappings-02

• The certificate profile does not admit alg -9 (ESP256). gives the measured reason, the measurement, and vector X2 () is the statement that was refused.
• The Open Items section is removed. The in-toto references stay pinned to release v1.2.0, the draft names of and stay as cited, already says that no profile names its declaration, and now states the measured reason for retaining the certificate profile's existing limits.
• makes explicit that a byte order mark is not ignored in this JSON representation, and vector R14 illustrates the resulting Malformed state and INDETERMINATE matching result.
• This appendix is added.

Since draft-gruszka-evaluation-receipt-mappings-01

• defines the JSON representation of a typed digest reference. Input outside it is Malformed before the other states, member names are compared after unescaping, and repeated names are found before any conversion. The matching rule takes exactly one digest_alg and one digest, both strings, whatever the state.
• Vectors R7 to R13 () give Malformed inputs and an escaped member name.
• Step 1 of names the form of the value in each carrier.
• and say that a MATCH is not a Verified reference, and is a normative reference.

Since draft-gruszka-evaluation-receipt-mappings-00

• adds a certificate profile next to the key profile. Its statement carries an X.509 chain in x5chain and a did:x509 issuer and is signed with alg -7, and step 3 of checks it against a did:x509 identifier and trust anchor that the Receiver configured. Vectors X1 to X6 () cover it.
• checks a Transparent Statement after removing its receipts under label 394 unread, and step 1 fixes the encoding choices that Section 4.2.2 leaves to a protocol. Vectors T1 to T5 () are Transparent Statements, and gives a statement for each status other than accepted.
• assigns the states Unresolved and Failed of Section 8.1 to typed digest references, with vectors R1 to R6 ().
• adds that a receipt does not show where B came from, and adds that an accepted status says nothing about registration and that registration alone does not establish that the payload is the receipt digest.
• records the registration of a statement in the certificate profile with a local Transparency Service and the offline verification of the Transparent Statement it returned.