Authors, An additional question:
15) Regarding Table 1 (https://www.rfc-editor.org/authors/rfc9921.html#table-1) -- Are these updates to the IANA-registered descriptions acceptable? If so, we will ask IANA to update the registry [1] accordingly. The rationale is to avoid using an RFC number as an adjective and to match the capitalization within the document (titles of Sections 2.1 and 2.2). Original: 3161-ttc 269 RFC 3161 timestamp token: Timestamp then COSE 3161-ctt 270 RFC 3161 timestamp token: COSE then Timestamp Current: 3161-ttc 269 Timestamp Token per RFC 3161: Timestamp, Then COSE 3161-ctt 270 Timestamp Token per RFC 3161: COSE, Then Timestamp [1] https://www.iana.org/assignments/cose/cose.xhtml#header-parameters Thank you. Alice Russo RFC Production Center > On Feb 12, 2026, at 11:23 AM, Alice Russo <[email protected]> wrote: > > Thomas, > > Thank you for your reply. Please see the follow-ups below. The revised files > are here (please refresh): > https://www.rfc-editor.org/authors/rfc9921.html > https://www.rfc-editor.org/authors/rfc9921.txt > https://www.rfc-editor.org/authors/rfc9921.pdf > https://www.rfc-editor.org/authors/rfc9921.xml > > This diff file shows all changes from the approved I-D: > https://www.rfc-editor.org/authors/rfc9921-diff.html > https://www.rfc-editor.org/authors/rfc9921-rfcdiff.html (side by side) > > This diff file shows the changes made during AUTH48 thus far: > https://www.rfc-editor.org/authors/rfc9921-auth48diff.html > https://www.rfc-editor.org/authors/rfc9921-auth48rfcdiff.html (side by side) > > -- Re: #1, FYI, we reverted to not expand "CBOR" in the title and abstract. > This is in keeping with the titles of recent RFCs (e.g., RFCs 9864, 9679, > 9596) and avoids having an acronymn expansion within an acronym expansion. > > Original: > COSE Header parameter for RFC 3161 Time-Stamp Tokens > > Current: > CBOR Object Signing and Encryption (COSE) Header Parameter for Timestamp > Tokens as Defined in RFC 3161 > > > Regarding "CBOR": It is expanded in Section 3.1 (the first instance outside > the context of "COSE"). Just let us know if you prefer to add a reference to > RFC 8949, or a sentence that expands CBOR earlier. > > -- Re: #4 (usage of "primary"), no changes needed. > > -- Re: #6 (MessageImprint in this document vs. messageImprint in RFC 3161) > >> Perhaps we should do this: >> * MessageImprint, when referring to the type; >> * messageImprint, when referring to the value. >> However, there may be a non-zero risk of introducing some confusion. >> WDYT? > > If the current usage (all 'MessageImprint' in this document) is sufficiently > clear, then we suggest leaving it as is in order to avoid introducing > confusion. > > > -- Re: #10 (use of the OID from freeTSA.org, as detailed in your reply) > > Thank you for this information. Because the Internet-Draft was approved with > this OID in the examples in Appendices A.1 and A.2, we will assume it’s fine > to leave it unless someone suggests otherwise. > > > -- Re: #12b (Terminology) > >>> COSE signed object vs. signed COSE object >> >> COSE signer object > > We updated to "COSE signed object", assuming "signed" not "signer" was > intended; please review. > > FYI, there remain 2 instances of "signed COSE message". (Of note: We see > zero instances of "COSE signed object" in existing RFCs. We see "COSE Signed > Message" in RFC 9052.) > > > We will wait to hear from you again and from your coauthors > before continuing the publication process. This page shows > the AUTH48 status of your document: > https://www.rfc-editor.org/auth48/rfc9921 > > Thank you. > > Alice Russo > RFC Production Center > >> On Feb 9, 2026, at 9:05 AM, Thomas Fossati <[email protected]> wrote: >> >> Hi Lynne, Karen, >> >> On Thu, 5 Feb 2026 at 23:09, <[email protected]> wrote: >>> >>> 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 --> >> >> OK >> >>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the >>> title) for use on <https://www.rfc-editor.org/search>. --> >> >> Nothing to add. >> >>> 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>. --> >> >> Yes, please: >> >> * TSTInfo (seems the only one left out) >> >>> 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. --> >> >> Primary is used to mean "more important than the other". >> >>> 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. --> >> >> Sounds good, thanks. >> >>> 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. --> >> >> Perhaps we should do this: >> * MessageImprint, when referring to the type; >> * messageImprint, when referring to the value. >> However, there may be a non-zero risk of introducing some confusion. >> WDYT? >> >>> 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". --> >> >> With this change, it all looks in order. >> >>> 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. --> >> >> hmm, "inside" is an awkward term to use here. What we mean is that, >> although the described mechanism could be used in the context of the >> specified technology (i.e., the header parameters), we are not >> interested in going into detail here. >> >> As an alternative, we could remove the awkward part and simply say: >> >> Such a mechanism 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]". >> >> Having re-read the security considerations of 9338, I believe it's just >> 9052 that matters here. >> >>> 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. >> >> Moving "[STD96]" to "[RFC9052]" and "[STD96]" to "[RFC9052]" works. >> >>> 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' --> >> >> Thanks for spotting this! This is the OID that freeTSA.org [1] uses as >> TSAPolicyId in their TSTInfo. To provide some context, we used >> freeTSA.org as a TSA to which our requests are sent to create >> the examples. However, as they are an independent entity, we don't have >> any control over that protocol parameter. >> >> If you think it's critical, we could recreate the examples using a >> different, more compliant TSA. >> >> [1] https://freetsa.org/index_en.php >> >>> 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, ... --> >> >> Perfect, thanks. >> >>> 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 >> >> OK >> >>> 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 >> >> COSE signer object >> >>> private-key (where used as a modifier) >>> (e.g., "private-key parallelogram boxes") vs. >>> private key (e.g., "private key material") >> >> "private-key" is the label used in the corresponding diagram box (I >> believe it's <tt>'d), so it should be OK as is. >> >>> (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") >> >> We should only use the terms "unprotected header parameter" and >> "protected header parameter". If we are referring to header parameters >> in a specific header, we spell this out, for example, "timestamp header >> parameters in the protected header". >> >>> 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? --> >> >> Yes, please. >> >>> 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) --> >> >> Thanks! >> >>> 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. --> >> >> ACK >> >>> >>> Thank you. >>> >>> Lynne Bartholomew and Karen Moore >>> RFC Production Center >> >> Thank you! >> -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
