]> RiskRouter

anil@riskrouter.eu

Security SCITT transparency evidence SCITT Merkle tree completeness selective disclosure This document describes an evidence log that records only salted digests of records held by their makers, as leaves of an RFC 9162 Merkle tree, and three constructions over it that answer questions a single inclusion proof cannot: whether a set of records shown is complete (completeness chains), what one field of a sealed record said without revealing the others (selective disclosure), and whether records were kept, checked on a sample nobody could choose (spot checks). It profiles SCITT registration so that the log keeps a digest of each Signed Statement and never the statement. It is published as running code with test vectors.

Introduction Regulated firms must keep records (advice given, credit decisions, AI system logs, security logs) and, years later, show that a record is the one that existed at the time. A transparency log can make that showable without anyone trusting the firm or the log operator. Where records hold personal data, the log should never receive them: only a digest of a salted record leaves its maker, so the log holds nothing that must later be erased. An inclusion proof answers "was this record sealed unchanged?". It does not answer "is this all of it?", "what did this one field say?", or "were the records kept?". , and answer those, over an unchanged RFC 9162 tree. profiles SCITT registration for digest-only logs. The key words "MUST", "MUST NOT", "SHOULD" and "MAY" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.

Conventions Hashes are SHA-256 . A digest is written as 64 lowercase hexadecimal characters. Strings are UTF-8. The fields of a string that is hashed or signed are joined with "|", with no spaces and no escaping; no field may contain "|". Integers are written in ASCII decimal without leading zeros. Times inside such strings are UTC, written YYYY-MM-DDTHH:MM:SS.ffffffZ with exactly six fraction digits; a reader that receives another representation of the same instant MUST normalise it to this form before hashing or verifying. An account identifier is a UUID in its lowercase canonical form. A kind matches ^[a-z0-9][a-z0-9.-]{0,39}$. Unless stated otherwise, signatures are ECDSA over P-256 with SHA-256 , encoded as the 64-byte concatenation r || s and then base64 .

Records and digests A record is a JSON object whose keys match ^[a-z][a-z0-9_]{0,63}$ at every level and whose values are strings, integers within plus or minus (2^53 - 1), true, false, null, arrays and objects, nested at most 32 deep. Its canonical form is the JSON Canonicalization Scheme of the record. Its digest is

where salt is 16 to 64 random bytes the maker keeps with the record. A record outside the profile MUST be refused, never coerced.

Leaves and heads A leaf records leaf_index (assigned by the log, from 0, without gaps), created_at (assigned by the log, never by the client), the recording account, a kind, and record_digest:

Leaves form the Merkle tree of , Section 2.1, whose hashing is unchanged from . A maker MAY sign its own claim, riskrouter-evidence-claim|v3|kind|record_digest|key_id|claimed_at, with a P-256 key it registered with the log; the signature is then part of a v3 leaf string, inside the tree, so it cannot be replaced afterwards. The log verifies the signature before recording and refuses, recording nothing, a claim that does not verify. Heads are signed by the log over riskrouter-evidence-head|v2|tree_size|root_hash|timestamp. The same tree is also published as C2SP checkpoints , signed with a separate Ed25519 key, with tiles , so independent witnesses can cosign them.

Completeness chains A maker MAY place records in numbered chains. The record carries, inside itself: chain_tag: 64 hex characters naming the chain, which SHOULD be HMAC-SHA256 of a secret the maker keeps and the chain's name; chain_seq: 1, 2, 3, ... without gaps; chain_prev: the record_digest of the record at chain_seq - 1, or 64 zeros at position 1; and the maker sends chain_tag and chain_seq beside the digest, outside the leaf. The log MUST refuse a chain_seq that is not exactly the last position plus one, and a chain_tag already used by another account, recording nothing. On request for a tag, the log reads its current signed head first and then the chain's entries below that head's size, and signs:

A verifier holding the statement and the records a maker shows checks, for every position from 1 to length, that a record was shown which produces the digest at that position, names that tag and position, and names the digest of the position before. A position the statement lists and nobody showed is a record left out. The maker alone cannot hide a chained record; hiding one requires the log to sign a statement its own tree contradicts.

Selective disclosure To seal a record from which single fields can later be disclosed, the maker seals a commitment record:

and records the digest of the sealed record as any record. A disclosure carries the sealed record, its salt, the proof, and, for each disclosed field, its value and field salt. The secret MUST NOT be disclosed: with it, a hidden field of low entropy could be found by trial. Field names are visible; values are not.

Spot checks To check that records were kept without receiving them all, an auditor seals a plan naming a chain, a sample size and a future Bitcoin block height. When the block is mined, its hash is the seed, and the positions drawn are:

= 2^64 - (2^64 mod population) position = 1 + (x mod population), kept unless already drawn until min(sample, population) positions are drawn ]]>

where population is the chain's signed length. The maker shows the records at those positions, which are checked as in .

SCITT profile Registration under policy riskrouter-scitt-profile|1 accepts a COSE_Sign1 signed ES256 with a key the caller registered, with CWT claims iss and sub in the protected header , and a hash envelope whose payload is 32 bytes, so the artifact never reaches the log. The log keeps one leaf of kind scitt.statement whose digest is SHA-256 of the statement re-encoded with an empty unprotected header, and returns an RFC 9942 receipt over the tree root. This departs from the architecture's expectation that a Transparency Service stores statements, deliberately: the log holds no content.

Time Each new signed head is sent to RFC 3161 time-stamping authorities and anchored in Bitcoin through OpenTimestamps . Neither is a qualified time stamp in the sense of EU law unless its authority is.

Security Considerations A digest of a guessable record can be confirmed by anyone who guesses it; makers MUST salt records. A seal shows a record existed unchanged no later than its leaf's time; it does not show the record is true. A chain shows nothing about records that were never chained; whether every record of a kind must be chained is a policy question for the maker's supervisor. A log operator that colludes with a maker could accept a second chain position out of turn; its signed chain statements and heads, saved by holders and cosigned by witnesses, are what make such a fork evidence against the operator. On a log the maker runs itself, a chain is the maker's own word. Spot-check seeds rely on the auditor announcing a block height before it is mined, provable by the plan's leaf time.

Privacy Considerations The log holds digests, short kinds, account identifiers, chain tags and times. Records, salts, chain secrets and disclosure secrets stay with makers. A chain statement reveals how many records a chain holds and when they were sealed, to anyone holding its tag.

IANA Considerations This document has no IANA actions.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Federal Information Processing Standard, FIPS Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust over time and has been applied to certificates, end-to-end encrypted messaging systems, and supply chain security. This specification enables concise transparency-oriented systems by building on Concise Binary Object Representation (CBOR) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs. This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK] National Institute of Standards and Technology This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any CBOR Object Signing and Encryption (COSE) structure. This functionality helps to facilitate applications that wish to make use of CWT claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. Fraunhofer SIT Microsoft Research Microsoft Research ARM Traceability in supply chains is a growing security concern. While verifiable data structures have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility, interoperability between different transparency services, and compliance with various auditing procedures and regulatory requirements. Fraunhofer SIT This document defines new COSE header parameters for signaling a payload as an output of a hash function. This mechanism enables faster validation, as access to the original payload is not required for signature validation. Additionally, hints of the hashed payload's content format and availability are defined, providing references to optional discovery mechanisms that can help to find original payload content.

Implementation Status (RFC Editor: please remove this section before publication.) This section follows . An implementation is published at https://riskrouter.eu/spec with test vectors (spec-vectors.json), two independent verifiers (JavaScript and Python, standard libraries only) and a conformance suite. Its result files are the implementer's own statements; nobody certifies an implementation.