jiebi/CodeConvo huggingface dataset:
Code change:
To facilitate this forward for submission on Monday, I'm going to merge a few changes for additional discussion/review.
Fair, could you provide a suggested change? [edit] let me elaborate: not making iat mandatory! But about the fact that extension points in Receipts can render them with an expiration date and that only in the architecture's base definition they do not expire.
After reviewing comments and the paragraph this change sits within, the merged suggestions make a minor improvement, and I don't believe rewinds any problems. While we can/should make additional improvements, can we adopt this change? NAME NAME you have blocking requests. If the merged suggestions don't resolve your concerns, can you either make an additional suggestion or comment on why this shouldn't be merged?
NAME here you go: URL
The changes that have been made to the pull request has lost somethings. The logical receipt itself does not expire. The evidence captured in the ledger is more than just the hash of the signed statement as it has to capture the tests done to the signature and the results. That evidence and where it sits in the ledger establishes a time basis for the decision. A new signature on top of that linkage to the evidence in the ledger is being equated as a whole as the receipt. The "thing" signed is the same (location into the ledger) and the only thing that has changed is possibly the identity key material and algorithm. It is this concept of "never" expiring that is important to key.
from :
Tagging NAME
NAME we'll close this in a week and can reconsider with a PR.
Referring to , the latest changes provide the flexibility for Transparency Services to maintain previous receipts and re-issue them or generate new receipts which may not be persisted. As such, I'm approving this PR as incremental progress.

Related discussion:
text: only Log using a combination of trusted hardware, replication and consensus protocols, and cryptographic evidence.  A Receipt is an offline, universally-verifiable proof that an entry is recorded in <del> the Append-only Log.  Receipts do not expire, but it is possible to append new entries (more recent Signed Statements) that subsume older entries (less recent Signed Statements). </del> <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, header parameters or other claims MAY change each time a Receipt is produced. </ins> Anyone with access to the Transparency Service can independently verify its consistency and review the complete list of Transparent
Code change:
Assuming URL is merged, that document will register everything that is needed for SCITT Receipts (a profile of COSE Receipts). There is clean up work to do in the architecture. Remove the editorial notes regarding 394. Review IANA considerations (AFAIK, 394 was never requested for registration in the document, despite the editor notes).
I've merged the PR, but we need to publish a new version to the data tracker. Ideally other authors (of COSE Receipts / COMETRE) will do an editorial pass, and then push a new version to the data tracker.
I'd personally prefer to separate the mediatype exclusion (which I agree with removing) to a different PR, but would approve both anyway. LGTM

Related discussion:
text: are capitalized.  To ensure readability, only a core set of terms is included in this section. <del> : </del> The terms "header", "payload", and "to-be-signed bytes" are defined in RFC9052.
Code change:
Assuming URL is merged, that document will register everything that is needed for SCITT Receipts (a profile of COSE Receipts). There is clean up work to do in the architecture. Remove the editorial notes regarding 394. Review IANA considerations (AFAIK, 394 was never requested for registration in the document, despite the editor notes).
I've merged the PR, but we need to publish a new version to the data tracker. Ideally other authors (of COSE Receipts / COMETRE) will do an editorial pass, and then push a new version to the data tracker.
I'd personally prefer to separate the mediatype exclusion (which I agree with removing) to a different PR, but would approve both anyway. LGTM

Related discussion:
text: Statement a Transparent Statement is produced. Receipts are based on Signed Inclusion Proofs as described in COSE <del> Signed Merkle Tree Proofs (I-D.draft-ietf-cose-merkle-tree-proofs). </del> <ins> Signed Merkle Tree Proofs (I-D.draft-ietf-cose-merkle-tree-proofs) that also provides the COSE header parameter semantics for label 394. </ins> The Registration time is defined as the timestamp at which the Transparency Service has added this Signed Statement to its Append-
Code change:
Assuming URL is merged, that document will register everything that is needed for SCITT Receipts (a profile of COSE Receipts). There is clean up work to do in the architecture. Remove the editorial notes regarding 394. Review IANA considerations (AFAIK, 394 was never requested for registration in the document, despite the editor notes).
I've merged the PR, but we need to publish a new version to the data tracker. Ideally other authors (of COSE Receipts / COMETRE) will do an editorial pass, and then push a new version to the data tracker.
I'd personally prefer to separate the mediatype exclusion (which I agree with removing) to a different PR, but would approve both anyway. LGTM

Related discussion:
text: fig-transparent-statement-edn illustrates a Transparent Statement with a detached payload, and two Receipts in its unprotected header. <del> The label 394 "receipts" in unprotected header can contain multiple Receipts. </del> <ins> The type of label 394 "receipts" in the unprotected header is a CBOR array that can contain one or more Receipts (each entry encoded as a .cbor encoded Receipts). </ins> fig-receipt-edn one of the decoded Receipt from fig-transparent- statement-edn.  The Receipt contains inclusion proofs for verifiable
Code change:
Assuming URL is merged, that document will register everything that is needed for SCITT Receipts (a profile of COSE Receipts). There is clean up work to do in the architecture. Remove the editorial notes regarding 394. Review IANA considerations (AFAIK, 394 was never requested for registration in the document, despite the editor notes).
I've merged the PR, but we need to publish a new version to the data tracker. Ideally other authors (of COSE Receipts / COMETRE) will do an editorial pass, and then push a new version to the data tracker.
I'd personally prefer to separate the mediatype exclusion (which I agree with removing) to a different PR, but would approve both anyway. LGTM

Related discussion:
text: 7. <del> TBD; mybody. </del> 7.1. <del> This section requests registration of the following media types RFC2046 in the "Media Types" registry IANA.media-types in the manner described in RFC6838. To indicate that the content is an scitt configuration represented as JSON: Type name: application Subtype name: scitt-configuration+json Required parameters: n/a Optional parameters: n/a Encoding considerations: binary; application/scitt- configuration+json values are represented as a JSON Object; UTF-8 encoding SHOULD be employed for the JSON object. Security considerations: See the Security Considerations section of TBD. Interoperability considerations: n/a Published specification: TBD Applications that use this media type: TBD Fragment identifier considerations: n/a Additional information: Magic number(s): n/a File extension(s): n/a Macintosh file type code(s): n/a Person & email address to contact for further information: TBD Intended usage: COMMON Restrictions on usage: none Author: TBD Change Controller: IETF Provisional registration?  No </del> <ins> Pending WG discussion. </ins>
Code change:
Reason: Term was used only twice, not defined, and does not seem to play an important role. !
fiddled with a phrasing nit. This approval is not about the diagram picture, but the content of md that substitutes Identity Documents with URL

Related discussion:
text: Multiple Issuers can make the same Statement about a single Artifact, affirming multiple Issuers agree. <del> At least one identifier for an identity document MUST be included in the protected header of the COSE Envelope, as one of "x5t" or "kid". Additionally, "x5chain" that corresponds to either "x5t" or "kid" identifying the leaf certificate in the included certification path MAY be included in the unprotected header of the COSE Envelope. </del> <ins> At least one identifier representing one credential MUST be included in the protected header of the COSE Envelope, as one of "x5t" or "kid".  Additionally, "x5chain" that corresponds to either "x5t" or "kid" identifying the leaf certificate in the included certification path MAY be included in the unprotected header of the COSE Envelope. </ins> When using x509, Support for "x5t" is mandatory to implement.
Code change:
Reason: Term was used only twice, not defined, and does not seem to play an important role. !
fiddled with a phrasing nit. This approval is not about the diagram picture, but the content of md that substitutes Identity Documents with URL

Related discussion:
text: 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 "x5t" is not present. Key discovery protocols are out-of-scope of this document.
Code change:
changes "document" to "Signed Statement" (was a weird nit close to the suggested change)LGTM

Related discussion:
text: proof of Registration by a Transparency Service, in the form of a Receipt that countersigns the Signed Statement and witnesses its inclusion in the Append-only Log of a Transparency Service.  By <del> extension, the document may say an Artifact (a firmware binary) is transparent if it comes with one or more Transparent Statements from its author or owner, though the context should make it clear what type of Signed Statements is expected for a given Artifact. </del> <ins> extension, the Signed Statement may say an Artifact (for example, a firmware binary) is transparent if it comes with one or more Transparent Statements from its author or owner, though the context should make it clear what type of Signed Statements is expected for a given Artifact. </ins> Transparency does not prevent dishonest or compromised Issuers, but it holds them accountable.  Any Artifact that may be verified, is
Code change:
removed "(Artifact)" which seems to have been an artifact....LGTM

Related discussion:
text: Artifacts, from the build and supply of software and IoT devices to advanced manufacturing and food supply. <del> SCITT is a generalization of Certificate Transparency RFC9162, which can be interpreted as a transparency architecture for the supply chain of X.509 certificates.  Considering CT in terms of SCITT: </del> <ins> SCITT is a generalization of Certificate Transparency (CT) RFC9162, which can be interpreted as a transparency architecture for the supply chain of X.509 certificates.  Considering CT in terms of SCITT: </ins> <del> CAs (Issuers) sign X.509 TBSCertificates (Artifacts) to produce X.509 certificates (Signed Statements) </del> <ins> CAs (Issuers) sign the ASN.1 DER encoded tbsCertificate structure to produce an X.509 certificate (Signed Statements) </ins> CAs submit the certificates to one or more CT logs (Transparency Services)
Code change:
I don't understand the motivation behind replacing "any other COSE compatible PKI trust anchor." with "a JSON Web Key Set". Is there an issue with COSE compatible PKI trust anchors that is driving this change?
NAME : What is an example of a "any other COSE compatible PKI trust anchor." besides the JSON Web Key Set?
Good question NAME if JSON Web Key Set is indeed the only possible COSE compatible PKI trust anchor then I see no issues with this change.
I support Steve's suggested change.
I think the point here is to keep it open and not limit to what exists today.
NAME I have not worked on COSE for one minute, but I get the impression that a SCITT Transparency statement could include identities other than X.509, which seems to imply that another form of "trust anchor" is plausible, i.e. a PGP chain of Trust or even a SCITT trusted party - am I mistaken.
These are just examples anyway and as such the list is unbounded. But if you give examples, as you do today, then it better might be good to give examples that are understandable by readers. That is what I have been trying to do. I listed the only COSE example I am aware of.
LGTM to changes

Related discussion:
text: 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> 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. </del> <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. </ins> Registration Policies and trust anchors MUST be made transparent and available to all Relying Parties of the Transparency Service by
Code change:
fiddled with the language that intended to be normative and made it normative languageLGTM

Related discussion:
text: identifying the leaf certificate in the included certification path MAY be included in the unprotected header of the COSE Envelope. <del> When using x509, Support for "x5t" is mandatory to implement. </del> <ins> When using x.509 certificates, support for "x5t" is REQUIRED to implement. </ins> Support for "kid" in the protected header and "x5chain" in the <del> unprotected heaer is optional. </del> <ins> unprotected header is OPTIONAL to implement. </ins> 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
Code change:
This is not correct if we also consider SCRAPI
SCRAPI says Auth is, may or isn’t required on specific endpoints, but doesn’t specify how it’s implemented. Is that inconsistent?
please check my suggested changeLGTMok with changes to 4.3 step 2LGTM

Related discussion:
text: <del> A Client authenticates with the Transparency Service, to Register Signed Statements on behalf of one or more Issuers. Authentication and authorization is implementation-specific, and out of scope of the SCITT Architecture. </del> <ins> A Client authenticates with the Transparency Service before registering Signed Statements on behalf of one or more Issuers. Authentication and authorization are implementation-specific and out of scope of the SCITT architecture. </ins> <del> The Transparency Service MUST syntactically validate the Issuer's identity Claims, which may be different than the Client identity. </del> <ins> The Transparency Service MUST perform signature verification, as defined in RFC9052, and MAY perform additional checks as part of its Registration Policy. </ins>
Code change:
This is not correct if we also consider SCRAPI
SCRAPI says Auth is, may or isn’t required on specific endpoints, but doesn’t specify how it’s implemented. Is that inconsistent?
please check my suggested changeLGTMok with changes to 4.3 step 2LGTM

Related discussion:
text: The Transparency Service MUST check that the Signed Statement <del> includes the required protected headers listed above.  The Transparency Service MAY verify the Statement payload format, content and other optional properties. </del> <ins> 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 not correct if we also consider SCRAPI
SCRAPI says Auth is, may or isn’t required on specific endpoints, but doesn’t specify how it’s implemented. Is that inconsistent?
please check my suggested changeLGTMok with changes to 4.3 step 2LGTM

Related discussion:
text: , which MAY be asynchronous from Registration.  The Transparency Service MUST be able to provide a Receipt for all registered <del> Statements.  A Receipt for a Signed Statement MAY be provided asynchronously.  Details about generating Receipts are described in Receipt. </del> <ins> Signed Statements.  Details about generating Receipts are described in Receipt. </ins> The last two steps may be shared between a batch of Signed Statements recorded in the Append-only Log.
Code change:
Here is the status: I do not believe there is a security problem. Roy says that Antoine thinks there is a problem. Antoine is, however, not at the meeting.
Antoine can object in the next iteration or during WGLC
The replacement loses the security issue and adds a new one. The modification of removing the certificate chain, which will save space in the ledger, opens up a problem of building the chain dynamically may result in the wrong trust anchor.LGTM

Related discussion:
text: Signed Statement can be tampered with by a malicious Transparency Service (e.g., one that does not incorporate remote attestation), which may replace the intermediate certificates and ultimately <del> connect to an unexpected root.  This modification can allow malicious TS to forge Claims that look genuine except for the wrong trust anchor.  Auditors MUST perform certification path validation in accordance with PKIX rules specified in RFC5280.  In particular, Auditors MUST verify that certification paths chain to one or more trust anchors (often represented as root certificates). </del> <ins> connect to an unexpected root.  This modification helps protect against person-in-the-middle attacks, but not denial-of-service. Auditors MUST perform certification path validation in accordance with PKIX rules specified in RFC5280.  In particular, Auditors MUST verify that certification paths chain to one or more trust anchors (often represented as root certificates). </ins> 6.1.
Code change:
I generalized the description. You need to rotate all keys.
I don't have strong opinions about the MUST vs. SHOULD requirement here. The group will have to sort this out
Was wondering whether the cases where keys are never rotated are actually valid. The implication is the following: if an end-entity certificate has an indefinite lifetime then the certificates of the subordinate and CA certificates also need to have an indefinite lifetime. Is this a realistic deployment? If so, can you describe this deployment?
Sitting in the SUITS meeting, the same question of MUST came up. Someone made the comment that the MIST could be required in the doc, but the doesn’t mean a service that doesn’t follow the MIST guidance, can’t physically operate or even interop with other services. It would mean it’s not conformant to informative guidance, and a security review could seem it not as secure. Which might be fine for a locked down, IoT scenario. After the SUITS discussion, I’m fine with a MUST for operational info, that enables a service to function as they deem fit
Keeping with MUST as it doesn't change the compatibility, and a service that doesn't rotate would still be interoperable, and be operationally not compliant.
LGTM!removed the hyphen from cryptoperiodsApproving the MUST text.

Related discussion:
text: be used to protect against malicious or vulnerable replicas. Threshold signatures may be use to protect the service key, etc. <del> Issuers and Transparency Services MUST rotate verification keys for signature checking in well-defined cryptoperiods (see KEY- MANAGEMENT). </del> <ins> Issuers and Transparency Services MUST rotate their keys in well- defined cryptoperiods, see KEY-MANAGEMENT. </ins> A Transparency Service MAY provide additional authenticity assurances about its secure implementation and operation, enabling remote
Code change:
NAME NAME PTAL at the latest if they resolve your requested changes.
Suggest we incorporate Option 1 suggestion from Steve!I see this change as constructive, I asked Steve for clarification on his comments too.Changes as of URL improve the previous text. LGTM

Related discussion:
text: 5. <del> Transparency Services are often publicly accessible.  Issuers should treat Signed Statements (rendering them as Transparent Statements) as publicly accessible.  In particular, a Signed Statement Envelope and Statement payload should not carry any private information in plaintext. Transparency Services can have an authorization policy controlling who can access the Append-only Log.  While this can be used to limit who can read the Log, it may also limit the usefulness of the system. Some jurisdictions have a Right to be Forgotten.  However, once a Signed Statement is inserted into the Append-only Log maintained by a Transparency Service, it cannot be removed from the Log. </del> <ins> Transparency Services MAY support anonymous access, Issuers MUST ensure Signed Statements submitted to public access services are acceptable for public disclosure.  In this case, Signed Statements MUST NOT carry confidential information.  Once a Signed Statement is inserted into the Append-only Log maintained by a Transparency Service, it cannot be removed from the Log.  In some deployments, a Relaying Party, such as an Auditor, might require access to Signed Statements and Statements, which can be made available through adjacent services. Transparency Services MUST enforce access control to the Append-only Log. </ins> 6.
Code change:
You have to explain what this means and include reference. Since you are likely not going to do this, I suggest to delete this sentence.
I think we should take NAME 's change, and that the current text is problematic.
LGTM

Related discussion:
text: who can access the Append-only Log.  While this can be used to limit who can read the Log, it may also limit the usefulness of the system. <del> Some jurisdictions have a Right to be Forgotten.  However, once a Signed Statement is inserted into the Append-only Log maintained by a Transparency Service, it cannot be removed from the Log. </del> <ins> Once a cryptographic digest of the Signed Statement is registered on the Append-only Log, the registration cannot be removed from the Append-only Log. </ins> 6.
Code change:
I would not assume certain deployment situations. It is likely that there are many Transparency Services that are not necessarily publically accessible to everyone and the entire architecture would still be totally valid
I agree NAME I know of at least one registry (Transparency Service) that will not be publicly accessible.
NAME always public or not, should we not consider that as material for privacy considerations that follow the line your recommended deletion?Thanks for the updates LGTM

Related discussion:
text: 5. <del> Transparency Services are often publicly accessible.  Issuers should treat Signed Statements (rendering them as Transparent Statements) as publicly accessible.  In particular, a Signed Statement Envelope and Statement payload should not carry any private information in plaintext. </del> <ins> Issuers should treat Signed Statements (rendering them as Transparent Statements) as publicly accessible.  In particular, a Signed Statement Envelope and Statement payload should not carry any private information in plaintext. </ins> Transparency Services can have an authorization policy controlling who can access the Append-only Log.  While this can be used to limit