jiebi/CodeConvo huggingface dataset:
serialization), ease of processing and availability of implementations. <del> At a high-level, a claim is a COSE single-signed object (i.e. "COSE_Sign1") that contains the correct set of protected headers. Although issuers and relays may attach unprotected headers to claims, transparency services and verifiers MUST NOT rely on the presence or value of unrpotected headers in claims during registration and validation. </del> <ins> At a high-level that is the context of this architecture, a Claim is a COSE single-signed object (i.e.  "COSE_Sign1") that contains the correct set of protected headers.  Although issuers and relays may attach unprotected headers to claims, transparency services and verifiers MUST NOT rely on the presence or value of additional unprotected headers in claims during registration and validation. </ins> All claims MUST include the following protected headers: <del> algorithm (label: "1"): Asymmetric signature algorithm as integer, for example "-35" for ECDSA with SHA-384, see COSE Algorithms registry [2] </del> <ins> algorithm (label: "1"): Asymmetric signature algorithm used by the claim issuer, as an integer, for example "-35" for ECDSA with SHA- 384, see COSE Algorithms registry [2]; </ins> issuer (label: "TBD", to be registered): DID (Decentralized <del> Identifier, see W3C Candidate Recommendation [3]) of the signer as string, for example "did:web:example.com" </del> <ins> Identifier, see W3C Candidate Recommendation [3]) of the signer, as a string, for example "did:web:example.com"; </ins> <del> feed (label: "TBD"): the issuer's name for the artifact </del> <ins> feed (label: "TBD"): the issuer's name for the artifact, as a string; </ins> <del> payload type (label: "3"): Media type of payload as string, for </del> <ins> payload type (label: "3"): Media type of payload as a string, for </ins> example "application/spdx+json" registration policy info (label: "TBD"): a map of additional <del> attributes to help enforce registration policies </del> <ins> attributes to help enforce registration policies; </ins> DID key selection hint (label: "TBD"): a DID method-specific <del> selector for the signing key </del> <ins> selector for the signing key, as a bytestring. </ins> Additionally, claims MAY carry the following unprotected headers:
6.2. There are many types of statements (such as SBOMs, malware scans, <del> audit reports, policy definitions) that issuers may want to turn into claims.  The issuer must first decide on a suitable format to </del> <ins> audit reports, policy definitions) that Issuers may want to turn into Claims.  The Issuer must first decide on a suitable format to </ins> serialize the statement, such as: - JSON-SPDX - CBOR-SPDX - SWID - CoSWID - CycloneDX - in-toto - SLSA
The same claim may be independently registered in multiple TS.  To register a claim, the service performs the following steps: <del> Client authentication. </del> <ins> Client authentication.  This is implementation-specific, and MAY be unrelated to the issuer identity.  Claims may be registered by a different party than their issuer. </ins> <del> So far, implementation-specific, and unrelated to the issuer identity.  Claims may be registered by a different party than their issuer. Issuer identification.  The service must check that the ledger records a recent DID document for the "issuer" protected header of the envelope.  This MAY require that the service resolve the issuer DID and record the resulting document.  (See issuer identity above.) </del> <ins> Issuer identification.  The TS MUST store evidence of the DID resolution for the "issuer" protected header of the envelope and the resolved key manifest at the time of registration for auditing.  This MAY require that the service resolve the issuer DID and record the resulting document, or rely on a cache of recent resolutions. </ins> Envelope signature verification, as described in COSE signature, using the signature algorithm and verification key of the issuer
6.4. <del> Trusted input for receipt verification: the identity and the public signature-verification key of the transparency service. These may be included in the verifier's trusted configuration, or determined by a trusted policy. Verification steps: Verify receipt (see I-D.birkholz-scitt-receipts). Verify issuer signature. Freshness/revocation? Validate format of the envelope contents. Once verified, the claims together with their authenticated issuer and transparent ledger identities can be used as input to an authorization policy. </del> <ins> This section provides additional implementation considerations, the high-level validation algorithm is described in validation, with the ledger-specific details of checking receipts are covered in I- D.birkholz-scitt-receipts. Before checking a claim, the verifier must be configured with one or more identities of trusted transparency services.  If more than one service is configured, the verifier MUST return which service the claim is registered on. In some scenarios, the verifier already expects a specific issuer and feed for the claim, while in other cases they are not known in advance and can be an output of validation.  Verifiers SHOULD offer a configuration to decide if the issuer's signature should be locally verified (which may require a DID resolution, and may fail if the manifest is not available or if the key is revoked), or if it should trust the validation done by the TS during registration. Some verifiers MAY decide to locally re-apply some or all of the registration policies if they have limited trust in the TS.  In addition, verifiers MAY apply arbitrary validation policies after the signature and receipt have been checked.  Such policies may use as input all information in the envelope, the receipt, and the payload, as well as any local state. Verifiers SHOULD offer options to store or share receipts in case they are needed to audit the TS in case of a dispute. </ins> 7.
9. <del> Privacy Considerations </del> <ins> Unless advertised by the TS, every issuer should treat its claims as public.  In particular, their envelope and statement should not carry any private information in plaintext. </ins> 10. <del> Security Considerations </del> <ins> On its own, verifying a transparent claim 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 TS.  If the verifier trusts the issuer, it can infer that the claim 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 TS, it can independently infer that the claim passed the TS registration policy and that has been persisted in the ledger. Unless advertised in the TS registration policu, the verifier should not assume that the ordering of transparent claims in the ledger matches the ordering of their issuance. Similarly, the fact that an issuer can be held accountable for its transparent claims does not on its own provide any mitigation or remediation mechanism in case one of these claims turned out to be misleading or malicious--just that signed evidence will be available to support them. Issuers SHOULD ensure that the statements in their claims are correct and unambiguous, for example by avoiding ill-defined or ambiguous formats that may cause verifiers to interpret the claim as valid for some other purpose. Issuers and Transparency Services SHOULD carefully protect their private signing keys and avoid these keys for any purpose not described in this architecture.  In case key re-use is unavoidable, they MUST NOT sign any other message that may be verified as an envelope. </ins> 11.
There are many types of Statements (such as SBOMs, malware scans, audit reports, policy definitions) that Issuers may want to turn into Claims.  The Issuer must first decide on a suitable format to <del> serialize the Statement, such as: - JSON-SPDX - CBOR-SPDX - SWID - CoSWID - CycloneDX - in-toto - SLSA </del> <ins> serialize the Statement, such as: JSON-SPDX CBOR-SPDX SWID CoSWID CycloneDX in-toto SLSA </ins> Once the Statement is serialized with the correct content type, the Issuer should fill in the attributes for the Registration policy
7. <del> We explain how multiple, independent Transparency Services can be composed to distribute supply chains without a single transparency authority trusted by all parties. Multiple SCITT instances, governed and operated by different organizations. For example, - a small, simple SCITT instance may keep track specifically of the software used for operating SCITT services.  - an air-gapped data center may operate its own SCITT Registry to retain full control and auditing of its software supplies. </del> <ins> Editor's note: This section needs work. </ins> <del> How? - Policy-based.  Within an organization, local Verifiers contact an authoritative SCITT that records the latest policies associated with classes of Artifacts; these policies indicate which Issuers and Registries are trusted for verifying signed Transparent Claims for these Artifacts. </del> <ins> Multiple, independently-operated transparency services can help secure distributed supply chains, without the need for a single, centralized service trusted by all parties.  For example, multiple SCITT instances may be governed and operated by different organizations that do not trust one another. </ins> <del> Other federation mechanisms? </del> <ins> This may involve registering the same Claims at different transparency services, each with their own purpose and registration policy.  This may also involve attaching multiple Receipts to the same Claims, each Receipt endorsing the Issuer signature and a subset of prior Receipts, and each TS verifying prior Receipts as part of their registration policy. </ins> <del> We'd like to attach multiple Receipts to the same signed Claims, each Receipt endorsing the Issuer signature and a subset of prior Receipts.  This involves down-stream Registries verifying and recording these Receipts before issuing their own Receipts. </del> <ins> For example, a supplier TS may provide a complete, authoritative Registry for some kind of Claims, whereas a consumer TS may collect different kinds of Claims to ensure complete auditing for a specific use case, and possibly require additional reviews before registering some of these claims. </ins> 8. <del> Editor's Note: this may be moved to appendix. </del> <ins> Editor's Note: This may be moved to appendix. </ins> 8.1.
Claim Issuer, as an integer, for example "-35" for ECDSA with SHA- 384, see COSE Algorithms registry [2]; <del> Issuer (label: "TBD", to be registered): DID (Decentralized </del> <ins> Issuer (label: "TBD", temporary: "391"): DID (Decentralized </ins> Identifier, see W3C Candidate Recommendation [3]) of the signer, as a string, for example "did:web:example.com"; <del> Feed (label: "TBD"): the Issuer's name for the Artifact, as a string; </del> <ins> Feed (label: "TBD", temporary: "392"): the Issuer's name for the Artifact, as a string; </ins> payload type (label: "3"): Media type of payload as a string, for example "application/spdx+json" <del> Registration policy info (label: "TBD"): a map of additional attributes to help enforce Registration policies; </del> <ins> Registration policy info (label: "TBD", temporary: "393"): a map of additional attributes to help enforce Registration policies; </ins> <del> DID key selection hint (label: "TBD"): a DID method-specific selector for the signing key, as a bytestring. </del> <ins> Key ID (label: "4"): Key ID, as a bytestring. </ins> Additionally, Claims MAY carry the following unprotected headers: <del> Receipts (label: "TBD", to be registered): Array of Receipts, </del> <ins> Receipts (label: "TBD", temporary: "394"): Array of Receipts, </ins> defined in In CDDL RFC8610 notation, the Envelope is defined as follows:
The following parameters MUST be included in the protected header of the countersigner (sign_protected in cose_sign1_countersign): <ins> Service ID (label: TBD): The Service identifier, as defined in the Transparency Service parameters. </ins> Issued At (label: TBD): The time at which the countersignature was issued as the number of seconds from 1970-01-01T00:00:00Z UTC, ignoring leap seconds.
5.5. <del> Given the TS parameters, a signed envelope, and a Receipt for it, the following steps must be followed to verify this Receipt. </del> <ins> Given a signed envelope and a Receipt for it, the following steps must be followed to verify this Receipt. Decode the protected header of the Receipt and look-up the TS parameters using the service_id field. </ins> Verify that the Receipt Content structure is well-formed, as described in ReceiptContents. Construct a "Countersign_structure" as described in <del> cose_sign1_countersign, using "sign_protected" from the "leaf_info" field of the receipt contents. </del> <ins> cose_sign1_countersign, using the protected header of the Receipt as "sign_protected". </ins> Compute "LeafBytes" as the bytestring concatenation of the internal hash, the hash of internal data, and the hash of the
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
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,
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.
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
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
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.
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.
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
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:
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>
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> 2.2.2. </ins> <del> 2.1.2.1. </del> <ins> 2.2.2.1. </ins> <del> 2.1.2.2. </del> <ins> 2.2.2.2. </ins> One of the following:
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
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>