]> Fraunhofer SIT

Rheinstrasse 75 Darmstadt 64295 Germany henk.birkholz@ietf.contact

Bowball Technologies Ltd

United Kingdom jonathan@bowball-tech.com

Microsoft Research

21 Station Road Cambridge CB1 2FB UK antdl@microsoft.com

Security SCITT Internet-Draft This document specifies a REST API with the HTTP resources, request and response messages, and error handling needed for an interoperable implementation of a SCITT Transparency Service, as defined by the Supply Chain Integrity, Transparency, and Trust (SCITT) Architecture. About This Document Status information for this document may be found at . Discussion of this document takes place on the SCITT Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Supply Chain Integrity, Transparency, and Trust (SCITT) Architecture defines the core objects, identifiers and workflows necessary to interact with a SCITT Transparency Service:

• Signed Statements
• Receipts
• Transparent Statements
• Registration Policies

SCITT Reference APIs (SCRAPI) defines HTTP resources for a Transparency Service using COSE ().

Scope and Relation to the SCITT Architecture The SCITT Architecture specifies the conceptual roles, message structures, and workflows of a Transparency Service, but does not define a concrete protocol by which clients interact with that service. This document specifies one such concrete protocol: an HTTP-based REST API that realizes those interactions in an interoperable way. References in this specification to "normative requirements of the SCITT Architecture" are to the requirements expressed using BCP 14 keywords in that pertain to the externally observable behavior of a Transparency Service, such as the registration of Signed Statements, the issuance and validation of Receipts, and the publication of the keys used to verify Receipts. In particular, this document defines HTTP resources that satisfy the requirements in the following sections of :

• Registration of Signed Statements (Section 6.3 of ), realized by the Signed Statement registration resources defined in and .
• Issuance of Receipts and construction of Transparent Statements (Section 7 of ), realized by the Receipt resolution resource defined in .
• Discovery of the Transparency Service verification keys used by Verifiers to validate Receipts (Section 5.1.2 and Section 9.4 of ), realized by the resource defined in .

The mandatory-to-implement resources listed above are sufficient for an interoperable Transparency Service. The following aspects of are intentionally out of scope for this document and are not covered by this API:

• The internal structure and operation of the Transparency Service's Verifiable Data Structure (Section 5.1.3 of ).
• The contents and evaluation of Registration Policies (Section 5.1.1 of ); this document only defines how the outcome of a policy decision is communicated to clients.
• The format and semantics of Signed Statements, Receipts, and Transparent Statements themselves, which are defined in and the COSE specifications referenced therein.
• Transports other than HTTP, and bindings of these resources to other application protocols.

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. This specification uses the terms "Signed Statement", "Receipt", "Transparent Statement", "Artifact Repositories", "Transparency Service" and "Registration Policy" as defined in . This specification uses "payload" as defined in .

Resources All messages are sent as HTTP GET or POST requests. If the Transparency Service cannot process a client's request, it MUST return an HTTP 4xx or 5xx status code, and the body MUST be a Concise Problem Details object (application/concise-problem-details+cbor) . The Concise Problem Details object MUST contain the following fields:

• title: A human-readable string identifying the error that prevented the Transparency Service from processing the request, ideally short and suitable for inclusion in log messages.
• detail: A human-readable string describing the error in more depth, ideally with sufficient detail enabling the error to be rectified.

As specified by , the title and detail values use oltext, which is either an unadorned CBOR text string (text) or a language-tagged text string (tag38). When a language needs to be identified explicitly, tag38 carries a BCP 47 language tag as described in . If no explicit or implicit language context is available, unadorned text is interpreted with the language tag en. SCRAPI is not a CoAP API, but Constrained Problem Details objects provide a useful encoding for problem details and avoid the need to mix CBOR and JSON in resource or client implementations. Examples of errors may include: Most error types are specific to the type of request and are defined in the respective subsections below. The one exception is the "malformed" error type, which indicates that the Transparency Service could not parse the client's request because it did not comply with this document: Per the guidance in , the specific HTTP status codes shown in the examples throughout this document are illustrative. Status codes can be generated by generic HTTP components (caches, intermediaries, captive portals, gateways, etc.) that are not part of the Transparency Service, and the set of registered HTTP status codes can be extended over time. Clients MUST therefore be prepared to handle any HTTP status code by falling back to the generic class semantics (1xx, 2xx, 3xx, 4xx, or 5xx) of the response when a more specific code is not recognized, and MUST rely on the Concise Problem Details object (when present) rather than the status code alone to determine the application-level cause of an error. Clients handle 5xx responses as defined in and . Note that in the case of any error response, the Transparency Service MAY include a Retry-After header field per in order to request a minimum time for the client to wait before retrying the request. In the absence of this header field, this document does not specify a minimum. The following subsections specify the HTTP resources required for conformance, as listed in .

Transparency Service Keys This resource, located at /.well-known/scitt-keys (registered in accordance with ; see ), is used to discover the public keys that can be used by relying parties to verify Receipts issued by the Transparency Service. Clients interact with this resource by issuing an HTTP GET request, and MUST include Accept: application/cbor in the request. The Transparency Service MUST respond with a COSE Key Set, as defined in , serialized as application/cbor. Request: Response: The Transparency Service MAY stop returning keys it no longer uses to issue Receipts from that resource, following a reasonable delay. A delay is considered reasonable if it is sufficient for relying parties to have obtained the key needed to verify any previously issued Receipt. Consistent with key management best practices described in (Section 5.3.4, which distinguishes the originator-usage period during which a private key is used to apply cryptographic protection from the recipient-usage period during which the corresponding public key is used to verify that protection), retired public keys used for signing SHOULD remain available for verification for as long as any Receipts signed with them may still need to be verified, unless an alternative key archival or distribution mechanism preserves verifiability for relying parties. Retaining retired keys has operational implications: the Transparency Service is responsible for storing those keys (and their associated metadata, such as kid values and validity periods) securely and continuously, and for serving them via the Individual Transparency Service Key resource (see ) for the entire retention period. If retired public keys are not retained, Receipts issued under those keys can no longer be verified by relying parties using only the Transparency Service's published key material, which may break the verifiability of previously issued Receipts and disrupt downstream consumers that depend on long-term verification. A Transparency Service MAY include the Expires header field, as defined in , in responses returned by this resource and by the Individual Transparency Service Key resource () to indicate how long clients may cache the returned keys. A Transparency Service MAY use the Cache-Control header field with the max-age directive, as defined in , for the same purpose; when both are present, Cache-Control: max-age takes precedence per . The cache lifetime indicated by these headers is a hint about server availability and does not constrain client retention. A relying party that holds a Receipt MUST retain the verification key for as long as it may need to verify that Receipt, independent of any cache lifetime indicated by the Transparency Service. The presence of these headers does not constitute a guarantee of key availability. A Transparency Service may still need to retire a key before any indicated cache lifetime has elapsed, for example in response to suspected compromise or cryptographic algorithm deprecation. In such cases, a relying party that holds a Receipt signed with a retired key can request a fresh Receipt for the same Signed Statement at the same position in the Verifiable Data Structure, signed with a current key.

Individual Transparency Service Key This sub-resource, located at /.well-known/scitt-keys/{kid_value}, is used to resolve a single public key, from a kid value contained in a Receipt previously issued by the Transparency Service. Clients interact with this sub-resource by issuing an HTTP GET request, and MUST include Accept: application/cbor in the request. The Transparency Service MUST respond with a single COSE Key, as defined in , serialized as application/cbor, or a 404 status if no matching key is found. Request: Response: The following expected error is defined for the condition described below. When this condition is encountered, an implementation MUST return an error response that is a valid object. Implementations SHOULD use the error defined below, unless another valid error better describes the condition: To avoid requiring clients to infer an encoding convention from any particular kid value, the base64url form is always valid. For every kid value used by the service, this resource MUST accept the base64url encoding of the kid value, without padding, as {kid_value}. If a kid value is safe for use as a URI path segment without percent-encoding, this resource MUST also accept the kid value itself as {kid_value}. Both forms, when present, identify the same key. A Transparency Service MUST NOT use kid values whose raw and base64url forms would make the same URL identify different keys. specifies Base64Url encoding as follows: "Base64 encoding using the URL- and filename-safe character set defined in Section 5 of RFC 4648 , with all trailing '=' characters omitted and without the inclusion of any line breaks, whitespace, or other additional characters. Note that the base64url encoding of the empty octet sequence is the empty string. (See Appendix C of for notes on implementing base64url encoding without padding.)" It is RECOMMENDED to use COSE Key Thumbprint, as defined in as the mechanism to assign a kid to Transparency Service keys. provides a well-specified, canonical method to deterministically derive a unique kid value directly from the COSE Key itself. Using this mechanism offers several benefits to implementers:

• it ensures that the kid is uniquely and reproducibly bound to the key material,
• it removes the need for an out-of-band identifier assignment process,
• it enables independent parties to compute and verify the same kid for a given key, which simplifies key discovery and reduces the risk of kid collisions across Transparency Services.

Register Signed Statement This resource instructs a Transparency Service to register a Signed Statement on its log. Since log implementations may take many seconds or longer to reach finality, this API provides an asynchronous mode that returns a locator for the eventual Receipt resource, which the client can poll to retrieve the Receipt once registration completes. The following is a non-normative example of an HTTP request to register a Signed Statement: Request: >, / Protected Header / {}, / Unprotected Header / / Payload, sha-256 digest of file stored at payload-location / h'935b5a91...e18a588a', h'269cd68f4211dffc...0dcb29c' / Signature / ]) ]]> A Transparency Service depends on the verification of the Signed Statement in the Registration Policy. The Registration Policy for the Transparency Service MUST be applied before any additional processing. The details of Registration Policies are out of scope for this document. Signed Statements MAY use detached payloads, as described in . When a Signed Statement is submitted with a detached payload, the Transparency Service still requires access to the payload content in order to verify the signature as part of applying the Registration Policy. The mechanism by which the payload is made available to the Transparency Service is implementation-specific. Response: One of the following:

Status 201 - Registration is successful If the Transparency Service is able to produce a Receipt within a reasonable time, it MAY return it directly. >, / unprotected / { / proofs / 396 : { / inclusion / -1 : [ <<[ / size / 9, / leaf / 8, / inclusion path / h'7558a95f...e02e35d6' ]>> ], }, }, / payload / null, / signature / h'02d227ed...ccd3774f' ]) ]]> The response contains the Receipt for the Signed Statement. The response MUST contain a Location header field whose value is the URL of the Receipt resource (see ). Fresh Receipts may be requested through the resource identified in the Location header. Transparency Services that support both synchronous and asynchronous registration MUST return the same Location URL for the same registered Signed Statement regardless of which registration mode was used.

Status 202 - Registration is running In cases where the registration request is accepted but the Transparency Service is not able to produce a Receipt in a reasonable time, it returns a 202 Accepted response, as in this non-normative example: ]]> The response MUST contain a Location header field whose value is the URL of the eventual Receipt resource (see ). The client polls this resource to retrieve the Receipt once registration completes. The Transparency Service MAY include a Retry-After header in the HTTP response to help with polling.

Status 400 - Invalid Client Request The following expected errors are defined for the conditions described below. When such a condition is encountered, an implementation MUST return an error response that is a valid object. Implementations SHOULD use the corresponding error defined below, unless another valid error better describes the condition.

Status 429 - Too Many Requests If a client is polling for an in-progress registration too frequently then the Transparency Service MAY, in addition to implementing rate limiting, return a 429 response: { / title / -1: \ "Too Many Requests", / detail / -2: \ "Only requests per are allowed." } ]]>

Resolve Receipt This resource resolves the Receipt for a given EntryID. It is the resource identified by the Location header returned in the 202 Accepted response to an asynchronous registration request (see ), and may also be used at any later time to obtain a fresh Receipt for a previously registered Signed Statement. A client polls this resource to obtain the Receipt. The response is one of:

• 200, once registration is complete and the Receipt is available;
• 204, while registration is still in progress; or
• 404, if no Receipt exists for the EntryID, including when registration has failed.

Request: Response: One of the following:

Status 200 - OK If the Receipt is found: >, / unprotected / { / proofs / 396 : { / inclusion / -1 : [ <<[ / size / 9, / leaf / 8, / inclusion path / h'7558a95f...e02e35d6' ]>> ], }, }, / payload / null, / signature / h'02d227ed...ccd3774f' ]) ]]>

Status 204 - Registration is running If the registration identified by the EntryID is still in progress, the Transparency Service returns a 204 No Content response, as in this non-normative example: Cache-Control: no-store ]]> The Transparency Service SHOULD include a Retry-After header in the HTTP response to help with polling. Because a 204 response is transient and the resource is expected to return a Receipt once registration completes, the Transparency Service SHOULD set Cache-Control: no-store to prevent caching of the in-progress response.

Status 404 - Not Found If there is no Receipt found for the specified EntryID the Transparency Service MUST respond with a 4xx-class status code (typically 404 Not Found) and a Concise Problem Details object as in the following example: not known \ to this Transparency Service" } ]]> A 404 response is also returned when an asynchronous registration has failed and no Receipt will be produced. In that case, the Transparency Service MAY enrich the Concise Problem Details object with application-specific detail explaining why registration did not complete, as in this non-normative example: could not \ be persisted to the log" } ]]> As an example, a successful asynchronous registration followed by Receipt resolution follows this sequence: TS Client <-- 202 Location: .../entries/123 --- TS May happen zero or more times: Client --- GET .../entries/123 --> TS Client <-- 204 Retry-After: --- TS Finally: Client --- GET .../entries/123 --> TS Client <-- 200 (Receipt) --- TS ]]>

Privacy Considerations The privacy considerations section of applies to this document.

Security Considerations

General Scope This document describes the interoperable API for client calls to, and implementations of, a Transparency Service as specified in . As such the security considerations in this section are concerned only with security considerations that are relevant at that implementation layer. All questions of security of the related COSE formats, algorithm choices, cryptographic envelopes, verifiable data structures and the like are handled elsewhere and out of scope for this document.

Applicable Environment SCITT is concerned with issues of cross-boundary supply-chain-wide data integrity and as such must assume a very wide range of deployment environments. Thus, no assumptions can be made about the security of the computing environment in which any client implementation of this specification runs.

Authentication Authentication is out of scope for this document. Implementations MAY authenticate clients, for example for the purposes of authorization or preventing denial-of-service attacks. If Authentication is not implemented, rate limiting or other denial-of-service mitigations MUST be implemented.

Threat Model

In Scope The most serious threats to implementations on Transparency Services are ones that would cause the failure of their main promises, to wit:

• Threats to strong identification, for example representing the Statements from one issuer as those of another
• Threats to payload integrity, for example changing the contents of a Signed Statement before making it transparent
• Threats to non-equivocation, for example attacks that would enable the presentation or verification of divergent proofs for the same Statement payload

Denial-of-Service Attacks While denial-of-service attacks are very hard to defend against completely, and Transparency Services are unlikely to be in the critical path of any safety-liable operation, any attack which could cause the silent failure of Signed Statement registration, for example, should be considered in scope. The impact of DoS attacks can be detected by a client checking that the Transparency Service has registered any submitted Signed Statement and returned a Receipt. Since verification of Receipts does not require the involvement of the Transparency Service, a DoS attack cannot cause the silent loss of a registration. However, this relies on clients actively checking for Receipts and does not prevent the disruption itself. Clients to Transparency Services that need to detect delayed or lost registrations MUST ensure that Receipts are available for their registered Statements, either on a periodic or needs-must basis, depending on the use case. Beyond this, implementers of Transparency Services MUST follow general good practice around defending against network attacks such as flooding, including defenses such as rate limiting.

Eavesdropping Since the purpose of this API is to ultimately put the message payloads on a Transparency Log there is limited risk to eavesdropping. Nonetheless, transparency may mean 'within a limited community' rather than 'in full public', so implementers MUST add protections against man-in-the-middle and network eavesdropping, such as TLS.

Message Modification Attacks Modification attacks are mitigated by the use of the Issuer signature on the Signed Statement.

Message Insertion Attacks Insertion attacks are mitigated by the use of the Issuer signature on the Signed Statement, therefore care must be taken in the protection of Issuer keys and credentials to avoid theft and impersonation.

Out of Scope

Replay Attacks Replay attacks are not particularly concerning for SCITT or SCRAPI: Once a statement is made, it is intended to be immutable and non-repudiable, so making it twice should not lead to any particular issues. There could be issues at the payload level (for instance, the statement "it is raining" may be true when first submitted but not when replayed), but being payload-agnostic implementations of SCITT services cannot be required to worry about that. If the semantic content of the payload are time-dependent and susceptible to replay attacks in this way then timestamps MUST be added to the protected header signed by the Issuer. The iat claim in a CWT_Claims header parameter () MUST be used when the Issuer provides the timestamp themselves. The COSE header parameters defined in for including timestamp tokens or a similar mechanic, for example an Epoch Marker Claim in the 'CWT_Claims' header parameter, SHOULD be used, where a timestamp from a third party is required, unless another protected-header mechanism is specified by the applicable profile. Other mechanisms for including timestamps in the protected header MAY also be used.

Message Deletion Attacks Once registered with a Transparency Service, Registered Signed Statements cannot be deleted. Thus, any message deletion attack must occur prior to registration else it is indistinguishable from a man-in-the-middle or denial-of-service attack on this interface.

Use of Unauthenticated HTTP Metadata Implementations that serve multiple application profiles MAY use unauthenticated HTTP-layer signals, such as request headers or distinct registration endpoints, to route incoming Signed Statements to profile-specific processing. However, these signals are not signed, are not committed to the Verifiable Data Structure, and cannot be replayed by Auditors. Implementations MUST NOT use unauthenticated signals as authoritative inputs to the registration decision. Implementations that use such signals for early dispatch MUST ensure that any processing decisions that affect the outcome of registration are fully determined by authenticated inputs, or are otherwise captured in the Verifiable Data Structure, such that the registration process remains deterministic and replayable by Auditors. The authoritative identification of the application profile is carried within the protected header or payload of the Signed Statement, and MUST be verified after signature authentication.

Operational Considerations

Client Retry Behavior Aggressive client retry or polling behavior can significantly impact a Transparency Service, increasing load and, in extreme cases, amplifying transient failures into sustained outages. Clients that retry a request MUST honor any Retry-After header field (defined in ) returned by the Transparency Service, treating it as a minimum interval before retrying. In its absence, clients that retry a request MUST apply exponential backoff with jitter, cap the total number of retries, and avoid synchronizing retries across clients.

Server-Side Retry Configuration Operators SHOULD configure a minimum retry interval appropriate for the expected registration latency and service capacity, and SHOULD communicate it to clients via the Retry-After header on relevant responses (e.g., 202, 204, 429, 503), unless the service does not support client polling or retries for those responses. The interval should account for worst-case registration time, sustainable request volume, and intermediary behavior.

Rate Limiting As noted in and , rate limiting or other denial-of-service mitigations are required. The specific per-client policy is implementation dependent and typically varies with whether and how clients are authenticated (e.g., per-identity for authenticated clients versus per source IP for unauthenticated clients), the cost of the operation, and the deployment environment. When a client exceeds the configured rate limit, the Transparency Service MUST return a 429 response (see ) including a Retry-After header field.

IANA Considerations

Well-Known URI for Key Discovery IANA is requested to register the /.well-known/scitt-keys URI in the "Well-Known URIs" registry defined in . The normative behavior of this resource and its /{kid_value} sub-resource is specified in and .

Registration Template The following value is requested to be registered in the "Well-Known URIs" registry (using the template from ):

• URI suffix: scitt-keys
• Change controller: IETF
• Specification document(s): RFCthis
• Status: Permanent
• Related information:

References Normative References 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. 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. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. 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. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations. This document obsoletes RFC 3205. This document defines a concise "problem detail" as a way to carry machine-readable details of errors in a Representational State Transfer (REST) response to avoid the need to define new error response formats for REST APIs for constrained environments. The format is inspired by, but intended to be more concise than, the problem details for HTTP APIs defined in RFC 7807. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. 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] This specification defines a method for computing a hash value over a CBOR Object Signing and Encryption (COSE) Key. It specifies which fields within the COSE Key structure are included in the cryptographic hash computation, the process for creating a canonical representation of these fields, and how to hash the resulting byte sequence. The resulting hash value, referred to as a "thumbprint", can be used to identify or select the corresponding key. 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. This document defines two CBOR Object Signing and Encryption (COSE) header parameters for incorporating timestamping based on RFC 3161 into COSE message structures (COSE_Sign and COSE_Sign1). This enables the use of established timestamping infrastructure per RFC 3161 in COSE-based protocols. This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. 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] Informative References Fraunhofer SIT Linaro Huawei Technologies Arm Universität Bremen TZI This document defines Epoch Markers as a means to establish a notion of freshness among actors in a distributed system. Epoch Markers are similar to "time ticks" and are produced and distributed by a dedicated system known as the Epoch Bell. Systems receiving Epoch Markers do not need to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a specific Epoch Marker establishes a new epoch that is shared among all recipients. This document defines Epoch Marker types, including CBOR time tags, RFC 3161 TimeStampToken, and nonce-like structures. It also defines a CWT Claim to embed Epoch Markers in RFC 8392 CBOR Web Tokens, which serve as vehicles for signed protocol messages. 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.

Contributors Transmute

United States orie@transmute.industries

Orie contributed examples, text, and URN structure to early version of this draft. Microsoft

United Kingdom amaury.chamayou@microsoft.com

Amaury contributed crucial content to ensure interoperability between implementations, improve example expressiveness and consistency, as well as overall document quality. Business Cyber Guardian

United States dick@businesscyberguardian.com

Dick contributed use cases and helped improve example expressiveness and consistency. MITRE Corporation

United States ramartin@mitre.org

Bob contributed use cases and helped with authoring and improving the document.

stevenlasker@hotmail.com

Steve contributed architectural insights, particularly around asynchronous operations and participated in the initial writing of the document. Microsoft

United States nicolebates@microsoft.com

Nicole contributed reviews and edits that improved the quality of the text.

USA roywill@msn.com

Roy contributed the receipt refresh use case and associated resource definition.