Original text:
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>  Support for "x5t" is mandatory to implement. <del> Support for "kid" is optional. </del>  <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>  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>  The protected header of a Signed Statement and a Receipt MUST include the "CWT Claims" header parameter as specified in CWT_CLAIMS_COSE.

Reviewer comments:
My take on trying to make registration auditable. This is still very open-ended in terms of implementation choice
I have made optional, but still supported
Steve, Is it too late to add another service API to SCRAPI: Retrieve Registration Policy 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
Hi, NAME Once the Architecture is settled, we plan to put more focus on SCRAPI, and yes, we can certainly add/edit/remove.
NAME this PR contains guidance for SCRAPI enabling registration policies to be retrieved: URL It also adds optional endpoints for retrieving signature and payloads, not just receipts.
Thanks NAME NAME I'm still not sure how the architecture handles a revoked certificate used to sign the registry log. Would a new log be started with a different signing key and the old log would remain available for reference - with a warning that the signing key has been revoked or is expired? Still trying to figure out implementation details so that REA can support the initiative. I assume the results of a SCRAPI query would contain a warning that the returned results are from a log that has a revoked signing key.
SCITT does not have any messages currently related to revoked certificates. What messages do you propose?
It can be as simple as a warning in response to a query i.e. “Warning: The signing certificate has been revoked or has expired” 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
Dealing with expired or revoked TS certificates should be straightforward, as you can always obtain a fresh receipt for a previously registered transparent statement. For issuer certificate this is a non-issue as SCITT only guarantees the issuer certificate was valid at registration.
Thanks, Antoine. Is this also the case when the certificate used to maintain log integrity has been revoked or has expired. I’m presuming the registry log integrity is also maintained using a digital certificate – correct? 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 . You are receiving this because you were mentioned.Message ID: NAME
Since the refactor and the shift to X.509-based claim signature, the authentication of issuers is no longer auditable - i.e. it is no longer possible for verifiers and auditors to re-validate the claim signature and issuer authentication performed by a TS at registration, which massively increases the trust in the TS (which may now try to register forged claims with plausible deniability - by claiming the TS lost the issuer's certificate used at registration even if none existed). Part of the issue is that claims use x5t instead of x5c. This means there is no mechanism for auditors to obtain the certificate chain used to sign a claim from the TS at registration. Even if x5c was used instead of x5t, only the leaf certificate is required to appear in x5c. Reconstructing the full issuer certificate chain requires at least the TS configuration to link to the configured root CAs used by the TS. Since roots and intermediate certificates expire (or can be updated, as is often the case with PKIX root programs from Mozilla, Google and Microsoft), it is not possible to assume that verifiers can just store the root configuration with the TS's certificate. There are further issues with issuer authentication: >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. This is not well-specified without a reference to such a regular expression. Is this supposed to mean RFC4514 string representation of a distinguished name? The language of RFC4514 doesn't appear to be regular (it is context free), so this must be clarified. There is also no requirement for the issuer's serialized distinguished name to be produced from the claim's X.509 leaf subject. A malicious issuer can put a different issuer's serialized distinguished name in the iss field and is likely to confuse a verifier who cannot detect the mismatch since issuer authentication is not auditable. This makes iss essentially useless for verifiers, and it may be preferable to set iss to nil if x5t/x5c is used.
I propose we require in the architecture that the full certificate chain used to identify the issuer and verify its signature at the time of registration be authenticated by the TS via the resulting receipt. Given a transparent statement (and possibly auxiliary transparent statement from the TS log recording root and intermediate certificates) verifiers must be able to retrieve and review the full certificate chain. This clearly separates PKI issues (delegated to certificate issuance) and the evidence required to keep them transparent and auditable. The text included a a way to implement this requirement based on transparent configuration statements, which I found useful but may be too detailed/prescriptive for the architecture.
I don't think its in the spirit of COSE to include the full cert chain in a protected header. A thumbprint to a certificate that is in a chain is more concise.
This issue will be closed if no PR is raised by Friday.
Closed with
These changes seem appropriateI suggested a couple of improvements, but overall I support this PR. LGTM

Revised text:
sense for their operational use cases. At least one identifier for an identity document MUST be included in  <ins> the protected header of the COSE envelope, as one of "x5t", "x5chain" or "kid". </ins> Support for "x5t" is mandatory to implement.  <ins> Support for "kid" and "x5chain" is optional. </ins>  <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.  <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.