jiebi/CodeConvo huggingface dataset:
Code change:
Given that all tree algorithms must include a protected header of the countersigner, it makes sense to move that to the top as a common structure. This serves two purposes: inspecting the protected header without verifying the receipt (useful if verification happened elsewhere and a tree-algorithm-agnostic service wants to index general information about the receipt), and allowing for more flexible key discovery schemes in the future that would rely on information in the protected header. Note that this change is independent of the discussions in the mailing list around COSE countersignatures.

Related discussion:
text: Verify the certificate chain established by the node certificate embedded in the receipt and the fixed service certificate in the <del> TS parameters (see parameters) using the Issued At time from "sign_protected" to verify the validity periods of the certificates.  The chain MUST enable the use of the public key in the receipt certificate for signature verification with the </del> <ins> TS parameters (see parameters) using the Issued At time from the protected header of the Receipt to verify the validity periods of the certificates.  The chain MUST enable the use of the public key in the receipt certificate for signature verification with the </ins> Signature Algorithm of the TS parameters. Verify that "signature" is a valid signature value of the root
Code change:
Given that all tree algorithms must include a protected header of the countersigner, it makes sense to move that to the top as a common structure. This serves two purposes: inspecting the protected header without verifying the receipt (useful if verification happened elsewhere and a tree-algorithm-agnostic service wants to index general information about the receipt), and allowing for more flexible key discovery schemes in the future that would rely on information in the protected header. Note that this change is independent of the discussions in the mailing list around COSE countersignatures.

Related discussion:
text: item reflects that a CCF ledger records both signed envelopes and auxiliary entries.) <del> For each signed envelope, compute the "Countersign_structure" as described in cose_sign1_countersign. </del> <ins> For each signed envelope, create the countersigner protected header and compute the "Countersign_structure" as described in cose_sign1_countersign. </ins> For each item in the list, compute "LeafBytes" as the bytestring concatenation of the internal hash, the hash of internal data and,
Code change:
Given that all tree algorithms must include a protected header of the countersigner, it makes sense to move that to the top as a common structure. This serves two purposes: inspecting the protected header without verifying the receipt (useful if verification happened elsewhere and a tree-algorithm-agnostic service wants to index general information about the receipt), and allowing for more flexible key discovery schemes in the future that would rely on information in the protected header. Note that this change is independent of the discussions in the mailing list around COSE countersignatures.

Related discussion:
text: fixed "node_certificate" and "signature", and the bytestrings "internal_hash" and "internal_data" provided with the envelope. <del> Produce the receipt using the Service Identifier and this receipt contents. </del> <ins> Produce the receipt using the countersigner protected header and this receipt's contents. </ins> 6.
Code change:
Changes: Remove initial version from CCF tree alg identifier. The idea is to not be linked directly to major CCF software releases but rather version independently here. For now, there is no need to include a version number in the tree alg identifier. Remove CCF hash alg parameter as that is always implied by the signature alg. CCF signs pre-hashed data (the Merkle tree root) and doesn't hash twice.

Related discussion:
text: 6. <del> The CCF 2 tree algorithm specifies an algorithm based on a binary </del> <ins> The CCF tree algorithm specifies an algorithm based on a binary </ins> Merkle tree over the sequence of all ledger entries, as implemented <del> in the CCF version 2 framework (see CCF_Merkle_Tree). </del> <ins> in the CCF framework (see CCF_Merkle_Tree). </ins> 6.1. The algorithm requires that the TS define additional parameters: <del> Hash Algorithm: The hash algorithm used in its Merkle Tree (see hash-alg-registry). Signature Algorithm: The signature algorithm used (see sig-alg- registry). </del> <ins> Signature Algorithm: The ECDSA signature algorithm used to sign the Merkle tree root (see sig-alg-registry). </ins> Service Certificate: The self-signed X.509 certificate used as trust anchor to verify signatures generated by the transparency service using the Signature Algorithm. <del> All definitions in this section use the hash algorithm set in the TS parameters (see Section parameters).  We write HASH to refer to this algorithm, and HASH_SIZE for the fixed length of its output in bytes. </del> <ins> All definitions in this section use the hash algorithm required by the signature algorithm set in the TS parameters (see Section parameters).  We write HASH to refer to this algorithm, and HASH_SIZE for the fixed length of its output in bytes. </ins> 6.2.
Code change:
Changes: Remove initial version from CCF tree alg identifier. The idea is to not be linked directly to major CCF software releases but rather version independently here. For now, there is no need to include a version number in the tree alg identifier. Remove CCF hash alg parameter as that is always implied by the signature alg. CCF signs pre-hashed data (the Merkle tree root) and doesn't hash twice.

Related discussion:
text: The Receipt contents structure is a CBOR array.  The items of the array in order are: <del> "signature": the signature over the Merkle tree root as bstr. </del> <ins> "signature": the ECDSA signature over the Merkle tree root as bstr.  Note that the Merkle tree root hash is the prehashed input to ECDSA and is not hashed twice. </ins> "node_certificate": a DER-encoded X.509 certificate for the public key for signature verification.  This certificate MUST be a valid
Code change:
Changes: Remove initial version from CCF tree alg identifier. The idea is to not be linked directly to major CCF software releases but rather version independently here. For now, there is no need to include a version number in the tree alg identifier. Remove CCF hash alg parameter as that is always implied by the signature alg. CCF signs pre-hashed data (the Merkle tree root) and doesn't hash twice.

Related discussion:
text: 10.2.2. <del> IANA is asked to establish a registry of hash algorithm identifiers, named "Hash Algorithms", with the following registration procedures: TBD The "Hash Algorithms" registry initially consists of: The designated expert(s) should ensure that the proposed algorithm has a public specification and is suitable for use as a cryptographic hash algorithm with no known preimage or collision attacks.  These attacks can damage the integrity of the ledger. 10.2.3. </del> IANA is asked to establish a registry of signature algorithm identifiers, named "Signature Algorithms", with the following registration procedures: TBD
Code change:
The first change is to address the fact that the current .md renders correctly as bullet list on Github but not in other contexts such as URL

Related discussion:
text: verifiable cryptographic proof of endorsement of the signed envelope by the countersigner. <del> Compared with countersignatures on single COSE envelopes, - Receipts countersign the envelope in context, providing authentication both of the envelope and of its logical position in the authenticated data structure.  - Receipts are proof of commitment to the whole contents of the data structure, even if the Verifier knows only some of its contents.  - Receipts can be issued in bulk, using a single public- key signature for issuing a large number of Receipts. </del> <ins> Compared with countersignatures on single COSE envelopes, Receipts countersign the envelope in context, providing authentication both of the envelope and of its logical position in the authenticated data structure. Receipts are proof of commitment to the whole contents of the data structure, even if the Verifier knows only some of its contents. Receipts can be issued in bulk, using a single public-key signature for issuing a large number of Receipts. </ins> 1.1.
Code change:
The first change is to address the fact that the current .md renders correctly as bullet list on Github but not in other contexts such as URL

Related discussion:
text: a Service identifier: An opaque identifier (e.g.  UUID) that uniquely identifies the service and can be used to securely <del> retrive all other Serivce parameters. </del> <ins> retrive all other Service parameters. </ins> The Tree algorithm used for issuing receipts, and its additional global parameters, if any.  This document creates a registry (see
Code change:
Allowing both a receipt and an array of receipts as type is ambiguous here since the receipt is an array itself and not wrapped, so distinguishing the two cases wouldn't work. Having a single type also simplifies client code.

Related discussion:
text: Label: TBD <del> Value Type: Receipt / [+ Receipt] </del> <ins> Value Type: [+ Receipt] </ins> <del> Description: A COSE_Sign1 Countersign Receipt to be embedded in the unprotected header of the countersigned COSE_Sign1 message. </del> <ins> Description: One or more COSE_Sign1 Countersign Receipts to be embedded in the unprotected header of the countersigned COSE_Sign1 message. </ins> 9.1.1.2.
Code change:
A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM

Related discussion:
text: 2. <ins> The SCITT REST API is designed to support identifier systems that are currently relevant to supply chains, including DID, x509 and PGP. In order to support these systems, the API must be aware of specific header parameters, in particular, "kid", "x5u" and "x5c". The API enables implementers to deploy interoperable URIs for disclosing information feeds related to supply chain actors, and artifacts accessible via transparency services. </ins> 2.1. <ins> TBD (comments on OAuth / Client Attestation). 2.2. TBD (comments on GAIN / OIDC). 2.3. TBD (comments on URLs / QR Codes). 3. 3.1. </ins> All messages are sent as HTTP GET or POST requests. If the Transparency Service cannot process a client's request, it
Code change:
A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM

Related discussion:
text: to wait before retrying the request.  In the absence of this header field, this document does not specify a minimum. <del> 2.1.1. </del> <ins> 3.1.1. </ins> <del> 2.1.1.1. </del> <ins> 3.1.1.1. </ins> Headers:
Code change:
A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM

Related discussion:
text: Body: SCITT COSE_Sign1 message <del> 2.1.1.2. </del> <ins> 3.1.1.2. </ins> One of the following:
Code change:
A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM

Related discussion:
text: Operation ID returned in the response.  Clients should always obtain a Receipt as a proof that Registration has succeeded. <del> 2.1.2. </del> <ins> 3.1.2. </ins> <del> 2.1.2.1. </del> <ins> 3.1.2.1. </ins> <del> 2.1.2.2. </del> <ins> 3.1.2.2. </ins> One of the following:
Code change:
A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM

Related discussion:
text: status.  This is because differentiating between the two may not be possible in an eventually consistent system. <del> 2.1.3. </del> <ins> 3.1.3. </ins> <del> 2.1.3.1. </del> <ins> 3.1.3.1. </ins> Query parameters:
Code change:
A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM

Related discussion:
text: Signed Statement is returned with the corresponding Registration Receipt embedded in the COSE unprotected header. <del> 2.1.3.2. </del> <ins> 3.1.3.2. </ins> One of the following:
Code change:
A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM

Related discussion:
text: Error code: "entryNotFound" <del> 2.1.4. </del> <ins> 3.1.4. </ins> <del> 2.1.4.1. </del> <ins> 3.1.4.1. </ins> <del> 2.1.4.2. </del> <ins> 3.1.4.2. </ins> One of the following:
Code change:
A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM

Related discussion:
text: The retrieved Receipt may be embedded in the corresponding COSE_Sign1 document in the unprotected header. <del> 3. </del> <ins> 4. </ins> Privacy Considerations <del> 4. </del> <ins> 5. </ins> Security Considerations <del> 5. </del> <ins> 6. </ins> Maybe <ins> 6.1. This section requests registration of the "application/receipt+cose" media type RFC2046 in the "Media Types" registry in the manner described in RFC6838. TODO: Consider negotiation for receipt as "JSON" or "YAML".  TODO: Consider impact of media type on "Data URIs" and QR Codes. To indicate that the content is a SCITT Receipt: Type name: application Subtype name: receipt+cose Required parameters: n/a Optional parameters: n/a Encoding considerations: TODO Security considerations: TODO Interoperability considerations: n/a Published specification: this specification 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: TODO Intended usage: COMMON Restrictions on usage: none Author: TODO Change Controller: IESG Provisional registration?  No </ins>
Code change:
Introduction: Removed excess carriage returns Problem Statement: Added new text (threats + artifacts) and illustration (threats)
Please add "and is still valid" - see new proposed langauge enable the consumer to verify that software originated from a 'duly authorized signing party' on behalf of the Supplier, and is still valid
+1 to this change
Closing as been addressed now!
I have no concerns with the revised language for 3.1. One minor nit on 3.2 to be consistent with the use case title REPLACE: A consumer of released software component wants: WITH A consumer of released software product wants:
LGTM
This issue has been resolved in the above PR.
LGTM!

Related discussion:
text: supply chain attacks across the entire software lifecycle while prioritizing data privacy. <del> Insert more detail on the development and deployment flows, threat landscape, and notional artifacts that allow security/compliance risk assessment. </del> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Code change:
Introduction: Removed excess carriage returns Problem Statement: Added new text (threats + artifacts) and illustration (threats)
Please add "and is still valid" - see new proposed langauge enable the consumer to verify that software originated from a 'duly authorized signing party' on behalf of the Supplier, and is still valid
+1 to this change
Closing as been addressed now!
I have no concerns with the revised language for 3.1. One minor nit on 3.2 to be consistent with the use case title REPLACE: A consumer of released software component wants: WITH A consumer of released software product wants:
LGTM
This issue has been resolved in the above PR.
LGTM!

Related discussion:
text: 2. <del> As illustrated in livecycle-threats, a supply chain attack may </del> <ins> Supply chain security is paramount to protecting critical infrastructure, aerospace, and defense and avoiding impacts on security, the economy, public health, and safety.  It has historically focused on risk management practices to safeguard logistics, meet compliance regulations, demand forecasts, and optimize inventory.  While these elements are foundational to a healthy supply chain, an integrated cyber security-based perspective of the software supply chains remains broadly undefined.  Recently, the global community has experienced numerous supply chain attacks by cybercriminals targeting weaknesses in software supply chains.  As illustrated in lifecycle-threats, a software supply chain attack may </ins> leverage one or more lifecycle stages and directly or indirectly target the component. <ins> DevSecOps relies on third-party and open-source solutions, expanding supply chain complexity, and reducing the visibility of the lifecycle compliance.  One solution approach is to enhance the auditability and accountability of Digital Supply Chain Artifacts (DSCA) by using an interoperable, scalable, and flexible decentralized architecture with a transparent registry.  The required software artifacts are highly variable based on community policy requirements, and the solution approach should be artifact agnostic to enable adaptation to these broad policies.  Example artifacts may include commit signatures, build environment and parameters, software bill of materials, static and dynamic application security testing results, fuzz testing results, release approvals, deployment records, vulnerability scan results, and patch logs. </ins> 3. TBD
Code change:
Added a placeholder section to aggregate problem statements across use cases. Refine and complete this section as use cases stabilize.
:ship: it

Related discussion:
text: This eventually leads to a loss of reputation and company closure for Vendor OS-X. <ins> 5. Consumers want to understand and verify that an actual trust bond exists between the Supplier of a certain software component package and the Signing Authority of that software component package (4.1.1) Consumers want to obtain statements from producers and third- parties related to the software product in a timely and unambiguous fashion (4.2.1) Consumers want to attribute statements to an authoritative issuer (4.2.2) Consumers want to associate statements with other statements in a meaningful manner (4.2.3) Consumers want to consistently, efficiently, and homogeneously check the authenticity of statements (4.2.4) Consumers want to understand if a particular provider is actually the original provider or a promoter (4.3.1) Consumers want to know if and how the source, or resulting binary, of a promoted software component differs from the original software component (4.3.2) Consumers want to check the provenance and history of a software component's source back to its origin (4.3.3) Consumers want to assess whether to trust a promoter or not (4.3.4) To be continued... </ins>
Code change:
Signed-off-by: Henk Birkholz
Henk, The Distributor isn’t always the signing authority. It’s true in some app stores, but beyond that the model breaks, down. Walmart doesn’t digitally sign software it sells/distributes. 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
Then this is going on the agenda for Monday, too. Thanks Dick
Thanks, Henk. 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 discussion with Henk I believe the use-case here is an app store-like promotion scenario. If that's true, I recommend we refer to this as the relationship between a supplier/producer and the distributor. While signing is a property of the relationship between an app creator and an app store we can increase the clarity of the use-case by describing the roles in the relationship (producer/distributor/consumer). I've made some suggestions on the PR to replace "Signing Authority" with "Distributor".

Related discussion:
text: A certain software component product is created and packaged by a Supplier.  The package by itself does not include a proof of authenticity.  A signing authority is tasked with adding a proof of <del> authenticity.  Trust has to be established from the Supplier towards the Signing Authority - and vice versa.  The mutual trust relationship (trust bond) between Supplier and Signing Authority is </del> <ins> authenticity.  Trustworthiness has to be established from the Supplier towards the Distributor - and vice versa.  The mutual trustworthiness relationship between Supplier and Distributor is </ins> established per each individual software component package. A consumer of a released software wants: <del> to understand and verify that an actual trust bond exists between the Supplier of a certain software component package and the Signing Authority of that software component package. </del> <ins> to understand and verify that an actual trustworthiness relationship exists between the Supplier of a certain software component package and the Distributor of that software component package. </ins> There is no standardized way to: <del> enable the consumer to verify that a trust bond for a certain software component package exists and is still valid. </del> <ins> enable the consumer to verify that a trustworthiness relationship for a certain software component package exists and is still valid. </ins> 3.2.