Code change:
sense for their operational use cases. At least one identifier for an identity document MUST be included in <del> the protected header of the COSE envelope, either "x5t" or "kid". </del> <ins> the protected header of the COSE envelope, as one of "x5t", "x5chain" or "kid". </ins> Support for "x5t" is mandatory to implement. <del> Support for "kid" is optional. </del> <ins> Support for "kid" and "x5chain" is optional. </ins> <del> 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. </del> <ins> 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. </ins> The mechanisms for how Transparency Services obtain identity documents is out-of-scope of this document. <del> The "kid" header parameter MUST be present when the "x5t" header parameter is not present.  Key discovery protocols are out-of-scope of this document. </del> <ins> The "kid" header parameter MUST be present when neither "x5t" nor "x5chain" are present.  Key discovery protocols are out-of-scope of this document. </ins> The protected header of a Signed Statement and a Receipt MUST include the "CWT Claims" header parameter as specified in CWT_CLAIMS_COSE.

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 .