From 52fd5b59caa2d17f471db3f4eb2c9479aa394070 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Tue, 1 Oct 2024 15:16:53 +0000 Subject: [PATCH] Script updating gh-pages from bbd7102. [ci skip] --- steve/268/draft-ietf-scitt-architecture.html | 53 ++++++++++++-------- steve/268/draft-ietf-scitt-architecture.txt | 46 +++++++++++------ 2 files changed, 64 insertions(+), 35 deletions(-) diff --git a/steve/268/draft-ietf-scitt-architecture.html b/steve/268/draft-ietf-scitt-architecture.html index 2ebc1f3..f25c48f 100644 --- a/steve/268/draft-ietf-scitt-architecture.html +++ b/steve/268/draft-ietf-scitt-architecture.html @@ -1557,18 +1557,43 @@

The SCITT architecture consists of a very loose federation of Transparency Services, and a set of common formats and protocols for issuing and registering Signed Statements, and auditing Transparent Statements.

In order to accommodate as many Transparency Service implementations as possible, this document only specifies the format of Signed Statements (which must be used by all Issuers) and a very thin wrapper format for Receipts, which specifies the Transparency Service identity and the agility parameters for the Signed Inclusion Proofs. Most of the details of the Receipt's contents are specified in the COSE Signed Merkle Tree Proof document [I-D.draft-ietf-cose-merkle-tree-proofs].

-

Figure 1 illustrates two Transparency Services and two Receipts as a single Signed Statement MAY be registered on more than one Transparency Service. +

Figure 1 illustrates entities and processes that comprise a Transparency Service independent of any one use case.

+

This section describes the three main roles and associated processes in SCITT:

+ +

In addition, Figure 1 illustrates two Transparency Services and two Receipts as a single Signed Statement MAY be registered on more than one Transparency Service. Each Transparency Service produces a Receipt. -A Transparent Statement MAY contain multiple Receipts, for each Transparency Service it was successfully Registered.

-

The arrows indicate the flow of information. +A Transparent Statement MAY contain multiple Receipts, for each Transparency Service it was successfully Registered.

+

The arrows indicate the flow of information. For example, Credentials are used to produce Signed Statements and the Transparency Service verifies the Signed Statements. The Transparency Service produces a Receipt. A Receipt combined with a Signed Statement creates a Transparent Statement. -To verify a Transparent Statement, credentials are required to authenticate the Signed Statement and the Receipts of the Transparent Statement.

+To verify a Transparent Statement, credentials are required to authenticate the Signed Statement and the Receipts of the Transparent Statement.

-
-
+
+
@@ -1717,26 +1742,14 @@

Replay Log - +

Figure 1: Relationship of Concepts in SCITT
-

This section describes at a high level, the three main roles and associated processes in SCITT:

- -

The subsequent sections describe the main concepts, namely Transparency Service, Signed Statements, Registration, and Transparent Statements in more detail.

+

The subsequent sections describe the main concepts, namely Transparency Service, Signed Statements, Registration, and Transparent Statements in more detail.

diff --git a/steve/268/draft-ietf-scitt-architecture.txt b/steve/268/draft-ietf-scitt-architecture.txt index 52ed1c9..6fe77c0 100644 --- a/steve/268/draft-ietf-scitt-architecture.txt +++ b/steve/268/draft-ietf-scitt-architecture.txt @@ -402,11 +402,37 @@ Table of Contents COSE Signed Merkle Tree Proof document [I-D.draft-ietf-cose-merkle-tree-proofs]. - Figure 1 illustrates two Transparency Services and two Receipts as a - single Signed Statement MAY be registered on more than one - Transparency Service. Each Transparency Service produces a Receipt. - A Transparent Statement MAY contain multiple Receipts, for each - Transparency Service it was successfully Registered. + Figure 1 illustrates entities and processes that comprise a + Transparency Service independent of any one use case. + + This section describes the three main roles and associated processes + in SCITT: + + * Issuers that use their credentials to create Signed Statements + about Artifacts + + * Transparency Services that evaluate Signed Statements against + Registration Policies, producing Receipts upon successful + Registration. The returned Receipt may be combined with the + Signed Statement to create a Transparent Statement. + + * Relying Parties that: + + - collect Receipts of Signed Statements for subsequent + registration of Transparent Statements; + + - retrieve Transparent Statements for analysis of Statements + about Artifacts themselves (e.g. verification); + + - or replay all the Transparent Statements to check for the + consistency of the Transparency Service's Append-only Log (e.g. + auditing) + + In addition, Figure 1 illustrates two Transparency Services and two + Receipts as a single Signed Statement MAY be registered on more than + one Transparency Service. Each Transparency Service produces a + Receipt. A Transparent Statement MAY contain multiple Receipts, for + each Transparency Service it was successfully Registered. The arrows indicate the flow of information. For example, Credentials are used to produce Signed Statements and the @@ -461,16 +487,6 @@ Table of Contents Figure 1: Relationship of Concepts in SCITT - This section describes at a high level, the three main roles and - associated processes in SCITT: - - * Issuers and Signed Statements - - * Transparency Service and the registration process - - * Relying Parties of the Transparent Statements and the Receipt - validation process - The subsequent sections describe the main concepts, namely Transparency Service, Signed Statements, Registration, and Transparent Statements in more detail.