Also, approval from me. Best Stavros
Am 16. Juni 2025 15:52:06 MESZ schrieb Kaveh Bashiri <kaveh.bashiri.i...@gmail.com>: >Hello, >I approve from my side. >Best wishes, >Kaveh > >Am 16.06.25 um 13:01 schrieb ste...@gazdag.de: >> Hello, >> I approve from my side. >> Thanks, >> Stefan >>> Daniel Van Geest <daniel.vange...@cryptonext-security.com> hat am >>> 16.06.2025 12:12 CEST geschrieben: >>> >>> RFC Editor, >>> >>> Attached is an updated xml with either approval for you to make your >>> suggested changes, or our own suggestions based on your comments. >>> >>> Our comments are marked in the XML as follows: >>> >>> <!-- [authors] --> >>> >>> Coauthors, please review and indicate approval. >>> >>> I approve the proposed changes. >>> >>> Regards, >>> Daniel Van Geest >>> >>> On 2025-06-09 11:55 p.m., rfc-edi...@rfc-editor.org wrote: >>>> Authors, >>>> >>>> While reviewing this document during AUTH48, please resolve (as necessary) >>>> the following questions, which are also in the XML file. >>>> >>>> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in >>>> the title) for use onhttps://www.rfc-editor.org/search. --> >>>> >>>> >>>> 2) <!-- [rfced] We have updated the abstract for clarity. Please review >>>> and let us know if any updates are needed. >>>> >>>> Original: >>>> This document specifies algorithm identifiers and ASN.1 encoding >>>> formats for the stateful hash-based signature (HBS) schemes >>>> Hierarchical Signature System (HSS), eXtended Merkle Signature Scheme >>>> (XMSS), and XMSS^MT, a multi-tree variant of XMSS. This >>>> specification applies to the Internet X.509 Public Key infrastructure >>>> (PKI) when those digital signatures are used in Internet X.509 >>>> certificates and certificate revocation lists. >>>> >>>> Perhaps: >>>> This document specifies algorithm identifiers and ASN.1 encoding >>>> formats for the following stateful Hash-Based Signature (HBS) >>>> schemes: Hierarchical Signature System (HSS), eXtended Merkle >>>> Signature Scheme (XMSS), and XMSS^MT (a multi-tree variant of XMSS). >>>> When those digital signatures are used in Internet X.509 certificates >>>> and certificate revocation lists, this specification applies to the >>>> Internet X.509 Public Key Infrastructure (PKI). >>>> --> >>>> >>>> >>>> 3) <!-- [rfced] Please note that we updated instances of MT in XMSS^MT to >>>> appear as superscript to match how it appears in [SP800208]. Please review >>>> and let us know if you prefer otherwise. >>>> >>>> Note that the text file will continue to display XMSS^MT, but the HTML and >>>> PDF will display MT in superscript. >>>> --> >>>> >>>> >>>> 4) <!-- [rfced] Please review some questions regarding the following text: >>>> >>>> a) For ease of the reader, may we reformat this text as follows? >>>> >>>> Original: >>>> Usual backup and restore strategies when using a stateless signature >>>> scheme (e.g. SLH-DSA) are to duplicate private keying material and >>>> to operate redundant signing devices or to store and safeguard a copy >>>> of the private keying material such that it can be used to set up a >>>> new signing device in case of technical difficulties. >>>> >>>> Perhaps: >>>> Usual backup and restore strategies when using a stateless signature >>>> scheme (e.g., SLH-DSA) are to: >>>> * duplicate private keying material and operate redundant signing >>>> devices, or >>>> * store and safeguard a copy of the private keying material such >>>> that it >>>> can be used to set up a new signing device in case of technical >>>> difficulties. >>>> --> >>>> >>>> >>>> 5) <!-- [rfced] References: The original URL for the reference [CNSA2.0] >>>> returns a 404 error. We found the following archived URL for this page from >>>> the Internet Archive's Wayback Machine: >>>> >>>> https://web.archive.org/web/20220908002358/https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF >>>> >>>> Is there a better URL, or may we replace the current URL with this >>>> archived link? This URL has an archive date of 8 September 2022 (the >>>> original date >>>> for this reference was 7 September 2025). --> >>>> >>>> >>>> 6) <!-- [rfced] Acknowledgements: How may we adjust to make more clear the >>>> relationship between these various documents (as in, which documents are >>>> meant to be similar to each other)? >>>> >>>> Original: >>>> >>>> This document uses a lot of text from similar documents [SP800208], >>>> ([RFC3279] and [RFC8410]) as well as [I-D.ietf-lamps-rfc8708bis]. >>>> Thanks go to the authors of those documents. "Copying always makes >>>> things easier and less error prone" - [RFC8411]. >>>> >>>> Perhaps: >>>> >>>> This document uses a lot of text from similar documents, including: >>>> [SP800208], [RFC3279] and [RFC8410], as well as [RFC9708]. Thanks goes >>>> to the authors of those documents. "Copying always makes things easier >>>> and less error prone" [RFC8411]. >>>> >>>> --> >>>> >>>> >>>> 7) <!-- [rfced] Terminology and Abbreviations: >>>> >>>> a) We note that "object identifier" appears a few times after the >>>> abbreviation "OID" is introduced. For consistency throughout the document, >>>> may we abbreviate all instances of "object identifier" to "OID" after first >>>> expansion? >>>> >>>> b) We note different uses of the following term. For clarity, may we >>>> lowercase "certificate authorities" so that it does not >>>> appear to reference the abbreviation "CA"? >>>> >>>> Certification Authority (CA) certificates >>>> Certificate Authorities >>>> >>>> c) FYI - We expanded the following abbreviation upon first use >>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review >>>> carefully to ensure correctness: >>>> >>>> Internet of Things (IoT) >>>> >>>> --> >>>> >>>> >>>> 8) <!-- [rfced] We have changed all <artwork> elements in this document to >>>> <sourcecode>. Please review to confirm this is correct. >>>> >>>> In addition, please consider whether the "type" attribute of any >>>> <sourcecode> element should be set and/or has been set correctly. >>>> Currently, some are set to asn.1 and some are set to x509. >>>> >>>> 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, feel free to >>>> suggest additions for consideration. Note that it is also acceptable >>>> to leave the "type" attribute not set. --> >>>> >>>> >>>> 9) <!-- [rfced] Please review whether any of the notes in this document >>>> should be in the <aside> element. It is defined as "a container for content >>>> that is semantically less important or tangential to the content that >>>> surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). --> >>>> >>>> >>>> 10) <!-- [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. >>>> >>>> RFC Editor >>>> >>>> >>>> On Jun 9, 2025, at 3:47 PM,rfc-edi...@rfc-editor.org wrote: >>>> >>>> >>>> *****IMPORTANT***** >>>> >>>> Updated 2025/06/09 >>>> >>>> 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 >>>> *rfc-edi...@rfc-editor.org (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). >>>> *auth48archive@rfc-editor.org, 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, >>>> auth48archive@rfc-editor.org 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/rfc9802.xml >>>> https://www.rfc-editor.org/authors/rfc9802.html >>>> https://www.rfc-editor.org/authors/rfc9802.pdf >>>> https://www.rfc-editor.org/authors/rfc9802.txt >>>> >>>> Diff file of the text: >>>> https://www.rfc-editor.org/authors/rfc9802-diff.html >>>> https://www.rfc-editor.org/authors/rfc9802-rfcdiff.html (side by side) >>>> >>>> Diff of the XML: >>>> https://www.rfc-editor.org/authors/rfc9802-xmldiff1.html >>>> >>>> >>>> Tracking progress >>>> ----------------- >>>> >>>> The details of the AUTH48 status of your document are here: >>>> https://www.rfc-editor.org/auth48/rfc9802 >>>> >>>> Please let us know if you have any questions. >>>> >>>> Thank you for your cooperation, >>>> >>>> RFC Editor >>>> >>>> -------------------------------------- >>>> RFC9802 (draft-ietf-lamps-x509-shbs-13) >>>> >>>> Title : Use of the HSS and XMSS Hash-Based Signature Algorithms >>>> in Internet X.509 Public Key Infrastructure >>>> Author(s) : D. Geest, K. Bashiri, S. Fluhrer, S. Gazdag, S. Kousidis >>>> WG Chair(s) : Russ Housley, Tim Hollebeek >>>> Area Director(s) : Deb Cooley, Paul Wouters >>>> >>>>
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
