Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 2) <!--[rfced] We had the following questions related to SVG used throughout the document: a) Please review our update to Figure 1 from "3rd-party" to "third-party". It looks like making this change may have affected the spacing of that sentence. Please regenerate. b) We note that the text within at least one (maybe more) of the SVG figures is not able to be selected. Is it possible to modify the SVG using your preferred SVG editing software to improve the rendering of the string in the SVG? Here is an example of SVG where the strings within the SVG are selectable and searchable: https://www.rfc-editor.org/rfc/rfc9576.html#figure-1 --> 3) <!--[rfced] We had the following questions/comments related to the Terminology section: a) We have moved the following paragraph to appear directly before the list of terms defined in this document as the terms borrowed from other documents (e.g., "header") are not capitalized in the text. We have also changed "corresponding" to "following" for clarity. Please review and let us know any objections. Original: When used in text, the corresponding terms are capitalized. To ensure readability, only a core set of terms is included in this section. Current: When used in text, the following terms are capitalized. To ensure readability, only a core set of terms is included in this section. b) Related to the paragraph above in part (a): Note that several of the terms in the Terminology list are not consistently capped throughout the rest of the document. For example, should "attestation" be capped within the Attestation definition (occurs two times lowercase)? Here is a list of terms that appear in lowercase in the body of the document: append-only artifact attestation equivocation issuer (see also single-issuer) non-equivocation receipt (see related cluster-wide query as this affects both documents) registration relying party (or parties) signed statement statement transparent statement transparency service (or services) verifiable data structure (see related question about abbreviation use) We suggest the following possible ways forward: -Cap the terms on their introduction (i.e., <dt>) in the list in the Terminology section only: lowercase when used in prose. Remove the sentence about these terms being capped from the Terminology section (from (a) above). -Cap the terms consistently throughout the document. Leave the sentence from (a) as is. -Leave the variation between capitalization and lowercase if there is meaning involved (e.g., when capped it has this definition but when lowercase it does not) and update the sentence in (a) to explain the meaning behind the variation. NOTE: Generally, we believe over-capitalizing nouns can get distracting to readers, but we understand the desire to match past use or add meaning, etc. Our main goal is to ensure the reader understands your intent. c) The only term that seems to be out of alphabetical order in this is "Attestation". May we move this term to fit in the A's? d) We note that [RFC8392] uses "CWT Claims Set" rather than "CWT Claim Set". Please review and let us know what/if any updates are necessary. Current: In SCITT Statements and Receipts, the iss Claim is a member of the COSE header parameter 15: CWT Claims defined in [RFC9597], which embeds a CWT Claim Set [RFC8392] within the protected header of a COSE Envelope. e) Section 4 is titled "Definition of Transparency". Does this seem like something that should be grouped with "Terminology" (i.e., should it be Section 3.1)? f) Section 5.1.1.1: Should this pointer to the definition of "trust anchor" be replaced by an entry in the Terminology section instead? We note that the term was already used at the end of Section 5.1.1. Original: Transparency Services MUST maintain a list of trust anchors (see definition of trust anchor in [RFC4949]) in order to check the signatures of Signed Statements, either separately, or inside Registration Policies. g) Section 9.4: Should this pointer to the definition of cryptoperiod be replaced by an entry in the Terminology section instead? Original: * rotate their keys at a cryptoperiod (defined in [RFC4949]) appropriate for the key algorithm and domain-specific regulations h) Please see our cluster-wide questions related to discrepancies between the definitions that appear in both documents in this cluster. --> 4) <!--[rfced] Can you let us know how "NIST guidance "Software Supply Chain Security Guidance EO 14028" is different from [NIST_E014028]? This currently reads as if the reference is using itself. Original: NIST guidance "Software Supply Chain Security Guidance EO 14028" uses the definition from [NIST_EO14028], which states that an "attestation" is "The issue of a statement, based on a decision, that fulfillment of specified requirements has been demonstrated.". The related reference entry: [NIST_EO14028] NIST, "Software Supply Chain Security Guidance Under Executive Order (EO) 14028 Section 4e", 4 February 2022, <https://www.nist.gov/system/files/documents/2022/02/04/ software-supply-chain-security-guidance-under-EO-14028- section-4e.pdf>. Perhaps: [NIST_EO14028] states that an "attestation" is: The issue of a statement, based on a decision, that fulfillment of specified requirements has been demonstrated. --> 5) <!--[rfced] In the following list, we will update to have the citation follow the text unless we hear objection. Original: * [CoSWID] Concise Software Identification Tags format * [CycloneDX] Bill of Materials format * [in-toto] Supply chain description metadata * [SPDX-CBOR] Software component description format * [SPDX-JSON] Software component description format * [SLSA] Supply-chain Levels for Software Artifacts * [SWID] Software Identification Tag format --> 6) <!--[rfced] We had the following questions about the figure in Section 6.2: a) There is no number or title. How may we update? b) We believe To Be Signed Bytes should be made To-Be-Signed Bytes to match the use in the Terminology section. If this is the case, please update and regenerate the SVG. --> 7) <!--[rfced] Section 6.3 (in the numbered list): Points 1-3 began with a phrase enclosed in <strong> followed by a colon; but points 4 and 5 did not have text following the part in <strong>. Please see our formatting updates where we: - got rid of <strong>, - got rid of the colons, and - added a blank line after the text that was in <strong> We believe that the current version of this list looks more parallel (each entry is the step performed followed by any further info if it exists) and might be easier for the reader's eyes (especially in the text file). Please review and let us know if we've not correctly captured your intent. --> 8) <!--[rfced] The parentheses at the end of these sentences make them read strangely (how does it relate to the rest of the sentence?). Please review: Original: The verifiable data structure (-111) uses 1 from (RFC9162_SHA256). and The structure of this inclusion proof is specific to the verifiable data structure used (RFC9162_SHA256). --> 9) <!--[rfced] Please carefully review our edits to this text to ensure we have maintained your intended meaning. Original: Transparency Services can leverage Verifiable Data Structures which only retain cryptographic metadata (e.g. a hash), rather than the complete Signed Statement, as part of a defense in depth approach to maintaining confidentiality. Current: Transparency Services can leverage Verifiable Data Structures that only retain cryptographic metadata (e.g., a hash) rather than the complete Signed Statement as part of an in-depth defensive approach to maintaining confidentiality. --> 10) <!--[rfced] FYI - the RPC will communicate any changes to Sections 10.1 and 10.2 to IANA for them to update the following registries respectively to exactly match the document once AUTH48 completes. https://www.iana.org/assignments/media-types/application/scitt-statement+cose https://www.iana.org/assignments/media-types/application/scitt-receipt+cose, --> 11) <!-- [rfced] The reference entries for [SPDX-CBOR] and [SPDX-JSON] are identical. Should these references be condensed down into one reference? Or are these references meant to point to specific parts of the SPDX Specification? Current: [SPDX-CBOR] "SPDX Specification", <https://spdx.dev/use/specifications/>. [SPDX-JSON] "SPDX Specification", <https://spdx.dev/use/specifications/>. --> 12) <!--[rfced] We had the following questions/comments related to abbreviation use throughout the document: a) FYI - We have added expansions for abbreviations upon first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. b) FYI - We have updated to use an abbreviation (instead of its expanded form) after first use in accordance with the guidance at https://www.rfc-editor.org/styleguide/part2/#exp_abbrev. Please let us know any objections. c) Does TS refer to Transparency Service, Transparent Statement, or something else? After first use, we suggest using TS as described in (b) above. d) This document uses both: verifiable data structure proofs and Verifiable Data Structure Proofs We will capitalize on first use and introduce the VDP abbreviation as was used in draft-ietf-cose-merkle-tree-proofs-18 for use thereafter unless we hear objection. e) As one of the T's in SCITT stands for transparency, is "SCITT transparency" redundant? Original: This "content-agnostic" approach allows SCITT transparency services... --> 13) <!--[rfced] We had the following questions related to terminology use throughout the document (see also our cluster-wide terminology questions that impact terms used in both documents in C557): a) As the large majority of instances appear as shown on the right, we will update to use that form consistently throughout the body of the text unless we hear objection: SCITT Architecture vs. SCITT architecture x.509 vs. X.509 b) Should the following terms be made consistent throughout? If so, please let us know the preferred form: Mandatory Registration Checks vs. mandatory Registration checks c) We see that this document uses the term "proof type". This term is defined in draft-ietf-cose-merkle-tree-proofs-18. Should there be any type of citation pointing the reader to the Terminology section of that document for more information? d) Most instances of "iss" refer to it as a Claim. Should these sentences be updated as follow? Original: When x5t or x5chain is present in the protected header, iss MUST be a string that meets URI requirements defined in [RFC8392]. The iss value's length MUST be between 1 and 8192 characters in length. Perhaps: When x5t or x5chain is present in the protected header, the iss Claim MUST be a string that meets URI requirements defined in [RFC8392]. The iss Claim value's length MUST be between 1 and 8192 characters in length. e) We note that Section 2.2.3 uses both "integrated software" and "Software Integration". Please review if these should be made consistent and if capitalization is necessary. f) We see the following various treatment for media type names (with respect to quotation marks, parentheses, word ordering, etc.): ('content type') media type (scitt-receipt+cose) media type media type application/scitt-receipt+cose media type application/scitt-statement+cose May we make these consistent? g) Should the iss Claims mentioned in the first sentence below be in quotation marks to match the quotations used for the sub Claim in the second sentence below? Original: Multi-tenant support can be enabled through the use of identifiers in the iss Claim, for example, ts.example. may have a distinct Issuer identity for each sub domain, such as tenant1.ts.example. and tenant2.ts.example.. Original: It indicates the Signed Statement is securing a JSON content type, and identifying the content with the sub Claim "vendor.product.example". --> 14) <!-- [rfced] See a list below of terms enclosed in <tt> in this document. We note that some of the terms enclosed in <tt> appear elsewhere in the document without <tt> (e.g., payload, receipts). <tt>-111</tt> <tt>15: CWT Claims</tt> <tt>15</tt> <tt>-1</tt> <tt>1</tt> <tt>-2</tt> <tt>3</tt> <tt>8</tt> <tt>CWT Claims</tt> <tt>iss</tt> Claim <tt>Issuer Claim</tt> <tt>kid</tt> <tt>payload</tt> <tt>receipts</tt> <tt>Subject Claim</tt> <tt>sub</tt> CWT Claim <tt>tenant1.ts.example.</tt> <tt>tenant2.ts.example.</tt> <tt>ts.example.</tt> <tt>x5chain</tt> <tt>x5t</tt> Please review to ensure the usage of <tt> is correct and consistent. Let us know if any updates are needed. --> 15) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> Thank you. Megan Ferguson RFC Production Center *****IMPORTANT***** Updated 2026/03/06 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * [email protected] (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * [email protected], which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, [email protected] will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9943.xml https://www.rfc-editor.org/authors/rfc9943.html https://www.rfc-editor.org/authors/rfc9943.pdf https://www.rfc-editor.org/authors/rfc9943.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9943-diff.html https://www.rfc-editor.org/authors/rfc9943-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9943-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9943 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9943 (draft-ietf-scitt-architecture-22) Title : An Architecture for Trustworthy and Transparent Digital Supply Chains Author(s) : H. Birkholz, A. Delignat-Lavaud, C. Fournet, Y. Deshpande, S. Lasker WG Chair(s) : Jon Geater, Christopher Inacio Area Director(s) : Deb Cooley, Paul Wouters -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
