jiebi/CodeConvo huggingface dataset:
Code change:
We are inconsistent with our use of "registered" and "recorded" when referring to the addition of signed statements to the append-only log. I recommend using the term "registered" consistently to refer to this act. This implies that some "process" was applied before registration can occur on the append-only log.
Doing a quick search it seems easy and good to make this change, except one place that looks a bit janky. The current document (draft-08 as released) includes a line: It doesn't quite sound technically right to simply replace the word here because the VDS doesn't register things: there are other bits of the higher level TS involved there. Would it satisfy you in this case to change to: I don't want to mess too much with meaningful text changes and it would be a shame to hold up this issue for one detail. And I think this is strictly better because it also suggests that the VDS doesn't record (or validate, or witness, or any other word we might have come up with) Signed Statements that haven't been registered.
No objections here Jon. Thanks for resolving this issue so quickly. Please close this issue after applying appropriate changes.
URL
Closing as resolved by
LGTM

Related discussion:
text: Implementations of Transparency Services may protect their Append- only Log using a combination of trusted hardware, replication and consensus protocols, and cryptographic evidence.  A Receipt is an <del> offline, universally-verifiable proof that an entry is recorded in </del> <ins> offline, universally-verifiable proof that an entry is registered in </ins> the Append-only Log.  Requesting a receipt can result in the production of a new receipt for the same signed statement.  A Receipt's verification key, signing algorithm, validity period,
Code change:
We are inconsistent with our use of "registered" and "recorded" when referring to the addition of signed statements to the append-only log. I recommend using the term "registered" consistently to refer to this act. This implies that some "process" was applied before registration can occur on the append-only log.
Doing a quick search it seems easy and good to make this change, except one place that looks a bit janky. The current document (draft-08 as released) includes a line: It doesn't quite sound technically right to simply replace the word here because the VDS doesn't register things: there are other bits of the higher level TS involved there. Would it satisfy you in this case to change to: I don't want to mess too much with meaningful text changes and it would be a shame to hold up this issue for one detail. And I think this is strictly better because it also suggests that the VDS doesn't record (or validate, or witness, or any other word we might have come up with) Signed Statements that haven't been registered.
No objections here Jon. Thanks for resolving this issue so quickly. Please close this issue after applying appropriate changes.
URL
Closing as resolved by
LGTM

Related discussion:
text: 4.1. Transparency Services MUST feature an Append-only Log.  The Append- <del> only Log is the verifiable data structure that records Signed Statements and supports the production of Receipts. </del> <ins> only Log is the verifiable data structure that records registered Signed Statements and supports the production of Receipts. </ins> All Transparency Services MUST expose APIs for the Registration of Signed Statements and issuance of Receipts.
Code change:
We are inconsistent with our use of "registered" and "recorded" when referring to the addition of signed statements to the append-only log. I recommend using the term "registered" consistently to refer to this act. This implies that some "process" was applied before registration can occur on the append-only log.
Doing a quick search it seems easy and good to make this change, except one place that looks a bit janky. The current document (draft-08 as released) includes a line: It doesn't quite sound technically right to simply replace the word here because the VDS doesn't register things: there are other bits of the higher level TS involved there. Would it satisfy you in this case to change to: I don't want to mess too much with meaningful text changes and it would be a shame to hold up this issue for one detail. And I think this is strictly better because it also suggests that the VDS doesn't record (or validate, or witness, or any other word we might have come up with) Signed Statements that haven't been registered.
No objections here Jon. Thanks for resolving this issue so quickly. Please close this issue after applying appropriate changes.
URL
Closing as resolved by
LGTM

Related discussion:
text: in Receipt. The last two steps may be shared between a batch of Signed Statements <del> recorded in the Append-only Log. </del> <ins> registered in the Append-only Log. </ins> A Transparency Service MUST ensure that a Signed Statement is registered before releasing its Receipt.
Code change:
We are inconsistent with our use of "registered" and "recorded" when referring to the addition of signed statements to the append-only log. I recommend using the term "registered" consistently to refer to this act. This implies that some "process" was applied before registration can occur on the append-only log.
Doing a quick search it seems easy and good to make this change, except one place that looks a bit janky. The current document (draft-08 as released) includes a line: It doesn't quite sound technically right to simply replace the word here because the VDS doesn't register things: there are other bits of the higher level TS involved there. Would it satisfy you in this case to change to: I don't want to mess too much with meaningful text changes and it would be a shame to hold up this issue for one detail. And I think this is strictly better because it also suggests that the VDS doesn't record (or validate, or witness, or any other word we might have come up with) Signed Statements that haven't been registered.
No objections here Jon. Thanks for resolving this issue so quickly. Please close this issue after applying appropriate changes.
URL
Closing as resolved by
LGTM

Related discussion:
text: If a Transparency Service is honest, then a Transparent Statement including a correct Receipt ensures that the associated Signed <del> Statement passed its Registration Policy and was recorded </del> <ins> Statement passed its Registration Policy and was registered </ins> appropriately. Conversely, a corrupt Transparency Service may:
Code change:
Remove ambiguous details reported in (.
x5t value MAY be included in the unprotected header in support of certain supply chain scenarios.
LGTMLGTM

Related discussion:
text: header of the COSE_Sign1 Envelope, to one of the root certificates most recently registered as a trust anchor of the Transparency Service.  An "x5chain" with a leaf certificate that corresponds to <del> the "x5t" value MAY be included in the unprotected header in support of certain supply chain scenarios. </del> <ins> the "x5t" value MAY be included in the unprotected header. </ins> The Transparency Service MUST apply the Registration Policy that was most recently added to the Append-only Log at the time of
Code change:
Address feedback from Hannes in .
Registry, RFC9162_SHA256 is value 1, which supports -1 (inclusion proofs) and -2 (consistency proofs). I believe this registry is defined in another document. The sentence needs to be changed to make the meaning clear.
Breaks circular relationship until one is completed.LGTM

Related discussion:
text: statement-edn.  The Receipt contains inclusion proofs for verifiable data structures.  The unprotected header contains verifiable data structure proofs.  See the protected header for details regarding the <del> specific verifiable data structure used.  Referencing the COSE Verifiable Data Structure Registry, RFC9162_SHA256 is value "1", which supports "-1" (inclusion proofs) and "-2" (consistency proofs). </del> <ins> specific verifiable data structure used.  Per the COSE Verifiable Data Structure Registry documented in I-D.draft-ietf-cose-merkle- tree-proofs, the COSE key type RFC9162_SHA256 is value "1".  Labels identify inclusion proofs ("-1") and consistency proofs ("-2"). </ins> fig-receipt-protected-header-edn illustrates the decoded protected header of the Transparent Statement in fig-transparent-statement-edn.
Code change:
Editors call notes: Moving above the diagram is good clarity Changing from defining the roles to the overall diagram caused some confusion. If the PR can maintain the roles, and add diagram clarity, that would be preferred.
Figure 1 needs to be explained and referenced in the text. The arrows in the figure need to be explained The figure shows two different boxes and the semantic needs to be explained
LGTM

Related discussion:
text: COSE Signed Merkle Tree Proof document I-D.draft-ietf-cose-merkle- tree-proofs. <del> This section describes at a high level, the three main roles and associated processes in SCITT: </del> <ins> fig-concept-relationship illustrates entities and processes that comprise a Transparency Service independent of any one use case. </ins> <del> Issuers and Signed Statements </del> <ins> This section describes the three main roles and associated processes in SCITT: </ins> <del> Transparency Service and the registration process </del> <ins> Issuers that use their credentials to create Signed Statements about Artifacts </ins> <del> Relying Parties of the Transparent Statements and the Receipt validation process </del> <ins> Transparency Services that evaluate Signed Statements against Registration Policies, producing Receipts upon successful Registration.  The returned Receipt may be combined with the Signed Statement to create a Transparent Statement. Relying Parties that: collect Receipts of Signed Statements for subsequent registration of Transparent Statements; retrieve Transparent Statements for analysis of Statements about Artifacts themselves (e.g. verification); or replay all the Transparent Statements to check for the consistency of the Transparency Service's Append-only Log (e.g. auditing) </ins> The subsequent sections describe the main concepts, namely Transparency Service, Signed Statements, Registration, and
Code change:
I would argue that in CT Auditors are checking more than Signed Certificate Timestamps
NAME there is a lot of detail there and I am not sure how far you/others want to go, but I decided to keep it simple and I propose adding slightly more detail in URL I am sure you and others will let me know if that is too little (I doubt/hope it is not too much.)
NAME thanks for the issue. Did you have an intent for what to scope? Reading the , it implies a unique focus on x.509, rather than x.509 is one example of identity types that are supported. Considering CT in terms of SCITT: I'd suggest we limit the focus on x.509, and focus on the generalization that an issuer signs the protected header, which includes producing a timestamped signed statement and a timestamped receipt.
LGTM

Related discussion:
text: CT logs produce Signed Certificate Timestamps (Transparent Statements) <del> Signed Certificate Timestamps are checked by Relying Parties </del> <ins> Signed Certificate Timestamps, Signed Tree Heads, and their respective consistency proofs are checked by Relying Parties </ins> The Append-only Log can be checked by Auditors
Code change:
There is no explanation in draft, GitHub, or mailing lists about resolved key manifest. This change proposes replacement with protected header like other portions of the document.
resolved key manifest) for different Artifacts, or sign all Signed Statements under the same key. What does "resolved key manifest" mean?
LGTM

Related discussion:
text: Statement pertains to.  (See Subject under terminology Terminology.) Issuers MAY use different signing keys (identified by "kid" in the <del> resolved key manifest) for different Artifacts, or sign all Signed </del> <ins> protected header) for different Artifacts, or sign all Signed </ins> Statements under the same key. An Issuer can make multiple Statements about the same Artifact.  For
Code change:
These proposed changes, if accepted,
potentially be discovered out of band and Registration Policies are not assured on the presence of these optional fields. I do not understand what you want to say with the second part of the sentence. Even the first part of the sentence do not convey any real meaning.
LGTM of URL

Related discussion:
text: (see RFC8610) for of the protected header and unprotected header of Signed Statements and Receipts. <del> Everything that is optional in the following CDDL definition can potentially be discovered out of band and Registration Policies are not assured on the presence of these optional fields.  A Registration Policy that requires an optional field to be present MUST reject any Signed Statements or Receipts that are invalid according to the Registration Policy. </del> <ins> This definition specifies the minimal mandatory labels. Implementation-specific Registration Policies may define additional mandatory labels.  A Transparency Service implementation MUST reject registering Signed Statements that do not meet their current Registration Policy requirements.  Each implementation SHOULD provide details for their registration policies through documentation or discovery APIs. </ins> fig-signed-statement-edn illustrates an instance of a Signed Statement in Extended Diagnostic Notation (EDN), with a payload that
Code change:
Editors note: updated with a link to the referenced text: I don't understand the SHOULD. You have to be in possession of trust anchors to verify a digital signature. It is not an optional feature.
It would seem this is correct contingent on your interpretation of , particularly points 2 and 3, so good point.
It's not the use of the anchor in verifying that is optional. It is the use of issuer verification as a gate to registration that is the problem. For ts implementations that naturaly have RBAC at the edge, the "spam" problem is not really a problem. Statements about statements seem to me to be a better way to deal with use cases where strong issuer verification is necessary. Registration time checks can only ever be "point in time"
My read of the Issue and the current state of the document is: This section is under , which implies the MUST refers to enabling the registration process. Currently, a registration can not be completed unless the issuer is verified, which can't occur without trust anchors. The SHOULD refers to verifiers which are not part of the Registration Policy. I think their inclusion in this section is confusing. See for a proposal.

Related discussion:
text: Statement is accepted to be registered to the Append-only Log. Transparency Services MUST maintain Registration Policies. <del> Transparency Services MUST also maintain a list of trust anchors, which SHOULD be used by Relying Parties to authenticate Issuers, and which MAY be included in a Registration Policy statement.  For </del> <ins> Transparency Services MUST maintain a list of trust anchors (see definition of trust anchor in RFC4949).  Transparency Services MUST authenticate signed statements as part of a Registration Policy.  For </ins> instance, a trust anchor could be an X.509 root certificate, a pointer to an OpenID Connect identity provider, or any other COSE- compatible trust anchor.
Code change:
Note: This PR assumes is merged, and may need to be updated to fit within the context of 's final text.
Figure 1 needs to be explained and referenced in the text. The arrows in the figure need to be explained The figure shows two different boxes and the semantic needs to be explained

Related discussion:
text: COSE Signed Merkle Tree Proof document I-D.draft-ietf-cose-merkle- tree-proofs. <del> This section describes at a high level, the three main roles and associated processes in SCITT: </del> <ins> fig-concept-relationship illustrates the three main roles and associated processes that comprise a Transparency Service, independent of any one use case. </ins> <del> Issuers and Signed Statements </del> <ins> Issuers that use their credentials to create Signed Statements about Artifacts.  Issuer Credentials are also used to verify the Signed Statements within the Transparency Service registration process, and Transparent Statements. </ins> <del> Transparency Service and the registration process </del> <ins> Transparency Services that evaluate Signed Statements against Registration Policies, using credentials to sign Receipts upon successful Registration. </ins> <del> Relying Parties of the Transparent Statements and the Receipt validation process </del> <ins> Relying Parties that: collect Receipts, combining them with the Signed Statements to create a Transparent Statement; retrieve Transparent Statements for analysis of Statements about Artifacts; uses credentials to authenticate the Signed Statement and the Receipts of the Transparent Statement (e.g. verification); replay segments of Transparent Statements checking for the consistency of the Transparency Service's Append-only Log (e.g. auditing) In addition, fig-concept-relationship illustrates multiple Transparency Services and multiple Receipts as a single Signed Statement MAY be registered with one or more Transparency Service. Each Transparency Service produces a Receipt, which may be aggregated in a single Transparent Statement, demonstrating the Signed Statement was registered by multiple Transparency Services. The arrows indicate the flow of information. </ins> The subsequent sections describe the main concepts, namely Transparency Service, Signed Statements, Registration, and
Code change:
Closes URL
external attacks and internal misbehavior by some or all of the operators of the Transparency Service. What does the term "each of these functions" refer to?
LGTM to Danny

Related discussion:
text: use is unavoidable, keys MUST NOT sign any other message that may be verified as an Envelope as part of a Signed Statement. <del> Each of these functions MUST be carefully protected against both external attacks and internal misbehavior by some or all of the operators of the Transparency Service. </del> For instance, the code for the Registration Policy evaluation and endorsement may be protected by running in a Trusted Execution Environment (TEE).
Code change:
by allowing the use of a single, protected header parameter instead of a protected and unprotected pair, for reasons described in the issue. This allows implementations to avoid the risk highlighted at the end of , at the expense of a slightly larger protected header. This is not a purely theoretical concern, the most widely used signing service inside Microsoft has implemented this choice, and the separate from Microsoft has too.
The current text mandates the presence of in the protected header when using x509: URL, and allows an unprotected x5chain: URL I propose that the specification allows in the protected header, ideally as a substitute for , but in addition otherwise. The motivation for this change is to add a degree of integrity protection over , and blame for malicious payload otherwise. The current set up does not authenticate or integrity protect the contents of x5chain, only the leaf, which opens up some opportunities for attacks targeting x509 parsers. I can see why this minimal binding can be desirable in some cases (caching large cert chains), but servers that wish to be stricter to reduce their attack surface should be able to.
Thanks for the fix. Seems quite valuable to the overall operation! LGTM!LGTM thanks. For completeness of the record, I was previously against mandatory x5chain and mandatory deep, possibly online checks of the links in the chain. This PR looks eminently sensible for people who want to rely on x5chainDiscussion at the editors meeting to approve. LGTM

Related discussion:
text: by the Transparency Service MUST be checked. In essence, when using X.509 Signed Statements, the Transparency <del> Service MUST build and validate a complete certificate chain from the Issuer's certificate identified by "x5t" located in the protected header of the COSE_Sign1 Envelope, to one of the root certificates most recently registered as a trust anchor of the Transparency Service.  An "x5chain" with a leaf certificate that corresponds to the "x5t" value MAY be included in the unprotected header. </del> <ins> Service MUST build and validate a complete certification path from an Issuer's certificate to one of the root certificates most recently registered as a trust anchor by the Transparency Service. The protected header of the COSE_Sign1 Envelope MUST include either the Issuer's certificate as "x5t" or the chain including the Issuer's certificate as "x5chain".  If "x5t" is included in the protected header, an "x5chain" with a leaf certificate corresponding to the "x5t" value MAY be included in the unprotected header. </ins> The Transparency Service MUST apply the Registration Policy that was most recently added to the Append-only Log at the time of
Code change:
This editorial change attempts to per feedback from NAME
The three steps from Section 4.3 on Registration are essentially the same. To verify the signature you have to retrieve the issuer credentials and you have to do item 4. Issuer Verification: The Transparency Service MUST syntactically validate the Issuer's identity Claims, which may be different than the Client identity. 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. 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.
LGTM for reduction and lack of duplicity

Related discussion:
text: <del> The Transparency Service MUST perform signature verification, as defined in RFC9052, and MAY perform additional checks as part of its Registration Policy. 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. The Transparency Service MUST check that the Signed Statement includes the required protected headers.  The Transparency Service MAY validate the Signed Statement payload in order to enforce domain specific registration policies that apply to specific content types. </del> <ins> The Transparency Service MUST perform signature verification per RFC9052 and MUST verify the signature of the Signed Statement with the signature algorithm and verification key of the Issuer per RFC9360.  The Transparency Service MUST also check the Signed Statement includes the required protected headers.  The Transparency Service MAY validate the Signed Statement payload in order to enforce domain specific registration policies that apply to specific content types. </ins>
Code change:
This is a long sentence, maybe break it up into multiple 80 character lines? A policy could be 'unrecognized', 'unparsable', or 'not implemented'. Does 'unknown' imply all of these? Originally posted by NAME in URL

Related discussion:
text: contents of the Registry at the time of registration, and must then yield the same result. <del> The ordering of entries, their cryptographic contents, and the </del> <ins> the ordering of entries, their cryptographic contents, and the </ins> Registry governance may be non-deterministic, but they must be verifiable. <del> A Transparency Services SHOULD store evidence about the resolution </del> <ins> a Transparency Services SHOULD store evidence about the resolution </ins> of distributed identifiers into manifests. <del> A Transparency Service MAY additionally support verifiability of </del> <ins> a Transparency Service MAY additionally support verifiability of </ins> client authentication and access control. 5.2.3.4.