Merge branch 'scrapi-adoption-prep' into steve/scrapi-updates

draft-ietf-scitt-architecture.md

@@ -15,6 +15,11 @@ submissiontype: IETF
 kramdown_options:
   auto_id_prefix: sec-
 
+venue:
+  group: SCITT
+  mail: [email protected]
+  github: ietf-wg-scitt/draft-ietf-scitt-architecture
+
 author:
 - name: Henk Birkholz
   org: Fraunhofer SIT
@@ -70,13 +75,8 @@ normative:
   RFC6838:
   RFC9360:
   IANA.cose:
-  COSWID:
-    target: https://www.rfc-editor.org/rfc/rfc9393
-    title:  COSWID Specification
-  CWT_CLAIM_COSE:
-    target: https://datatracker.ietf.org/doc/draft-ietf-cose-cwt-claims-in-headers/
-    title: CBOR Web Token (CWT) Claims in COSE Headers
-  I-D.draft-birkholz-scitt-scrapi: scrapi
+  COSWID: RFC9393
+  CWT_CLAIMS_COSE: I-D.ietf-cose-cwt-claims-in-headers
 
 informative:
   I-D.draft-steele-cose-merkle-tree-proofs: COMETRE
@@ -91,28 +91,33 @@ informative:
     title: CBOR Web Token (CWT) Claims
   CycloneDX:
     target: https://cyclonedx.org/specification/overview/
-    title:  CycloneDX
+    title: CycloneDX
+  DID-CORE:
+    target: https://www.w3.org/TR/did-core/
+    title: Decentralized Identifiers (DIDs) v1.0
+    author:
+      org: W3C
+    date: 2022-07-22
+  DID-WEB:
+    target: https://w3c-ccg.github.io/did-method-web/
+    title: did:web Decentralized Identifiers Method Spec
   in-toto:
     target: https://in-toto.io/
-    title:  in-toto
+    title: in-toto
   SLSA:
     target: https://slsa.dev/
-    title:  SLSA
+    title: SLSA
   SPDX-JSON:
     target: https://spdx.dev/use/specifications/
-    title:  SPDX Specification
+    title: SPDX Specification
   SPDX-CBOR:
     target: https://spdx.dev/use/specifications/
-    title:  SPDX Specification
+    title: SPDX Specification
   SWID:
     target: https://csrc.nist.gov/Projects/Software-Identification-SWID/guidelines
-    title:  SWID Specification
+    title: SWID Specification
   EQUIVOCATION: DOI.10.1145/1323293.1294280
 
-venue:
-  mail: [email protected]
-  github: ietf-wg-scitt/draft-ietf-scitt-architecture
-
 --- abstract
 
 Traceability of physical and digital Artifacts in supply chains is a long-standing, but increasingly serious security concern.
@@ -409,7 +414,6 @@ Protected_Header = {
   1   => int             ; algorithm identifier,
   4   => bstr            ; Key ID (kid),
   15  => CWT_Claims      ; CBOR Web Token Claims,
-  393 => Reg_Info        ; Registration Policy info,
   3   => tstr            ; payload type
 }
 ~~~
@@ -427,15 +431,9 @@ Issuers MAY use different signing keys (identified by `kid` in the resolved key
 ### Registration Policy Metadata
 
 SCITT payloads are opaque to Transparency Services.
-For interoperability, Registration Policy decisions should be based on interpretation of information in the non-opaque Envelope.
-
-The small mandatory set of metadata in the envelope of a Signed Statement is neither intended nor sufficient to express the information required for the processing of Registration Policies in a Transparency Service.
+For interoperability, Registration Policy decisions should be based on interpretation of the mandatory metadata in the protected header of a Signed Statement.
 
-For example, a Transparency Service may only allow a Signed Statement to be registered if it was signed very recently, or may reject a Signed Statement if it arrives out of order in some sequenced protocol.
-
-Any metadata meant to be interpreted by the Transparency Service during Registration Policy evaluation, SHOULD be added to the `reg_info` header, unless the data is private, in which case it MAY be sent to the Transparency Service as an additional input during registration.
-
-While the `Reg_Info` header MUST be present in all Signed Statements, all attributes are optional, and the map MAY be empty.
+Each implementation of a Transparency Service MAY support additional metadata, specific to its implementation through additional ["Reserved for Private Use"](https://www.iana.org/assignments/cwt/cwt.xhtml#claims-registry) keys within the `CWT_Claims` header.
 
 ## Transparency Service
 
@@ -603,15 +601,12 @@ All Signed Statements MUST include the following protected headers:
 - **algorithm** (label: `1`): Asymmetric signature algorithm used by the Issuer of a Signed Statement, as an integer.<br>
   Example: `-35` is the registered algorithm identifier for ECDSA with SHA-384, see [COSE Algorithms Registry](#IANA.cose).
 - **Key ID** (label: `4`): Key ID, as a bytestring
-- **CWT_Claims** (label: `15` pending {{CWT_CLAIM_COSE}}): A CWT representing the Issuer (`iss`) making the statement, and the Subject (`sub`) to correlate a collection of statements about an Artifact.
+- **CWT_Claims** (label: `15` pending {{CWT_CLAIMS_COSE}}): A CWT representing the Issuer (`iss`) making the statement, and the Subject (`sub`) to correlate a collection of statements about an Artifact.
   Additional {{CWT_CLAIMS}} MAY be used, while `iss` and `sub` MUST be provided
   - **iss** (CWT_Claim Key `1`): The Identifier of the signer, as a string<br>
     Example: `https://software.vendor.example`
   - **sub** (CWT_Claim Key `2`): The Subject to which the Statement refers, chosen by the Issuer<br>
     Example: `github.com/opensbom-generator/spdx-sbom-generator/releases/tag/v0.0.13`
-- **Registration Policy** (label: `TBD`, temporary: `393`): A map containing key/value pairs set by the Issuer which are sealed on Registration and non-opaque to the Transparency Service.
-  The key/value pair semantics are specified by the Issuer or are specific to the `CWT_Claims iss` and `CWT_Claims sub` tuple.<br>
-  Examples: the sequence number of signed statements on a `CWT_Claims Subject`, Issuer metadata, or a reference to other Transparent Statements (e.g., augments, replaces, new-version, CPE-for)
 - **Content type** (label: `3`): The media type of the payload, as a string.<br>
   Example: `application/spdx+json` as the media type of SDPX in JSON encoding
 
@@ -635,19 +630,10 @@ CWT_Claims = {
   * tstr => any
 }
 
-Reg_Info = {
-  ? "register_by": uint .within (~time),
-  ? "sequence_no": uint,
-  ? "issuance_ts": uint .within (~time),
-  ? "no_replay": null,
-  * tstr => any
-}
-
 Protected_Header = {
   1   => int             ; algorithm identifier,
   4   => bstr            ; Key ID,
   15  => CWT_Claims      ; CBOR Web Token Claims,
-  393 => Reg_Info        ; Registration Policy info,
   3   => tstr            ; payload type
 }
 
@@ -671,11 +657,6 @@ For a software supply chain, payloads describing the software artifacts may incl
 - {{SLSA}}
 - {{SWID}}
 
-Once the Statement is serialized with the correct media-type/content-format, an Issuer should fill in the attributes for the Registration Policy information header.
-From the Issuer's perspective, using attributes from named policies ensures that the Signed Statement may only be registered on Transparency Services that implement the associated policy.
-
-For instance, if a Signed Statement is frequently updated, and it is important for Verifiers to always consider the latest version, Issuers may use the `sequence_no` or `issuer_ts` attributes.
-
 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).
 
 ## Registering Signed Statements
@@ -691,8 +672,7 @@ Signed Statements may be registered by a different party than their Issuer.
 1. **Signature verification:** The Transparency Service MUST verify the signature of the Signed Statement, as described in {{RFC9360}}, using the signature algorithm and verification key of the Issuer.
 1. **Signed Statement validation:** The Transparency Service MUST check that the Signed Statement includes the required protected headers listed above.
 The Transparency Service MAY verify the Statement payload format, content and other optional properties.
-1. **Apply Registration Policy:** For named policies, the Transparency Service MUST check that the required Registration Policy attributes are present in the protected headers and apply the check described in Table 1.
-  A Transparency Service MUST reject Signed Statements that contain an attribute used for a named policy that is not enforced by the service.
+1. **Apply Registration Policy:** The Transparency Service MUST check the attributes required by a policy are present in the protected headers.
   Custom Signed Statements are evaluated given the current Transparency Service state and the entire Envelope, and may use information contained in the attributes of named policies.
 1. **Register the Signed Statement** to the append-only log
 1. **Return the Transparent Statement**, which includes the Receipt
@@ -718,16 +698,16 @@ Receipts protected headers have additional mandatory fields:
 - **kccs**: A CWT Claim Set representing the issuance of the receipt. Only a subset of all CWT claims can be used in a SCITT receipt.
 - **crit**: The `crit` header (id: 2) MUST be included and the following headers MUST be marked critical: (`scitt-version`, `verifiable-data-structure`, `kccs`).
 
-Inside Reg_info, the Transparency Service may include the registration time to help Verifiers decide about the trustworthiness of the Transparent Statement.
+- The SCITT version header MUST be included and its value match the `version` field of the Receipt structure
+- The DID of Issuer header (in Signed Statements) MUST be included and its value match the `ts_identifier` field of the Receipt structure
+- Transparency Service MUST include additional claims in the protected header of Receipts to indicate the policies evaluated during the registration of a Statement
+- Since {{-COMETRE}} uses optional headers, the `crit` header (id: 2) MUST be included and all SCITT-specific headers (version, DID of Transparency Service and Registration Policy) MUST be marked critical
 
 The registration time is defined as the timestamp at which the Transparency Service has added this Signed Statement to its Append-only Log.
 
 Editor's Note: The WG is discussing if existing CWT claims might better support these design principles.
 
 ~~~ cddl
-label = int / tstr
-value = any
-
 Receipt_Unprotected_Header = {
   &(scitt-inclusion-proof: 396) => bstr .cbor inclusion-proof
 }
@@ -807,7 +787,6 @@ Transparent_Statement_as_COSE_Sign1 = [
     signature : bstr
 ]
 
-Transparent_Statement = #6.18(Transparent_Statement_as_COSE_Sign1)
 ~~~
 
 Example transparent statement: