jiebi/CodeConvo huggingface dataset:
4.3. <del> The client (which is not necessarily the Issuer) that registers a Signed Statement and receives a Receipt can produce a Transparent Statement by adding the Receipt to the Unprotected Header of the Signed Statement. </del> <ins> Client applications MAY register Signed Statements on behalf of one or more Issuers.  Client applications MAY request Receipts regardless of the identity of the Issuer of the associated Signed Statement. </ins> When a Signed Statement is registered by a Transparency Service a Receipt becomes available.  When a Receipt is included in a Signed
The Transparency Service is trusted with the confidentiality of the Signed Statements presented for Registration.  Some Transparency Services may publish every Signed Statement in their logs, to <del> facilitate their dissemination and auditing.  Others may just return Receipts to clients that present Signed Statements for Registration, and disclose the Append-only Log only to Auditors trusted with the confidentiality of its contents. </del> <ins> facilitate their dissemination and auditing.  Transparency Services MAY return Receipts to client applications synchronously or asynchronously. </ins> A collection of Signed Statements must not leak information about the contents of other Signed Statements registered on the Transparency
6.2.5. <del> Trust in clients that submit Signed Statements for Registration is implementation-specific.  An attacker may attempt to register any Signed Statement it has obtained, at any Transparency Service that accepts them, possibly multiple times and out of order.  This may be mitigated by a Transparency Service that enforces restrictive access control and Registration Policies. </del> <ins> Authentication of client applications is out of scope for this document.  Transparency Services MUST authenticate both client applications and the Issuer of signed statements in order to ensure that implementation specific authentication and authorization policies are enforced.  The specification of authentication and authorization policies is out of scope for this document. </ins> 6.2.6.
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.
to allow implementations to make the restrictions that make the most sense for their operational use cases. <del> At least one identifier for an identity document MUST be included in the protected header of the COSE envelope, as one of "x5t", "x5chain" or "kid". Support for "x5t" is mandatory to implement. Support for "kid" and "x5chain" is optional. 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. The mechanisms for how Transparency Services obtain identity documents is out-of-scope of this document. The "kid" header parameter MUST be present when neither "x5t" nor "x5chain" are present.  Key discovery protocols are out-of-scope of this document. The protected header of a Signed Statement and a Receipt MUST include the "CWT Claims" header parameter as specified in CWT_CLAIMS_COSE. The "CWT Claims" value MUST include the "Issuer Claim" (Claim label 1) and the "Subject Claim" (Claim label 2) IANA.cwt. A Receipt is a Signed Statement, (cose-sign1), with addition claims in its protected header related to verifying the inclusion proof in its unprotected header.  See I-D.draft-ietf-cose-merkle-tree-proofs. fig-signed-statement-cddl illustrates a normative CDDL definition for of the protected header for Signed Statements and Receipts. Everything that is optional in the following CDDL 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 policy. fig-signed-statement-edn illustrates a payload that is detached. This is to support very large supply chain artifacts, and to ensure that Transparent Statements can integrate with existing file systems. </del> There are many types of Statements (such as SBOMs, malware scans, audit reports, policy definitions) that Issuers may want to turn into Signed Statements.  An Issuer must first decide on a suitable format
Once all the Envelope headers are set, an Issuer MUST use a standard COSE implementation to produce an appropriately serialized Signed <del> Statement (the SCITT tag of "COSE_Sign1_Tagged" is outside the scope of COSE, and used to indicate that a signed object is a Signed Statement). </del> <ins> Statement.  The SCITT tag "COSE_Sign1_Tagged" is outside the scope of COSE, and used to indicate that a signed object is a Signed Statement. </ins> Issuers may produce Signed Statements about different Artifacts under the same Identity.  Issuers and Relying Parties must be able to recognize the Artifact to which the statements pertain by looking at the Signed Statement.  The "iss" and "sub" claims, within the CWT_Claims protected header, are used to identify the Artifact the <del> statement pertains to. See Subject under terminology Terminology. </del> <ins> statement pertains to.  (See Subject under terminology Terminology.) </ins> Issuers MAY use different signing keys (identified by "kid" in the resolved key manifest) for different Artifacts, or sign all Signed
Multiple Issuers can make the same Statement about a single Artifact, affirming multiple Issuers agree. <ins> At least one identifier for an identity document MUST be included in the protected header of the COSE envelope, as one of "x5t", "x5chain" or "kid". Support for "x5t" is mandatory to implement. Support for "kid" and "x5chain" is optional. 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. The mechanisms for how Transparency Services obtain identity documents is out-of-scope of this document. The "kid" header parameter MUST be present when neither "x5t" nor "x5chain" are present.  Key discovery protocols are out-of-scope of this document. The protected header of a Signed Statement and a Receipt MUST include the "CWT Claims" header parameter as specified in CWT_CLAIMS_COSE. The "CWT Claims" value MUST include the "Issuer Claim" (Claim label 1) and the "Subject Claim" (Claim label 2) IANA.cwt. A Receipt is a Signed Statement, (cose-sign1), with addition claims in its protected header related to verifying the inclusion proof in its unprotected header.  See I-D.draft-ietf-cose-merkle-tree-proofs. </ins> 4.2.1. <ins> fig-signed-statement-cddl illustrates a normative CDDL definition for of the protected header for Signed Statements and Receipts. Everything that is optional in the following CDDL 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 policy. fig-signed-statement-edn illustrates an instance of a Signed Statement in EDN, with a payload that is detached.  Detached payloads support large artifacts, and ensure Signed Statements can integrate with existing storage systems. fig-signed-statement-protected-header-edn illustrates the decoded protected header of the Signed Statement in fig-signed-statement-edn. It indicates the Signed Statement is securing a JSON content type, and identifying the content with the "sub" claim "vendor.product.example". 4.3. </ins> To register a Signed Statement, the Transparency Service performs the following steps:
fig-transparent-statement-cddl illustrates a normative CDDL definition of Transparent Statements. <del> fig-transparent-statement-edn illustrates a payload that is detached. The unprotected header can contain multiple receipts. </del> <ins> fig-transparent-statement-edn illustrates a Transparent Statement with a detached payload, and two receipts in its unprotected header. The label 394 "receipts" in unprotected header can contain multiple receipts. </ins> <del> Notice the verifiable data structure used is RFC9162_SHA256 in this case.  We know from the COSE Verifiable Data Structure Registry that RFC9162_SHA256 is value 1, and that it supports -1 (inclusion proofs) and -2 (consistency proofs). </del> <ins> fig-receipt-edn one of the decoded Receipt from fig-transparent- 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 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). </ins> <del> Notice the unprotected header contains verifiable data structure proofs, see the protected header for details regarding the specific verifiable data structure used. </del> <ins> fig-receipt-protected-header-edn illustrates the decoded protected header of the Transparent Statement in fig-transparent-statement-edn. The verifiable data structure ("-111") uses "1" from (RFC9162_SHA256). </ins> <del> This is a decoded inclusion proof for RFC9162_SHA256, other verifiable data structures might encode inclusion proofs differently. </del> <ins> fig-receipt-inclusion-proof-edn illustrates the decoded inclusion proof from fig-receipt-edn.  This inclusion proof indicates that the size of the transparency log was "8" at the time the receipt was issued.  The structure of this inclusion proof is specific to the verifiable data structure used (RFC9162_SHA256). </ins> <del> 4.3.1. </del> <ins> 4.4.1. </ins> Relying Parties MUST apply the verification process as described in <del> Section 4.4 of RFC9052. </del> <ins> Section 4.4 of RFC9052, when checking the signature of Signed Statements and Receipts. A Relying Party MUST trust the verification key or certificate and the associated identity of at least one issuer of a Receipt. A Relying Party MAY decide to verify only a single Receipt that is acceptable to them, and not check the signature on the Signed Statement or Receipts which rely on verifiable data structures which they do not understand. </ins> APIs exposing verification logic for Transparent Statements may provide more details than a single boolean result.  For example, an
is valid, if claims related to the validity period are valid, or if the inclusion proof in the Receipt is valid. <del> The algorithm-specific details of checking inclusion proofs are covered in I-D.draft-ietf-cose-merkle-tree-proofs.  The pseudo-code for validation of a transparent statement is as follows: Before checking a Transparent Statement, the Verifier must be configured with one or more identities of trusted Transparency Services. </del> Relying Parties MAY be configured to re-verify the Issuer's Signed <del> Statement locally, but this requires a fresh resolution of the Issuer's verification keys, which MAY fail if the key has been revoked. Some Relying Parties MAY decide to locally re-apply some or all of the Registration Policies, if they have limited trust in the Transparency Services.  In addition, Relying Parties MAY apply arbitrary validation policies after the Transparent Statement has been verified and validated.  Such policies may use as input all information in the Envelope, the Receipt, and the Statement payload, as well as any local state. Relying Parties MAY offer options to store or share the Receipt of the Transparent Statement for auditing the Transparency Services in case a dispute arises. </del> <ins> Statement locally. In addition, Relying Parties MAY apply arbitrary validation policies after the Transparent Statement has been verified and validated. Such policies may use as input all information in the Envelope, the Receipt, and the Statement payload, as well as any local state. </ins> 5.
Transparency Services MUST maintain Registration Policies. <del> Transparency Services MUST also maintain a list of trust anchors used to authenticate Issuers, which MAY be included in a 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. </del> <ins> 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 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. </ins> Registration Policies and trust anchors MUST be made transparent and available to all Relying Parties of the Transparency Service by
4.1.1.1. During registration, a Transparency Service MUST, at a minimum, <del> authenticate the Issuer of the Signed Statement by validating the COSE signature and checking the identity of the issuer against one of its currently configured trust anchors, using the "x5t" (34), "x5chain"(33) or "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. </del> <ins> syntactically check the Issuer of the Signed Statement by cryptographically verifying the COSE signature according to RFC9052. The Issuer identity MUST be bound to the Signed Statement by including an identifier in the protected header. If the protected header includes multiple identifiers, all those that are registered by the Transparency Service MUST be checked. For instance, when using 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. </ins> The Transparency Service MUST apply the Registration Policy that was most recently added to the Append-only Log at the time of
Transparency Services MUST ensure that for any Signed Statement they register, enough information is made available to Auditors (either in the Append-only Log and retrievable through audit APIs, or included <del> in the Receipt) to authenticate and retrieve the Transparent Statements describing the registration policy and trust anchors that apply to this registration. </del> <ins> in the Receipt) to reproduce the Registration checks that were defined by the Registration Policies at the time of Registration. </ins> 4.1.2.
<del> The Transparency Service MUST perform resolution of the Issuer's identity, which may be different than the Client identity.  This step may require that the service retrieves the Issuer ID in real- time, or rely on a cache of recent resolutions.  For auditing, during Registration, the Transparency Service MUST store evidence of the lookup, including if it was resolved from a cache. </del> <ins> The Transparency Service MUST syntactically validate the Issuer's identity claims, which may be different than the Client identity. </ins>
On its own, verifying a Transparent Statement does not guarantee that its Envelope or contents are trustworthy.  Just that they have been signed by the apparent Issuer and counter-signed by the Transparency <del> Service.  If the Verifier trusts the Issuer, it can infer that an Issuer's Signed Statement was issued with this Envelope and contents, which may be interpreted as the Issuer saying the Artifact is fit for its intended purpose.  If the Verifier trusts the Transparency Service, it can independently infer that the Signed Statement passed the Transparency Service Registration Policy and that has been persisted in the Append-only Log.  Unless advertised in the Transparency Service Registration Policy, the Verifier cannot assume that the ordering of Signed Statements in the Append-only Log matches the ordering of their issuance. </del> <ins> Service.  If the Verifier trusts the Issuer, after validation of the Issuer identity, it can infer that an Issuer's Signed Statement was issued with this Envelope and contents, which may be interpreted as the Issuer saying the Artifact is fit for its intended purpose.  If the Verifier trusts the Transparency Service, it can independently infer that the Signed Statement passed the Transparency Service Registration Policy and that has been persisted in the Append-only Log.  Unless advertised in the Transparency Service Registration Policy, the Verifier cannot assume that the ordering of Signed Statements in the Append-only Log matches the ordering of their issuance. </ins> Similarly, the fact that an Issuer can be held accountable for its Transparent Statements does not on its own provide any mitigation or
Transparency Services MUST ensure that for any Signed Statement they register, enough information is made available to Auditors (either in the Append-only Log and retrievable through audit APIs, or included <del> in the Receipt) to authenticate and retrieve the Transparent Statements describing the registration policy and trust anchors that apply to this registration. </del> <ins> in the Receipt) to authenticate and retrieve the Signed Statements describing the registration policy and trust anchors that apply to this registration. </ins> 4.1.2.
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.  Receipts do not have an expiration time, but the corresponding key material could.  Requesting a refreshed receipt can result in the same receipt with a different signature or signature with a different signing algorithm. </ins> Anyone with access to the Transparency Service can independently verify its consistency and review the complete list of Transparent
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
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-
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
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>
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.
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