jiebi/CodeConvo huggingface dataset:
Code change:
See URL Hi! Unfortunately, we couldn't submit the draft before the meeting and discuss it face-to-face. But here's a -01 fresh from the oven. We absorbed the feedback we got in SF and went ahead with one single header. However, the two modes of use ([1], [2]) define different inputs into the timestamping machinery and therefore create a different binding between COSE and TST. At present, the only way to distinguish between the two semantics is by their position in the COSE message (i.e., protected vs unprotected), which does not look like a good design :-) cheers, thanks [1] URL [2] URL ---------- Forwarded message --------- From: Date: Tue, 7 Nov 2023 at 14:36 Subject: New Version Notification for draft-ietf-cose-tsa-tst-header-parameter-URL To: Henk Birkholz , Maik Riechert , Maik Riechert , Thomas Fossati , A new version of Internet-Draft draft-ietf-cose-tsa-tst-header-parameter-URL has been successfully submitted by Thomas Fossati and posted to the IETF repository. Name: draft-ietf-cose-tsa-tst-header-parameter Revision: 01 Title: COSE Header parameter for RFC 3161 Time-Stamp Tokens Date: 2023-11-07 Group: cose Pages: 6 URL: URL Status: URL HTML: URL HTMLized: URL Diff: https://author-URL Abstract: RFC 3161 provides a method for timestamping a message digest to prove that the message was created before a given time. This document defines a CBOR Signing And Encrypted (COSE) header parameter that can be used to combine COSE message structures used for signing (i.e., COSESign and COSESign1) with existing RFC 3161-based timestamping infrastructure. The IETF Secretariat

Related discussion:
text: As part of the signature verification, the receiver MUST make sure that the message imprint in the embedded timestamp token matches either the payload or the signature fields, depending on the mode of <del> use.. </del> <ins> use. </ins> <del> Guidance is illustrated in RFC3161 via an example that shows how timestamp tokens can be used during signature verification of a timestamped message when using X.509 certificates. </del> <ins> RFC3161 provides an example that illustrates how timestamp tokens can be used to verify signatures of a timestamped message when utilizing X.509 certificates. </ins> <del> 4. </del> <ins> 5. </ins> The security considerations made in RFC3161 as well as those of RFC9338 apply. <del> 5. </del> <ins> 6. </ins> <del> IANA is requested to add the COSE Header parameter described in sec- tst-hdr to the "COSE Header Parameters" of the IANA.cose registry. </del> <ins> IANA is requested to add the two COSE Header parameters described in sec-tst-hdr to the "COSE Header Parameters" of the IANA.cose registry. </ins>
Code change:
NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!

Related discussion:
text: Trust in the TS itself is supported both by protecting their implementation (using, for instance, replication, trusted hardware, <del> and system attestation) and by enabling independent audits of the correctness and consistency of its ledger, thereby holding the </del> <ins> and remote attestation of systems) and by enabling independent audits of the correctness and consistency of its ledger, thereby holding the </ins> organization accountable that operates it.  Unlike CT, where independent auditors are responsible for enforcing the consistency of multiple independent instances of the same global ledger, we require
Code change:
NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!

Related discussion:
text: of Supply Chain Integrity, Transparency, and Trust throughout this document.  When used in text, the corresponding terms are capitalized.  To ensure readability, only a core set of terms is <del> included in this section. </del> <ins> included in this section.[^1] </ins> 4.
Code change:
NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!

Related discussion:
text: Custom policies may use additional information present in the ledger outside of claims.  For instance, issuers may have to register on the TS before claims can be accepted; a custom policy may be used to <del> enforce access control to the transparency service.  Similarly, policies may be used </del> <ins> enforce access control to the transparency service.  Verifying the signature of the issuer is also a form of registration policy, but it is globally enforced in order to separate authentication and authorization, with policy only considering authentic inputs. </ins> tbl-initial-named-policies defines an initial set of named policies that TS may decide to enforce.  This may be evolved in future drafts.
Code change:
NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!

Related discussion:
text: 6. This section details the interoperability requirements for <del> implementers of claim issuance and validation libraries, and </del> <ins> implementers of claim issuance and validation libraries, and of </ins> transparency services. 6.1.
Code change:
NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!

Related discussion:
text: 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:
Code change:
NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!

Related discussion:
text: 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
Code change:
NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!

Related discussion:
text: 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
Code change:
NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!

Related discussion:
text: 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.
Code change:
NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!

Related discussion:
text: 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.
Code change:
Cleaning up the Federation section, still TBD.
Also:
Linting errors need to be addressed. NAME if this blocks publishing / merging perhaps we can merge and then fix?
Yes, I can fix the lint after merging. If this would be a branch and not a fork, I could do it here more easily.
lgtm, any objections? still in early stage

Related discussion:
text: 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
Code change:
Cleaning up the Federation section, still TBD.
Also:
Linting errors need to be addressed. NAME if this blocks publishing / merging perhaps we can merge and then fix?
Yes, I can fix the lint after merging. If this would be a branch and not a fork, I could do it here more easily.
lgtm, any objections? still in early stage

Related discussion:
text: 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.
Code change:
This adds temporary integer header parameter labels to have something to prototype against until the new fields are registered. I used 391 as starting offset as that's S+C+I+T+T.

Related discussion:
text: 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:
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: The Receipt structure is a CBOR array with two items, in order: <del> "service_id": The service identifier as tstr. </del> <ins> "protected": The protected header of the countersigner. </ins> "contents": The proof as a CBOR structure determined by the tree algorithm.
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: 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.
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: length "HASH_SIZE". "leaf_info": auxiliary inputs to recompute the leaf digest <del> included in the Merkle tree: the internal hash, the internal data, and the protected header of the countersigner. </del> <ins> included in the Merkle tree: the internal hash and the internal data. </ins> "internal_hash" MUST be a bytestring of length "HASH_SIZE";
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: 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