From 189bd1fdd55de870f24b5b3cd6f1fec124bae0a9 Mon Sep 17 00:00:00 2001 From: Antoine Delignat-Lavaud Date: Thu, 29 Feb 2024 19:54:36 +0000 Subject: [PATCH 01/22] Registration auditability requirements (#200) --- draft-ietf-scitt-architecture.md | 43 ++++++++++++++++++-------------- 1 file changed, 24 insertions(+), 19 deletions(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index 07b3bff0..5bc39514 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -151,7 +151,7 @@ Its goal is to enhance auditability and accountability across supply chains. In supply chains, downstream artifacts are built upon upstream artifacts. The complexity of traceability and quality control for these supply chains increases with the number of artifacts and parties contributing to them. -There are many parties who publish information about artifacts: +There are many parties who publish information about artifacts. For example, the original manufacturer may provide information about the state of the artifact when it left the factory. The shipping company may add information about the transport environment of the artifact. Compliance auditors may provide information about their compliance assessment of the artifact. @@ -256,7 +256,7 @@ In SCITT, `sub` identifies the entity about which statements, and receipts are m The subject value MUST either be scoped to be locally unique in the context of the Issuer or be globally unique. The processing of this claim is generally application specific. The `sub` value is a case-sensitive string containing a StringOrURI value. -Issuer's use `sub` to identify the entity about which they are making Signed Statements. +Issuers use `sub` to identify the entity about which they are making Signed Statements. Transparency Services use `sub` to identify the entity about which they are issuing a Receipt. Transparency Service: @@ -388,32 +388,36 @@ Registration Policies refer to additional checks over and above the Mandatory Re 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. +Transparency Services MUST also maintain a list of trust anchors used to authenticate Issuers, which MAY be included in the registration policy statement. +For instance, a trust anchor could be an X.509 root certificate, the discovery URL of an OpenID Connect identity provider, a trusted DID resolver, a GPG keyserver, or any other PKI trust anchor. +Registration Policies and trust anchors MUST be made transparent and available to all clients of the Transparency Service by registering them as Signed Statements on the Append-only Log. - -This specification leaves implementation, encoding and documentation of Registration Policies to the operator of the Transparency Service. +This specification leaves implementation, encoding and documentation of Registration Policies and trust anchors to the operator of the Transparency Service. #### Mandatory Registration Checks -Transparency Services MUST, at a minimum, perform the following checks before registering a Signed Statement: +During registration, a Transparency Services MUST, at a minimum, authenticate the Issuer of the Signed Statement by validating the COSE signature and checking the identity of the issuer against one of its configured trust anchors, using the `x5t`, `x5chain` and `kid` protected headers of the Signed Statement as hints. +For instance, for X.509 signed claims, the Transparency Service must build and validate a complete certificate chain from the Issuer's certificate identified by `x5t`, to one of the root certificates most recently registered as a trust anchor of the Transparency Service. + +The Transparency Service MUST evaluate the registration policy that was most recently added to the Append-only Log for instance-specific registration checks. -- Authenticate the Issuer of the Signed Statement +#### Auditability of Registration -The Transparency Service MUST authenticate the Issuer of Signed Statements by validating the COSE signature and checking the identity of the issuer through one of its configured trust anchors, using the `x5t` and `kid` headers in the protected header as hints. For instance, for X.509 signed claims the Transparency Service must validate a complete certificate chain from the certificate identified by `x5t` to one of the trusted root authority certificate of the Transparency Service. -The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative." +The operator of a Transparency Service MAY update the registration policy or the trust anchors of a transparency service at any time. +This presents a challenge to Auditors and Relying Parties if they cannot determine what policy was used to register a given Transparent Statement. +Transparency Services MUST ensure that for any Transparent Statment they accept, enough information is made available to Auditors (either in the Append-only Log and retrievable through audit APIs, or included in the Receipt) to identify and recover the Transparent Statements describing the registration policy and trust anchors that were in use at the time that Transparent Statement was registered. -Before a Signed Statement is registered, the trust anchor used to verify its Issuer MUST be registered with the Transparency Service. +In particular, this information SHOULD enable Auditors to re-validate the mandatory Issuer authentication check, unless the required information isn't available (e.g. the authentication protocol is not verifiable), or it is confidential (e.g. an OAuth access token embedding the Issuer's pubic key), or it is private (e.g. a Issuer certificate containing the name and email address of a developer). ### Initialization and bootstrapping {#ts-initialization} -Since a Registration Policy is required prior to the registration of any Signed Statements, a means is required to configure the first Registration Policy that is not the standard issuance of a Signed Statement. -Transparency Services MUST support at least one of these methods: +Since the mandatory registration checks rely on having registered Signed Statements for the registration policy and trust anchors, Transparency Services MUST support at least one of the three following bootstrapping mechanisms: -- A built-in default Registration Policy -- Acceptance of a first Signed Statement whose payload is a valid Registration Policy, without performing registration checks -- An out-of-band authenticated management interface +- A built-in default Registration Policy and initial list of trust anchors; +- Acceptance of a first Signed Statement whose payload is a valid Registration Policy and trust anchors, omitting the normal registration checks; +- An out-of-band authenticated management interface to configure the registration policy and trust anchors. ### Append-only Log @@ -435,16 +439,16 @@ This specification prioritizes conformance to {{RFC9052}} and its required and o Profiles and implementation specific choices should be used to determine admissability of conforming messages. This specification is left intentionally open to allow implementations to make the restrictions that make the most sense for their operational use cases. -At least one identifier for an identity document MUST be included in the protected header of the COSE envelope, either `x5t` or `kid`. +At least one identifier for an identity document MUST be included in the protected header of the COSE envelope, as one of `x5t`, `x5chain` or `kid`. -- Support for `x5t` is mandatory to implement. +- Support for `x5t` and `x5chain` is mandatory to implement. - Support for `kid` is optional. -When `x5t` is present, `iss` MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a distinguished name. +When `x5t` or `x5chain` is present, `iss` MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a distinguished name. The mechanisms for how Transparency Services obtain identity documents is out-of-scope of this document. -The `kid` header parameter MUST be present when the `x5t` header parameter is not present. +The `kid` header parameter MUST be present when neither `x5t` nor `x5chain` are present. Key discovery protocols are out-of-scope of this document. The protected header of a Signed Statement and a Receipt MUST include the `CWT Claims` header parameter as specified in {{Section 2 of CWT_CLAIMS_COSE}}. @@ -474,6 +478,7 @@ Protected_Header = { ? &(alg: 1) => int ? &(content_type: 3) => tstr / uint ? &(kid: 4) => bstr + ? &(x5chain: 33) => COSE_X509 ? &(x5t: 34) => COSE_CertHash * int => any } From f56dd47ef24545c16b48a8216ac6ae109ce9aaef Mon Sep 17 00:00:00 2001 From: Antoine Delignat-Lavaud Date: Thu, 29 Feb 2024 21:22:39 +0000 Subject: [PATCH 02/22] 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 5bc39514..aed6768f 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -389,7 +389,7 @@ Registration Policies refer to additional checks over and above the Mandatory Re Transparency Services MUST maintain Registration Policies which govern whether or not a given Signed Statement is eligible for registration. Transparency Services MUST also maintain a list of trust anchors used to authenticate Issuers, which MAY be included in the registration policy statement. -For instance, a trust anchor could be an X.509 root certificate, the discovery URL of an OpenID Connect identity provider, a trusted DID resolver, a GPG keyserver, or any other PKI trust anchor. +For instance, a trust anchor could be an X.509 root certificate, the discovery URL of an OpenID Connect identity provider, or any other COSE compatible PKI trust anchor. Registration Policies and trust anchors MUST be made transparent and available to all clients of the Transparency Service by registering them as Signed Statements on the Append-only Log. From fcec1ccc33a1695af28b8fc6e552e2b647b35839 Mon Sep 17 00:00:00 2001 From: Antoine Delignat-Lavaud Date: Thu, 29 Feb 2024 21:24:28 +0000 Subject: [PATCH 03/22] 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 aed6768f..1cc21efc 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -397,7 +397,7 @@ This specification leaves implementation, encoding and documentation of Registra #### Mandatory Registration Checks -During registration, a Transparency Services MUST, at a minimum, authenticate the Issuer of the Signed Statement by validating the COSE signature and checking the identity of the issuer against one of its configured trust anchors, using the `x5t`, `x5chain` and `kid` protected headers of the Signed Statement as hints. +During registration, a Transparency Services MUST, at a minimum, authenticate the Issuer of the Signed Statement by validating the COSE signature and checking the identity of the issuer against one of its configured trust anchors, using the `x5t` (34), `x5chain`(33) and `kid`(4) protected headers of the Signed Statement as hints. For instance, for X.509 signed claims, the Transparency Service must build and validate a complete certificate chain from the Issuer's certificate identified by `x5t`, to one of the root certificates most recently registered as a trust anchor of the Transparency Service. The Transparency Service MUST evaluate the registration policy that was most recently added to the Append-only Log for instance-specific registration checks. From c4ed10a48c8c9158ec15acaac4b9fb96b072b6bc Mon Sep 17 00:00:00 2001 From: Antoine Delignat-Lavaud Date: Thu, 29 Feb 2024 21:24:52 +0000 Subject: [PATCH 04/22] 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 1cc21efc..028fbe0d 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -398,7 +398,7 @@ This specification leaves implementation, encoding and documentation of Registra #### Mandatory Registration Checks During registration, a Transparency Services MUST, at a minimum, authenticate the Issuer of the Signed Statement by validating the COSE signature and checking the identity of the issuer against one of its configured trust anchors, using the `x5t` (34), `x5chain`(33) and `kid`(4) protected headers of the Signed Statement as hints. -For instance, for X.509 signed claims, the Transparency Service must build and validate a complete certificate chain from the Issuer's certificate identified by `x5t`, to one of the root certificates most recently registered as a trust anchor of the Transparency Service. +For instance, in order to authenticate X.509 Signed Statements, the Transparency Service MUST build and validate a complete certificate chain from the Issuer's certificate identified by `x5t`, to one of the root certificates most recently registered as a trust anchor of the Transparency Service. The Transparency Service MUST evaluate the registration policy that was most recently added to the Append-only Log for instance-specific registration checks. From 33248072171eab52f73d14c0be07e55c50d38530 Mon Sep 17 00:00:00 2001 From: Antoine Delignat-Lavaud Date: Thu, 29 Feb 2024 21:27:18 +0000 Subject: [PATCH 05/22] 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 028fbe0d..cc6ad8f7 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -400,7 +400,7 @@ This specification leaves implementation, encoding and documentation of Registra During registration, a Transparency Services MUST, at a minimum, authenticate the Issuer of the Signed Statement by validating the COSE signature and checking the identity of the issuer against one of its configured trust anchors, using the `x5t` (34), `x5chain`(33) and `kid`(4) protected headers of the Signed Statement as hints. For instance, in order to authenticate X.509 Signed Statements, the Transparency Service MUST build and validate a complete certificate chain from the Issuer's certificate identified by `x5t`, to one of the root certificates most recently registered as a trust anchor of the Transparency Service. -The Transparency Service MUST evaluate the registration policy that was most recently added to the Append-only Log for instance-specific registration checks. +The Transparency Service MUST evaluate the registration policy that was most recently added to the Append-only Log. #### Auditability of Registration From 1c797fdf9b1f9576b4b1634ec7616eaa214528bf Mon Sep 17 00:00:00 2001 From: Antoine Delignat-Lavaud Date: Thu, 29 Feb 2024 21:30:00 +0000 Subject: [PATCH 06/22] Update draft-ietf-scitt-architecture.md Do not make x5chain mandatory to implement --- 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 cc6ad8f7..35fa2e19 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -441,7 +441,7 @@ This specification is left intentionally open to allow implementations to make t At least one identifier for an identity document MUST be included in the protected header of the COSE envelope, as one of `x5t`, `x5chain` or `kid`. -- Support for `x5t` and `x5chain` is mandatory to implement. +Support for `x5t` is mandatory to implement. - Support for `kid` is optional. When `x5t` or `x5chain` is present, `iss` MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a distinguished name. From feae0aa0443c87ca2dd49ac92abdebbcf3b56cd3 Mon Sep 17 00:00:00 2001 From: Antoine Delignat-Lavaud Date: Thu, 29 Feb 2024 21:30:47 +0000 Subject: [PATCH 07/22] Update draft-ietf-scitt-architecture.md Editorial mistake --- 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 35fa2e19..d2cee6d9 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -441,7 +441,7 @@ This specification is left intentionally open to allow implementations to make t At least one identifier for an identity document MUST be included in the protected header of the COSE envelope, as one of `x5t`, `x5chain` or `kid`. -Support for `x5t` is mandatory to implement. +- Support for `x5t` is mandatory to implement. - Support for `kid` is optional. When `x5t` or `x5chain` is present, `iss` MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a distinguished name. From 47ca4c28a58c6b2f3a5be68749823b43951eba38 Mon Sep 17 00:00:00 2001 From: Antoine Delignat-Lavaud Date: Thu, 29 Feb 2024 21:31:55 +0000 Subject: [PATCH 08/22] Update draft-ietf-scitt-architecture.md x5chain optional --- 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 d2cee6d9..84f2f82e 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -442,7 +442,7 @@ This specification is left intentionally open to allow implementations to make t At least one identifier for an identity document MUST be included in the protected header of the COSE envelope, as one of `x5t`, `x5chain` or `kid`. - Support for `x5t` is mandatory to implement. -- Support for `kid` is optional. +- Support for `kid` and `x5chain` is optional. When `x5t` or `x5chain` is present, `iss` MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a distinguished name. From 47cc0a309d139826bc72dd87616583f79b7e6901 Mon Sep 17 00:00:00 2001 From: Antoine Delignat-Lavaud Date: Fri, 1 Mar 2024 00:15:16 +0000 Subject: [PATCH 09/22] Update draft-ietf-scitt-architecture.md Co-authored-by: A.J. Stein --- 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 84f2f82e..4d86272c 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -151,7 +151,7 @@ Its goal is to enhance auditability and accountability across supply chains. In supply chains, downstream artifacts are built upon upstream artifacts. The complexity of traceability and quality control for these supply chains increases with the number of artifacts and parties contributing to them. -There are many parties who publish information about artifacts. +There are many parties who publish information about artifacts: For example, the original manufacturer may provide information about the state of the artifact when it left the factory. The shipping company may add information about the transport environment of the artifact. Compliance auditors may provide information about their compliance assessment of the artifact. From 45bbb17e83410ef04191001dd0e2f9159bbc5698 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Fri, 1 Mar 2024 08:08:47 -0800 Subject: [PATCH 10/22] 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 4d86272c..04f30ca8 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -400,7 +400,7 @@ This specification leaves implementation, encoding and documentation of Registra During registration, a Transparency Services MUST, at a minimum, authenticate the Issuer of the Signed Statement by validating the COSE signature and checking the identity of the issuer against one of its configured trust anchors, using the `x5t` (34), `x5chain`(33) and `kid`(4) protected headers of the Signed Statement as hints. For instance, in order to authenticate X.509 Signed Statements, the Transparency Service MUST build and validate a complete certificate chain from the Issuer's certificate identified by `x5t`, to one of the root certificates most recently registered as a trust anchor of the Transparency Service. -The Transparency Service MUST evaluate the registration policy that was most recently added to the Append-only Log. +The Transparency Service MUST evaluate the Registration Policy that was most recently added to the Append-only Log. #### Auditability of Registration From 5dbddb4b5b94d179b00c74999175e4667cc0dc48 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Fri, 1 Mar 2024 08:12:16 -0800 Subject: [PATCH 11/22] Update draft-ietf-scitt-architecture.md merging for clarity Co-authored-by: robinbryce --- 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 04f30ca8..924e8f12 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -407,7 +407,7 @@ The Transparency Service MUST evaluate the Registration Policy that was most rec The operator of a Transparency Service MAY update the registration policy or the trust anchors of a transparency service at any time. This presents a challenge to Auditors and Relying Parties if they cannot determine what policy was used to register a given Transparent Statement. -Transparency Services MUST ensure that for any Transparent Statment they accept, enough information is made available to Auditors (either in the Append-only Log and retrievable through audit APIs, or included in the Receipt) to identify and recover the Transparent Statements describing the registration policy and trust anchors that were in use at the time that Transparent Statement was registered. +Transparency Services MUST ensure that for any Transparent Statment they accept, enough information is made available to Auditors (either in the Append-only Log and retrievable through audit APIs, or included in the Receipt) to identify and recover the Transparent Statements describing the registration policy and trust anchors that are applicable to the Transparent Statement. In particular, this information SHOULD enable Auditors to re-validate the mandatory Issuer authentication check, unless the required information isn't available (e.g. the authentication protocol is not verifiable), or it is confidential (e.g. an OAuth access token embedding the Issuer's pubic key), or it is private (e.g. a Issuer certificate containing the name and email address of a developer). From 6fd5e3f96b76d7251b3c18d7a43e7609f10813ae Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Fri, 1 Mar 2024 09:29:43 -0800 Subject: [PATCH 12/22] 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 924e8f12..2a2bcd42 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -404,7 +404,7 @@ The Transparency Service MUST evaluate the Registration Policy that was most rec #### Auditability of Registration -The operator of a Transparency Service MAY update the registration policy or the trust anchors of a transparency service at any time. +The operator of a Transparency Service MAY update the Registration Policy or the trust anchors of a Transparency Service at any time. This presents a challenge to Auditors and Relying Parties if they cannot determine what policy was used to register a given Transparent Statement. Transparency Services MUST ensure that for any Transparent Statment they accept, enough information is made available to Auditors (either in the Append-only Log and retrievable through audit APIs, or included in the Receipt) to identify and recover the Transparent Statements describing the registration policy and trust anchors that are applicable to the Transparent Statement. From d085b8730c733b37f12f68df04bb193f79e4c6f5 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Fri, 1 Mar 2024 13:01:46 -0800 Subject: [PATCH 13/22] Update draft-ietf-scitt-architecture.md --- draft-ietf-scitt-architecture.md | 1 - 1 file changed, 1 deletion(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index 2a2bcd42..e7ee5641 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -405,7 +405,6 @@ The Transparency Service MUST evaluate the Registration Policy that was most rec #### Auditability of Registration The operator of a Transparency Service MAY update the Registration Policy or the trust anchors of a Transparency Service at any time. -This presents a challenge to Auditors and Relying Parties if they cannot determine what policy was used to register a given Transparent Statement. Transparency Services MUST ensure that for any Transparent Statment they accept, enough information is made available to Auditors (either in the Append-only Log and retrievable through audit APIs, or included in the Receipt) to identify and recover the Transparent Statements describing the registration policy and trust anchors that are applicable to the Transparent Statement. From 663b20a087fa65bb8015d9442450e6bcbdc3c273 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Fri, 1 Mar 2024 13:03:59 -0800 Subject: [PATCH 14/22] Update draft-ietf-scitt-architecture.md Co-authored-by: Jon Geater --- 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 e7ee5641..570a8f7d 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -391,7 +391,7 @@ Transparency Services MUST maintain Registration Policies which govern whether o Transparency Services MUST also maintain a list of trust anchors used to authenticate Issuers, which MAY be included in the registration policy statement. For instance, a trust anchor could be an X.509 root certificate, the discovery URL of an OpenID Connect identity provider, or any other COSE compatible PKI trust anchor. -Registration Policies and trust anchors 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 and trust anchors MUST be made transparent and available to all authorised clients of the Transparency Service by registering them as Signed Statements on the Append-only Log. This specification leaves implementation, encoding and documentation of Registration Policies and trust anchors to the operator of the Transparency Service. From 025fa59b16f0ce9f59c497b51a768a831702ba36 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Fri, 1 Mar 2024 13:05:54 -0800 Subject: [PATCH 15/22] Update draft-ietf-scitt-architecture.md Co-authored-by: Jon Geater --- 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 570a8f7d..6bcb84a7 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -397,7 +397,7 @@ This specification leaves implementation, encoding and documentation of Registra #### Mandatory Registration Checks -During registration, a Transparency Services MUST, at a minimum, authenticate the Issuer of the Signed Statement by validating the COSE signature and checking the identity of the issuer against one of its configured trust anchors, using the `x5t` (34), `x5chain`(33) and `kid`(4) protected headers of the Signed Statement as hints. +During registration, a Transparency Service MUST, at a minimum, authenticate the Issuer of the Signed Statement by validating the COSE signature and checking the identity of the issuer against one of its configured trust anchors, using the `x5t` (34), `x5chain`(33) or `kid`(4) protected headers of the Signed Statement as hints. For instance, in order to authenticate X.509 Signed Statements, the Transparency Service MUST build and validate a complete certificate chain from the Issuer's certificate identified by `x5t`, to one of the root certificates most recently registered as a trust anchor of the Transparency Service. The Transparency Service MUST evaluate the Registration Policy that was most recently added to the Append-only Log. From 1d2a20344e2f507b5a7051f64ee0c7e30f8644d6 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Fri, 1 Mar 2024 13:07:13 -0800 Subject: [PATCH 16/22] Update draft-ietf-scitt-architecture.md Co-authored-by: Jon Geater --- draft-ietf-scitt-architecture.md | 1 - 1 file changed, 1 deletion(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index 6bcb84a7..d1f35fee 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -408,7 +408,6 @@ The operator of a Transparency Service MAY update the Registration Policy or the Transparency Services MUST ensure that for any Transparent Statment they accept, enough information is made available to Auditors (either in the Append-only Log and retrievable through audit APIs, or included in the Receipt) to identify and recover the Transparent Statements describing the registration policy and trust anchors that are applicable to the Transparent Statement. -In particular, this information SHOULD enable Auditors to re-validate the mandatory Issuer authentication check, unless the required information isn't available (e.g. the authentication protocol is not verifiable), or it is confidential (e.g. an OAuth access token embedding the Issuer's pubic key), or it is private (e.g. a Issuer certificate containing the name and email address of a developer). ### Initialization and bootstrapping {#ts-initialization} From e4d7d9a4c11a4bc50b4a6efb08e8adec6b37c5de Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Sat, 2 Mar 2024 08:54:59 -0800 Subject: [PATCH 17/22] 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 d1f35fee..f570f95a 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -386,7 +386,7 @@ 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. +Transparency Services MUST maintain Registration Policies. Transparency Services MUST also maintain a list of trust anchors used to authenticate Issuers, which MAY be included in the registration policy statement. For instance, a trust anchor could be an X.509 root certificate, the discovery URL of an OpenID Connect identity provider, or any other COSE compatible PKI trust anchor. From f7913ebe366a7bd0038bb1141731794f3a9be4f2 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Mon, 4 Mar 2024 07:21:24 -0800 Subject: [PATCH 18/22] Update draft-ietf-scitt-architecture.md Co-authored-by: fournet --- 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 a857febe..5d43b2b6 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -402,7 +402,7 @@ This specification leaves implementation, encoding and documentation of Registra During registration, a Transparency Service MUST, at a minimum, authenticate the Issuer of the Signed Statement by validating the COSE signature and checking the identity of the issuer against one of its currently configured trust anchors, using the `x5t` (34), `x5chain`(33) or `kid`(4) protected headers of the Signed Statement as hints. For instance, in order to authenticate X.509 Signed Statements, the Transparency Service MUST build and validate a complete certificate chain from the Issuer's certificate identified by `x5t`, to one of the root certificates most recently registered as a trust anchor of the Transparency Service. -The Transparency Service MUST evaluate the Registration Policy that was most recently added to the Append-only Log. +The Transparency Service MUST apply the Registration Policy that was most recently added to the Append-only Log at the time of registration. #### Auditability of Registration From aae403e43889e71c25f46b68c02d10a0e04597bf Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Mon, 4 Mar 2024 07:25:45 -0800 Subject: [PATCH 19/22] Update draft-ietf-scitt-architecture.md Co-authored-by: fournet --- 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 5d43b2b6..b9756deb 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -408,7 +408,7 @@ The Transparency Service MUST apply the Registration Policy that was most recent The operator of a Transparency Service MAY update the Registration Policy or the trust anchors of a Transparency Service at any time. -Transparency Services MUST ensure that for any Transparent Statment they accept, enough information is made available to Auditors (either in the Append-only Log and retrievable through audit APIs, or included in the Receipt) to identify and recover the Transparent Statements describing the registration policy and trust anchors that are applicable to the Transparent Statement. +Transparency Services MUST ensure that for any Signed Statement they register, enough information is made available to Auditors (either in the Append-only Log and retrievable through audit APIs, or included in the Receipt) to authenticate and retrieve the Transparent Statements describing the registration policy and trust anchors that apply to this registration. ### Initialization and bootstrapping {#ts-initialization} From b9f43535928426bfabf6fa99bef597e4e875f7df Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Mon, 4 Mar 2024 07:32:00 -0800 Subject: [PATCH 20/22] 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 b9756deb..74308a24 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -415,7 +415,7 @@ Transparency Services MUST ensure that for any Signed Statement they register, e Since the mandatory registration checks rely on having registered Signed Statements for the registration policy and trust anchors, Transparency Services MUST support at least one of the three following bootstrapping mechanisms: - A built-in default Registration Policy and default trust anchors; -- Acceptance of a first Signed Statement whose payload is a valid Registration Policy and trust anchors, omitting the normal registration checks; +- Acceptance of a first Signed Statement whose payload is a valid Registration Policy, without performing registration checks - An out-of-band authenticated management interface to configure the registration policy and trust anchors. ### Append-only Log From 509c9350a3dedb803465b41d60657d805dcc34a2 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Mon, 4 Mar 2024 07:32:44 -0800 Subject: [PATCH 21/22] 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 74308a24..abfac3e2 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -416,7 +416,7 @@ Since the mandatory registration checks rely on having registered Signed Stateme - A built-in default Registration Policy and default trust anchors; - Acceptance of a first Signed Statement whose payload is a valid Registration Policy, without performing registration checks -- An out-of-band authenticated management interface to configure the registration policy and trust anchors. +- An out-of-band authenticated management interface ### Append-only Log From 80c4ff9cc82a6a35f9dd9abb3d57d5f744c0687b Mon Sep 17 00:00:00 2001 From: Antoine Delignat-Lavaud Date: Mon, 4 Mar 2024 15:38:52 +0000 Subject: [PATCH 22/22] Fix lint --- 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 abfac3e2..7f01c050 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -402,13 +402,13 @@ This specification leaves implementation, encoding and documentation of Registra During registration, a Transparency Service MUST, at a minimum, authenticate the Issuer of the Signed Statement by validating the COSE signature and checking the identity of the issuer against one of its currently configured trust anchors, using the `x5t` (34), `x5chain`(33) or `kid`(4) protected headers of the Signed Statement as hints. For instance, in order to authenticate X.509 Signed Statements, the Transparency Service MUST build and validate a complete certificate chain from the Issuer's certificate identified by `x5t`, to one of the root certificates most recently registered as a trust anchor of the Transparency Service. -The Transparency Service MUST apply the Registration Policy that was most recently added to the Append-only Log at the time of registration. +The Transparency Service MUST apply the Registration Policy that was most recently added to the Append-only Log at the time of registration. #### Auditability of Registration The operator of a Transparency Service MAY update the Registration Policy or the trust anchors of a Transparency Service at any time. -Transparency Services MUST ensure that for any Signed Statement they register, enough information is made available to Auditors (either in the Append-only Log and retrievable through audit APIs, or included in the Receipt) to authenticate and retrieve the Transparent Statements describing the registration policy and trust anchors that apply to this registration. +Transparency Services MUST ensure that for any Signed Statement they register, enough information is made available to Auditors (either in the Append-only Log and retrievable through audit APIs, or included in the Receipt) to authenticate and retrieve the Transparent Statements describing the registration policy and trust anchors that apply to this registration. ### Initialization and bootstrapping {#ts-initialization}