Code change:
govern whether or not a given Signed Statement is eligible for registration. <del> 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. </del> <ins> 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. </ins> This specification leaves implementation, encoding and documentation <del> of Registration Policies to the operator of the Transparency Service. </del> <ins> of Registration Policies and trust anchors to the operator of the Transparency Service. </ins> 4.1.1.1. <del> Transparency Services MUST, at a minimum, perform the following checks before registering a Signed Statement: Authenticate the Issuer of the Signed Statement 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." Before a Signed Statement is registered, the trust anchor used to verify its Issuer MUST be registered with the Transparency Service. </del> <ins> 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. 4.1.1.2. 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. 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). </ins> 4.1.2. <del> 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: </del> <ins> 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: </ins> <del> A built-in default Registration Policy </del> <ins> A built-in default Registration Policy and initial list of trust anchors; </ins> Acceptance of a first Signed Statement whose payload is a valid <del> Registration Policy, without performing registration checks </del> <ins> Registration Policy and trust anchors, omitting the normal registration checks; </ins> <del> An out-of-band authenticated management interface </del> <ins> An out-of-band authenticated management interface to configure the registration policy and trust anchors. </ins> 4.1.3.

Related discussion:
text: Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! URL Email: NAME NAME Tel: +1 978-696-1788
Yes, that's what I called the "TS certificates", i.e. the certificate used to sign the COSE receipt/countersignature. That's the only certificate relying parties would care about - if there are other internal certificates it's up to the TS implementation to expose the details to auditors through the audit API
Antoine, What is the set of criteria that the TS should use during the registration policy evaluation? Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! URL Email: NAME NAME Tel: +1 978-696-1788 From: Antoine Delignat-Lavaud NAME Sent: Monday, March 4, 2024 8:50 AM To: ietf-wg-scitt/draft-ietf-scitt-architecture NAME Cc: Dick Brooks (REA) NAME Mention NAME Subject: Re: [ietf-wg-scitt/draft-ietf-scitt-architecture] Registration auditability requirements () (PR ) NAME commented on this pull request. In draft-ietf-scitt-URL : -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 (34), (33) and (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 , 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. See the updated comment thread on line 403 (now 405) about possible weakening of this requirement — Reply to this email directly, view it on GitHub , or unsubscribe .