Merge pull request #210 from SteveLasker/steve/120

Replace Verifier with Relying Party, keeping Client

draft-ietf-scitt-architecture.md

@@ -191,7 +191,6 @@ Auditor:
 Client:
 
 : an application making protected Transparency Service resource requests on behalf of the resource owner and with its authorization.
-The term "Client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).
 
 Envelope:
 
@@ -202,12 +201,12 @@ In COSE, an Envelope consists of a protected header (included in the Issuer's si
 
 Equivocation:
 
-: a state where it is possible for a Transparency Service to provide different views of its Append-only log to Verifiers about the same Artifact {{EQUIVOCATION}}.
+: a state where it is possible for a Transparency Service to provide different views of its Append-only log to Relying Parties about the same Artifact {{EQUIVOCATION}}.
 
 Feed:
 
 : A collection of Receipts, as recorded by the Transparency Service, based on filtering of properties from the envelope including, but not limited to the `sub` field of the `CWT_Claims`.
-Verifiers may use the Feed to ensure completeness and Non-equivocation in supply chain evidence by identifying all Transparent Statements linked to the Artifact they are evaluating.
+Relying Parties may use the Feed to ensure completeness and Non-equivocation in supply chain evidence by identifying all Transparent Statements linked to the Artifact they are evaluating.
 
 Issuer:
 
@@ -216,8 +215,8 @@ An Issuer may be the owner or author of Artifacts, or an independent third party
 
 Non-equivocation:
 
-: a state where it is impossible for a Transparency Service to provide different views of its append-only log to Verifiers about the same Artifact.
-Over time, an Issuer may register new Signed Statements about an Artifact in a Transparency Service with new information. However, the consistency of a collection of Signed Statements about the Artifact can be checked by all Verifiers.
+: a state where it is impossible for a Transparency Service to provide different views of its append-only log to Relying Parties about the same Artifact.
+Over time, an Issuer may register new Signed Statements about an Artifact in a Transparency Service with new information. However, the consistency of a collection of Signed Statements about the Artifact can be checked by all Relying Parties.
 
 Receipt:
 
@@ -234,6 +233,10 @@ Registration Policy:
 
 : the pre-condition enforced by the Transparency Service before registering a Signed Statement, based on information in the non-opaque header and metadata contained in its COSE Envelope.
 
+Relying Party:
+
+: a relying party depends on Signed or Transparent Statements to verify an Artifact.
+
 Signed Statement:
 
 : an identifiable and non-repudiable Statement about an Artifact signed by an Issuer.
@@ -263,18 +266,18 @@ Transparency Service:
 
 : an entity that maintains and extends the Append-only Log, and endorses its state.
 A Transparency Service can be a complex distributed system, and SCITT requires the Transparency Service to provide many security guarantees about its Append-only Log.
-The identity of a Transparency Service is captured by a public key that must be known by Verifiers in order to validate Receipts.
+The identity of a Transparency Service is captured by a public key that must be known by Relying Parties in order to validate Receipts.
 
 Transparent Statement:
 
 : a Signed Statement that is augmented with a Receipt created via Registration in a Transparency Service.
 The receipt is stored in the unprotected header of COSE Envelope of the Signed Statement.
 A Transparent Statement remains a valid Signed Statement, and may be registered again in a different Transparency Service.
 
-Verifier:
+Relying Party:
 
 : organizations, stakeholders, and users involved in validating supply chain Artifacts.
-Verifiers analyze Transparent Statements, verifying their proofs and inspecting the Statement payload, either before using corresponding Artifacts, or later to audit an Artifact's provenance on the supply chain.
+Relying Parties consume Transparent Statements, verifying their proofs and inspecting the Statement payload, either before using corresponding Artifacts, or later to audit an Artifact's provenance on the supply chain.
 
 {: #mybody}
 
@@ -290,7 +293,7 @@ By extension, the document may say an Artifact (a firmware binary) is transparen
 
 Transparency does not prevent dishonest or compromised Issuers, but it holds them accountable.
 Any Artifact that may be verified, is subject to scrutiny and auditing by other parties.
-The Transparency Service provides a history of Statements, which may be made by multiple Issuers, enabling Verifiers to make informed decisions.
+The Transparency Service provides a history of Statements, which may be made by multiple Issuers, enabling Relying Parties to make informed decisions.
 
 Transparency is implemented by providing a consistent, append-only, cryptographically verifiable, publicly available record of entries.
 A SCITT instance is referred to as a Transparency Service.
@@ -312,7 +315,7 @@ Considering CT in terms of SCITT:
 - CAs (Issuers) sign X.509 TBSCertificates (Artifacts) to produce X.509 certificates (Signed Statements)
 - CAs submit the certificates to one or more CT logs (Transparency Services)
 - CT logs produce Signed Certificate Timestamps (Transparent Statements)
-- Signed Certificate Timestamps are checked by Verifiers
+- Signed Certificate Timestamps are checked by Relying Parties
 - The Append-only Log can be checked by Auditors
 
 # Architecture Overview
@@ -367,7 +370,7 @@ Most of the details of the Receipt's contents are specified in the COSE Signed M
          '------------------'      '----------------'
 ~~~
 
-This section describes at a high level, the three main roles and associated processes in SCITT: Issuers and Signed Statements, Transparency Service and the Signed Statement Registration process, as well as Verifiers of the Transparent Statements and the Receipt validation process.
+This section describes at a high level, the three main roles and associated processes in SCITT: Issuers and Signed Statements, Transparency Service and the Signed Statement Registration process, as well as Relying Parties of the Transparent Statements and the Receipt validation process.
 
 ## Transparency Service
 
@@ -387,10 +390,8 @@ Multi-tenant support can be enabled through the use of identifiers in the `iss`
 Registration Policies refer to additional checks over and above the Mandatory Registration Checks that are performed before a Signed Statement is accepted to be registered to the Append-only Log.
 
 Transparency Services MUST maintain Registration Policies which govern whether or not a given Signed Statement is eligible for registration.
-
-Registration Policies MUST be made transparent and available to all clients of the Transparency Service by registering them as Signed Statements on the Append-only Log.
-
-
+Registration Policies MUST be made transparent and available to all Relying Parties of the Transparency Service by registering them as Signed Statements on the Append-only Log, and distributing associated Receipts.
+Distribution of Receipts is out of scope for this document.```
 
 This specification leaves implementation, encoding and documentation of Registration Policies to the operator of the Transparency Service.
 
@@ -534,7 +535,7 @@ For a software supply chain, payloads describing the software artifacts may incl
 Once all the Envelope headers are set, an Issuer MUST use a standard COSE implementation to produce an appropriately serialized Signed Statement (the SCITT tag of `COSE_Sign1_Tagged` is outside the scope of COSE, and used to indicate that a signed object is a Signed Statement).
 
 Issuers may produce Signed Statements about different Artifacts under the same Identity.
-Issuers and Verifiers must be able to recognize the Artifact to which the statements pertain by looking at the Signed Statement.
+Issuers and Relying Parties must be able to recognize the Artifact to which the statements pertain by looking at the Signed Statement.
 The `iss` and `sub` claims, within the CWT_Claims protected header, are used to identify the Artifact the statement pertains to.
 
 See Subject under {{terminology}} Terminology.
@@ -545,15 +546,15 @@ An Issuer can make multiple Statements about the same Artifact.
 For example, an Issuer can make amended Statements about the same Artifact as their view changes over time.
 
 Multiple Issuers can make different, even conflicting Statements, about the same Artifact.
-Verifiers can choose which Issuers they trust.
+Relying Parties can choose which Issuers they trust.
 
 Multiple Issuers can make the same Statement about a single Artifact, affirming multiple Issuers agree.
 
 ### Registration
 
 To register a Signed Statement, the Transparency Service performs the following steps:
 
-1. **Client authentication:** A Client authenticates with the Transparency Service, to Register Signed Statements.
+1. **Client authentication:** A Client authenticates with the Transparency Service, to Register Signed Statements on behalf of one or more issuers.
 Authentication and authorization is implementation-specific, and out of scope of the SCITT Architecture.
 1. **Issuer Verification:** The Transparency Service MUST perform resolution of the Issuer's identity, which may be different than the Client identity.
   This step may require that the service retrieves the Issuer ID in real-time, or rely on a cache of recent resolutions.
@@ -578,7 +579,9 @@ The multiple receipts may be attached to the unprotected header of the Signed St
 
 ## Transparent Statements {#Receipt}
 
-The client (which is not necessarily the Issuer) that registers a Signed Statement and receives a Receipt can produce a Transparent Statement by adding the Receipt to the Unprotected Header of the Signed Statement.
+The Client (which is not necessarily the Issuer) that registers a Signed Statement and receives a Receipt can produce a Transparent Statement by adding the Receipt to the Unprotected Header of the Signed Statement.
+Client applications MAY register Signed Statements on behalf of one or more Issuers.
+Client applications MAY request Receipts regardless of the identity of the Issuer of the associated Signed Statement.
 
 When a Signed Statement is registered by a Transparency Service a Receipt becomes available.
 When a Receipt is included in a Signed Statement a Transparent Statement is produced.
@@ -673,7 +676,7 @@ This is a decoded inclusion proof for RFC9162_SHA256, other verifiable data stru
 
 ### Validation {#validation}
 
-Verifiers MUST apply the verification process as described in Section 4.4 of {{RFC9052}}.
+Relying Parties MUST apply the verification process as described in Section 4.4 of RFC9052.
 
 APIs exposing verification logic for Transparent Statements may provide more details than a single boolean result.
 For example, an API may indicate if the signature on the Receipt or Signed Statement is valid, if claims related to the validity period are valid, or if the inclusion proof in the Receipt is valid.
@@ -702,13 +705,13 @@ let verify_transparent_statement(t) =
 
 Before checking a Transparent Statement, the Verifier must be configured with one or more identities of trusted Transparency Services.
 
-Verifiers MAY be configured to re-verify the Issuer's Signed Statement locally, but this requires a fresh resolution of the Issuer's verification keys, which MAY fail if the key has been revoked.
+Relying Parties MAY be configured to re-verify the Issuer's Signed Statement locally, but this requires a fresh resolution of the Issuer's verification keys, which MAY fail if the key has been revoked.
 
-Some Verifiers MAY decide to locally re-apply some or all of the Registration Policies, if they have limited trust in the Transparency Services.
-In addition, Verifiers MAY apply arbitrary validation policies after the Transparent Statement has been verified and validated.
+Some Relying Parties MAY decide to locally re-apply some or all of the Registration Policies, if they have limited trust in the Transparency Services.
+In addition, Relying Parties MAY apply arbitrary validation policies after the Transparent Statement has been verified and validated.
 Such policies may use as input all information in the Envelope, the Receipt, and the Statement payload, as well as any local state.
 
-Verifiers MAY offer options to store or share the Receipt of the Transparent Statement for auditing the Transparency Services in case a dispute arises.
+Relying Parties MAY offer options to store or share the Receipt of the Transparent Statement for auditing the Transparency Services in case a dispute arises.
 
 # Privacy Considerations
 
@@ -735,7 +738,7 @@ Just that signed evidence will be available to support them.
 
 An Issuer that knows of a changed state of quality for an Artifact, SHOULD Register a new Signed Statement, using the same `15` CWT `iss` and `sub` claims.
 
-Issuers MUST ensure that the Statement payloads in their Signed Statements are correct and unambiguous, for example by avoiding ill-defined or ambiguous formats that may cause Verifiers to interpret the Signed Statement as valid for some other purpose.
+Issuers MUST ensure that the Statement payloads in their Signed Statements are correct and unambiguous, for example by avoiding ill-defined or ambiguous formats that may cause Relying Parties to interpret the Signed Statement as valid for some other purpose.
 
 Issuers and Transparency Services MUST carefully protect their private signing keys and avoid these keys being used for any purpose not described in this architecture document.
 In cases where key re-use is unavoidable, keys MUST NOT sign any other message that may be verified as an Envelope as part of a Signed Statement.
@@ -793,7 +796,7 @@ In both cases, the SCITT Architecture provides generic, universally-verifiable c
 On one hand, this enables valid actors to detect and disambiguate malicious actors who employ Equivocation with Signed Statements to different entities.
 On the other hand, their liability and the resulting damage to their reputation are application specific, and out of scope of the SCITT Architecture.
 
-Verifiers and Auditors need not be trusted by other actors.
+Relying Parties and Auditors need not be trusted by other actors.
 In particular, so long as actors maintain proper control of their signing keys and identity infrastructure they cannot "frame" an Issuer or a Transparency Service for Signed Statements they did not issue or register.
 
 ### Append-only Log
@@ -812,7 +815,7 @@ This ensures any Verifier that trusts at least one such Auditor that (2, 3) will
 
 Due to the operational challenge of maintaining a globally consistent Append-only Log, some Transparency Services may provide limited support for historical queries on the Signed Statements they have registered, and accept the risk of being blamed for inconsistent Registration or Issuer Equivocation.
 
-Verifiers and Auditors may also witness (1, 4) but may not be able to collect verifiable evidence for it.
+Relying Parties and Auditors may also witness (1, 4) but may not be able to collect verifiable evidence for it.
 
 ### Availability of Receipts
 
@@ -832,7 +835,7 @@ All contents exchanged between actors is protected using secure authenticated ch
 
 The Transparency Service is trusted with the confidentiality of the Signed Statements presented for Registration.
 Some Transparency Services may publish every Signed Statement in their logs, to facilitate their dissemination and auditing.
-Others may just return Receipts to clients that present Signed Statements for Registration, and disclose the Append-only Log only to Auditors trusted with the confidentiality of its contents.
+Transparency Services MAY return Receipts to client applications synchronously or asynchronously.
 
 A collection of Signed Statements must not leak information about the contents of other Signed Statements registered on the Transparency Service.
 
@@ -849,19 +852,19 @@ The SCITT Architecture supports cryptographic agility.
 The actors depend only on the subset of signing and Receipt schemes they trust.
 This enables the gradual transition to stronger algorithms, including e.g. post-quantum signature algorithms.
 
-### Transparency Service Clients
+### Transparency Service Client Applications
 
-Trust in clients that submit Signed Statements for Registration is implementation-specific.
-An attacker may attempt to register any Signed Statement it has obtained, at any Transparency Service that accepts them, possibly multiple times and out of order.
-This may be mitigated by a Transparency Service that enforces restrictive access control and Registration Policies.
+Authentication of Client applications is out of scope for this document.
+Transparency Services MUST authenticate both client applications and the Issuer of signed statements in order to ensure that implementation specific authentication and authorization policies are enforced.
+The specification of authentication and authorization policies is out of scope for this document.
 
 ### Impersonation
 
 The identity resolution mechanism is trusted to associate long-term identifiers with their public signature-verification keys.
 Transparency Services and other parties may record identity-resolution evidence to facilitate its auditing.
 
 If one of the credentials of an Issuer gets compromised, the SCITT Architecture still guarantees the authenticity of all Signed Statements signed with this credential that have been registered on a Transparency Service before the compromise.
-It is up to the Issuer to notify Transparency Services of credential revocation to stop Verifiers from accepting Signed Statements signed with compromised credentials.
+It is up to the Issuer to notify Transparency Services of credential revocation to stop Relying Parties from accepting Signed Statements signed with compromised credentials.
 
 # IANA Considerations