From 8413f94d1675019fe40e3a1dcb1b9c7ac4bb3d07 Mon Sep 17 00:00:00 2001 From: steve lasker Date: Fri, 1 Dec 2023 13:30:58 -0800 Subject: [PATCH 01/12] Remove Reg_Info Signed-off-by: steve lasker --- draft-ietf-scitt-architecture.md | 40 ++++---------------------------- 1 file changed, 4 insertions(+), 36 deletions(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index 485e8a06..cfecd14e 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -411,7 +411,6 @@ Protected_Header = { 1 => int ; algorithm identifier, 4 => bstr ; Key ID (kid), 13 => CWT_Claims ; CBOR Web Token Claims, - 393 => Reg_Info ; Registration Policy info, 3 => tstr ; payload type } ~~~ @@ -574,15 +573,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. +For interoperability, Registration Policy decisions should be based on interpretation of the mandatory metadata in the non-opaque Envelope of a Signed Statement. -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 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 @@ -723,9 +716,6 @@ All Signed Statements MUST include the following protected headers: Example: `did:web:example.com` - **sub** (CWT_Claim Key `2`): The Subject to which the Statement refers, chosen by the Issuer
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.
- 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.
Example: `application/spdx+json` as the media type of SDPX in JSON encoding @@ -749,19 +739,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, 13 => CWT_Claims ; CBOR Web Token Claims, - 393 => Reg_Info ; Registration Policy info, 3 => tstr ; payload type } @@ -785,11 +766,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 @@ -805,8 +781,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:** For named policies, the Transparency Service MUST check the attributes required by the 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 @@ -833,7 +808,7 @@ The following requirements for the COSE signature of the Merkle Root are added: - 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 MAY include the Registration policy info header to indicate to Verifiers what policies have been applied at the registration of this Statement +- Transparency Service MUST include the Registration policy info header to indicate to Verifiers what policies have been applied at the registration of this 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 Transparency Service may include the registration time to help Verifiers decide about the trustworthiness of the Transparent Statement. @@ -851,7 +826,6 @@ Receipt = [ Protected_Header = { 390 => int ; SCITT Receipt Version 394 => tstr ; DID of Transparency Service (required) - ? 393 => Reg_info ; Registration policy information (optional) ; Other COSE Signed Merkle Tree headers ; (e.g. tree algorithm, tree size) @@ -861,12 +835,6 @@ Protected_Header = { ? 4 => bstr ; Key ID (optional) ? 33 => COSE_X509 ; X.509 chain (optional) } - -; Details of the registration info, as provided by the TS -RegistrationInfo = { - ? "registration_time": uint .within (~time), - * tstr => any -} ~~~ ## Validation of Transparent Statements From 1e6886aedb7b9b2c0d2ce637ff8ad570350222da Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Tue, 5 Dec 2023 06:21:20 -0800 Subject: [PATCH 02/12] Update draft-ietf-scitt-architecture.md Co-authored-by: Orie Steele --- draft-ietf-scitt-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index cfecd14e..f8137049 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -573,7 +573,7 @@ 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 the mandatory metadata in the non-opaque Envelope of a Signed Statement. +For interoperability, Registration Policy decisions should be based on interpretation of the mandatory metadata in the protected header of a Signed Statement. 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. From f41232f91f65fa8bcdba328d35c107f1996d360f Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Tue, 5 Dec 2023 06:21:45 -0800 Subject: [PATCH 03/12] Update draft-ietf-scitt-architecture.md Co-authored-by: Orie Steele --- draft-ietf-scitt-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index f8137049..c323c8e4 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -781,7 +781,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 the attributes required by the policy are present in the protected headers. +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 From b6ec5f8deb34226928ba7760e36c722f13ffe84b Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Tue, 5 Dec 2023 07:28:44 -0800 Subject: [PATCH 04/12] Update draft-ietf-scitt-architecture.md Co-authored-by: Orie Steele --- draft-ietf-scitt-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index c323c8e4..028f5275 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -808,7 +808,7 @@ The following requirements for the COSE signature of the Merkle Root are added: - 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 the Registration policy info header to indicate to Verifiers what policies have been applied at the registration of this Statement +- 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 Transparency Service may include the registration time to help Verifiers decide about the trustworthiness of the Transparent Statement. From c22d51b283ef9564267c819688094d6ab817d362 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Tue, 5 Dec 2023 08:52:29 -0800 Subject: [PATCH 05/12] Update draft-ietf-scitt-architecture.md --- draft-ietf-scitt-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index bf3f953b..ef48ae5b 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -787,7 +787,7 @@ CWT_Claims = { Protected_Header = { 1 => int ; algorithm identifier, 4 => bstr ; Key ID, - 13 => CWT_Claims ; CBOR Web Token Claims, + 15 => CWT_Claims ; CBOR Web Token Claims, 3 => tstr ; payload type } From 2ce3156638fa135ee4408c1b1b99cc97bf399af6 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Tue, 5 Dec 2023 08:52:36 -0800 Subject: [PATCH 06/12] Update draft-ietf-scitt-architecture.md --- draft-ietf-scitt-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index ef48ae5b..2e36606a 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -421,7 +421,7 @@ CWT_Claims = { Protected_Header = { 1 => int ; algorithm identifier, 4 => bstr ; Key ID (kid), - 13 => CWT_Claims ; CBOR Web Token Claims, + 15 => CWT_Claims ; CBOR Web Token Claims, 3 => tstr ; payload type } ~~~ From f439f89c88b2038ef67ce6b6c0b418e64cbcc0ab Mon Sep 17 00:00:00 2001 From: steve lasker Date: Mon, 4 Dec 2023 22:04:46 -0800 Subject: [PATCH 07/12] Fix merge conflicts Signed-off-by: steve lasker --- draft-ietf-scitt-architecture.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index 2e36606a..3b6eaf2c 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -861,6 +861,9 @@ The registration time is defined as the timestamp at which the Transparency Serv Editor's Note: The WG is discussing if existing CWT claims might better support these design principles. +~~~ cddl +label = int / tstr +value = any ; Additional protected headers ; in the COSE signed_tree_root of the SignedMerkleTreeProof Protected_Header = { From 4301c8d1399189ef64e58f7a8124dbf1b7d7e84b Mon Sep 17 00:00:00 2001 From: steve lasker Date: Mon, 4 Dec 2023 22:26:08 -0800 Subject: [PATCH 08/12] Fix merge conflicts Signed-off-by: steve lasker --- draft-ietf-scitt-architecture.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index 3b6eaf2c..23f59d2a 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -864,11 +864,6 @@ Editor's Note: The WG is discussing if existing CWT claims might better support ~~~ cddl label = int / tstr value = any -; Additional protected headers -; in the COSE signed_tree_root of the SignedMerkleTreeProof -Protected_Header = { - 390 => int ; SCITT Receipt Version - 394 => tstr ; DID of Transparency Service (required) Receipt_Unprotected_Header = { &(scitt-inclusion-proof: 396) => bstr .cbor inclusion-proof From 1720d0b8ce4a10658ba2361712c0e3089c2dcb4b Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Tue, 5 Dec 2023 11:40:53 -0800 Subject: [PATCH 09/12] Update draft-ietf-scitt-architecture.md Fixup of merge conflict --- draft-ietf-scitt-architecture.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index 23f59d2a..586a6258 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -862,9 +862,6 @@ The registration time is defined as the timestamp at which the Transparency Serv 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 } From 5e30c650c323eec1d1a6348cfeccee7558e5ff6f Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Thu, 7 Dec 2023 09:29:41 +0100 Subject: [PATCH 10/12] some header re-shuffeling --- draft-ietf-scitt-architecture.md | 32 +++++++++++++++----------------- 1 file changed, 15 insertions(+), 17 deletions(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index 586a6258..44e8b4cd 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -15,6 +15,11 @@ submissiontype: IETF kramdown_options: auto_id_prefix: sec- +venue: + group: SCITT + mail: scitt@ietf.org + github: ietf-wg-scitt/draft-ietf-scitt-architecture + author: - name: Henk Birkholz org: Fraunhofer SIT @@ -74,12 +79,9 @@ normative: RFC9360: IANA.params: 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 + RFC9393: COSWID + I-D.ietf-cose-cwt-claims-in-headers: CWT-CLAIMS-COSE + informative: I-D.draft-steele-cose-merkle-tree-proofs: COMETRE PBFT: DOI.10.1145/571637.571640 @@ -93,7 +95,7 @@ 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 @@ -105,25 +107,21 @@ informative: 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: scitt@ietf.org - 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. @@ -755,7 +753,7 @@ 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.
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
Example: `did:web:example.com` From 7329b259f7672237f67f959ef2f8758870e0fd86 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Thu, 7 Dec 2023 09:32:06 +0100 Subject: [PATCH 11/12] and removed my own lint... --- draft-ietf-scitt-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index 44e8b4cd..5c5ae74f 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -80,7 +80,7 @@ normative: IANA.params: IANA.cose: RFC9393: COSWID - I-D.ietf-cose-cwt-claims-in-headers: CWT-CLAIMS-COSE + I-D.ietf-cose-cwt-claims-in-headers: CWT-CLAIMS-COSE informative: I-D.draft-steele-cose-merkle-tree-proofs: COMETRE From d8d8695de57b593c0e30a39751dcc48ba7483759 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Mon, 11 Dec 2023 19:52:32 -0800 Subject: [PATCH 12/12] Update draft-ietf-scitt-architecture.md Co-authored-by: A.J. Stein --- draft-ietf-scitt-architecture.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index 5c5ae74f..189b0d84 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -79,8 +79,8 @@ normative: RFC9360: IANA.params: IANA.cose: - RFC9393: COSWID - I-D.ietf-cose-cwt-claims-in-headers: CWT-CLAIMS-COSE + COSWID: RFC9393 + CWT_CLAIMS_COSE: I-D.ietf-cose-cwt-claims-in-headers informative: I-D.draft-steele-cose-merkle-tree-proofs: COMETRE