Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
1) <!--[rfced] The document title has been updated as follows. Please let us know any objections. Original: COSE Header parameter for RFC 3161 Time-Stamp Tokens Currently: Concise Binary Object Representation (CBOR) Object Signing and Encryption (COSE) Header Parameter for Timestamp Tokens as Defined in RFC 3161 --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on <https://www.rfc-editor.org/search>. --> 3) <!-- [rfced] Regarding the use of "<tt>" in this document and this note in your reply to our Document Intake email: "We tried to <tt/> all COSE types (e.g., COSE_Sign1) and COSE header names (e.g., 3161-ttc) ... I am not sure we were entirely consistent, though. This also raises the question of why we did not include the types from RFC3161." For consistency of style, we made the following updates. Please let us know any objections: * bstr: We added <tt>s around this term in Table 1. * MessageImprint: We added <tt>s around 4 instances of "the MessageImprint". * TimeStampToken: We added <tt>s around this term in the Introduction. Would you like us to add <tt>s around other terms from RFC 3161 (e.g., TSTInfo)? If yes, please specify which terms/types from RFC 3161 you would like us to enclose in <tt>...</tt>. --> 4) <!-- [rfced] Section 1.1: Does "primary" in these sentences indicate that the primary use case is more important than the second use case or perhaps was developed earlier? Please see the definition of "primary" on <https://www.merriam-webster.com/dictionary/primary>, and let us know if "primary" should be changed to "first". Original: The primary use case is that of "long-term signatures", i.e., signatures that can still be verified even after the signing certificate has expired. ... This primary usage scenario motivates the "COSE then Timestamp" mode described in Section 2.1. --> 5) <!-- [rfced] Section 1.1: This sentence did not parse. We updated it as follows. If this is incorrect, please clarify "in order to reduce ... as well as avoiding". Original: It is also common practice to only register the signed parts of a statement (the "signed statement" portion) with a transparency service, in order to reduce the complexity of consistency checks at a later stage, as well as avoiding the need to retrieve or reconstruct unsigned parts. Currently: It is also common practice to only register the signed parts of a statement (the "signed statement" portion) with a transparency service, in order to reduce the complexity of consistency checks at a later stage and to avoid the need to retrieve or reconstruct unsigned parts. --> 6) <!-- [rfced] Sections 3.1 and subsequent: We see that this document uses "MessageImprint" in text but RFC 3161 uses "messageImprint" in its text (e.g., "The messageImprint field" in its Section 2.4.1). Please confirm that you wish to keep the currently capitalized form in this document. --> 7) <!-- [rfced] Please review each artwork element and let us know if any should be marked as sourcecode instead. The current list of preferred values for "type" is available at <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. If the current list does not contain an applicable type, you may suggest additions for consideration. Note that it is also acceptable to leave the "type" attribute unset. Please note that per <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>, we changed instances of sourcecode type "asn1" to "asn.1". --> 8) <!-- [rfced] Section 5: As it appears that "the ones" means "the parameters" (per "This document defines two ... parameters" as used in the Abstract and Introduction), we changed "ones" to "parameters". If this is incorrect, please clarify the text. Original: Such a mechanism can be employed inside the ones described in this specification, but is out of scope for this document. Currently: Such a mechanism can be employed inside the parameters described in this specification but is out of scope for this document. --> 9) <!-- [rfced] References: STD 96 consists of two RFCs: RFC 9052 and RFC 9338 (Please type "STD 96" (unquoted) in the Search box on <https://www.rfc-editor.org>). This makes the text "Also review the Security Considerations section in [STD96]" in Section 5 problematic, as this text appears to refer to RFC 9052 only. If you don't wish to also refer to RFC 9338 ("CBOR Object Signing and Encryption (COSE): Countersignatures", published December 2022), we suggest changing "[STD96]" to "[RFC9052]". Also, STD 70 only consists of one RFC (RFC 5652). If you would like to change "[STD96]" to "[RFC9052]", would you also like to change "[STD70]" to "[RFC5652]"? Please advise regarding both of the above. Original: Also review the Security Considerations section in [STD96]. ... [STD96] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://doi.org/10.17487/RFC9052>. --> 10) <!-- [rfced] Appendices A.1 and A.2: Please confirm that the "OBJECT IDENTIFIER '1 2 3 4 1'" entries are correct and not some type of placeholder. We ask because (1) we don't see anything like it in any published RFC except for RFC 4134, which appears to mostly use similar entries as privacy mark tests and (2) "1.2.3.4.1" yields the following error on <https://oid-base.com/>: Sorry.. Error: * OID 1.2.3 cannot exist: For examples, use {joint-iso-itu-t(2) example(999)} Original: OBJECT IDENTIFIER '1 2 3 4 1' ... OBJECT IDENTIFIER '1 2 3 4 1' --> 11) <!-- [rfced] Acknowledgments: As it appears that the authors did not intend to list themselves as editors in the first-page header or in the Authors' Addresses section, we changed "The editors" to "The authors". Please let us know any concerns. Original: The editors would like to thank Alexey Melnikov, Carl Wallace, ... Currently: The authors would like to thank Alexey Melnikov, Carl Wallace, ... --> 12) <!-- [rfced] Terminology a) The following terms were used inconsistently in this document. We chose to use the latter forms on the right. Please let us know any objections. COSE then Timestamp -> COSE, then Timestamp time-stamp tokens (3 instances - document title and title of Section 3) -> timestamp token(s) (11 instances in text) Timestamp then COSE -> Timestamp, then COSE b) The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. COSE signed object vs. signed COSE object private-key (where used as a modifier) (e.g., "private-key parallelogram boxes") vs. private key (e.g., "private key material") (un)protected header(s) (where used as a modifier) (e.g., "unprotected header parameter", "protected header parameter", and "protected headers bucket") vs. protected-header (e.g., "protected-header payload timestamps") c) We see that after "TST" is defined as "TimeStampToken" in Section 1, the text alternates between using "TimeStampToken" and "TST". Because this is a short document, would you like to change the subsequent instances of "TimeStampToken" to "TST" once it's defined? --> 13) <!-- [rfced] Please note that we added expansions for the following abbreviations where first used, per Section 3.6 of RFC 7322 ("RFC Style Guide" - <https://www.rfc-editor.org/info/rfc7322>). Please review carefully to ensure correctness. CBOR: Concise Binary Object Representation CMS: Cryptographic Message Syntax (per cited RFC 5652) TSA: Time Stamping Authority (per RFC 3161) --> 14) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide at <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. Lynne Bartholomew and Karen Moore RFC Production Center On Feb 5, 2026, at 2:07 PM, RFC Editor via auth48archive <[email protected]> wrote: *****IMPORTANT***** Updated 2026/02/05 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/rfc9921.xml https://www.rfc-editor.org/authors/rfc9921.html https://www.rfc-editor.org/authors/rfc9921.pdf https://www.rfc-editor.org/authors/rfc9921.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9921-diff.html https://www.rfc-editor.org/authors/rfc9921-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9921-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9921 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9921 (draft-ietf-cose-tsa-tst-header-parameter-08) Title : COSE Header parameter for RFC 3161 Time-Stamp Tokens Author(s) : H. Birkholz, T. Fossati, M. Riechert WG Chair(s) : Ivaylo Petrov, Michael B. Jones Area Director(s) : Deb Cooley, Paul Wouters -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected] -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
