Re: [auth48] AUTH48: RFC-to-be 9558 <draft-makarenko-gost2012-dnssec-05> for your review

[Boris Makarenko <[e-mail]>]

Eliot, RFC editor:

I have no objection to adding this text to the the end of Section 1 of 
the document. We're completely okay with that.

>> Caution:
>>
>> This specification is not a standard and does not have IETF community 
>> consensus.  It makes use of a cryptographic algorithm that is a 
>> national standard for Russia. Neither the IETF nor the IRTF has 
>> analyzed that algorithm for suitability for any given application, 
>> and it may contain either intended or unintended weaknesses.
>>
I also agree with all the edits proposed by RFC editor.

So, I approve the publication of the RFC.

Thank you all for your work.

Boris


08.03.2024 09:53, Independent Submissions Editor (Eliot Lear) пишет:
>
> Authors, RPC:
>
> Since this document entered the RFC Editor queue, the independent 
> submissions editor has been in discussions with the IAB and the 
> editorial board about national cryptography.  The following text 
> should be added to the end of Section 1 of this document.
>
>> Caution:
>>
>> This specification is not a standard and does not have IETF community 
>> consensus.  It makes use of a cryptographic algorithm that is a 
>> national standard for Russia. Neither the IETF nor the IRTF has 
>> analyzed that algorithm for suitability for any given application, 
>> and it may contain either intended or unintended weaknesses.
>>
> Note: this is not a reflection on any particular country and will be 
> equally applied to *all* national cryptography, nor is it a reflection 
> of any specific cryptographic quality in GOST.
>
> Authors, I apologize for how late in this process this change is being 
> requested, but that was due to the timing of discussions with the IAB 
> and my editorial board.
>
> Eliot
> On 07.03.2024 23:25, [e-mail] wrote:
>> *****IMPORTANT*****
>>
>> Updated 2024/03/07
>>
>> 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
>>     
>>     *[e-mail]  (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).
>>       
>>     *[e-mail], 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,
>>          [e-mail]  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/rfc9558.xml
>>     https://www.rfc-editor.org/authors/rfc9558.html
>>     https://www.rfc-editor.org/authors/rfc9558.pdf
>>     https://www.rfc-editor.org/authors/rfc9558.txt
>>
>> Diff file of the text:
>>     https://www.rfc-editor.org/authors/rfc9558-diff.html
>>     https://www.rfc-editor.org/authors/rfc9558-rfcdiff.html  (side by side)
>>
>> Diff of the XML:
>>     https://www.rfc-editor.org/authors/rfc9558-xmldiff1.html
>>
>>
>> Tracking progress
>> -----------------
>>
>> The details of the AUTH48 status of your document are here:
>>     https://www.rfc-editor.org/auth48/rfc9558
>>
>> Please let us know if you have any questions.
>>
>> Thank you for your cooperation,
>>
>> RFC Editor
>>
>> --------------------------------------
>> RFC9558 (draft-makarenko-gost2012-dnssec-05)
>>
>> Title            : Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
>> Author(s)        : B. Makarenko, V. Dolmatov, Ed.
>>