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

[Василий Долматов <[e-mail]>]

Hello,

I agree with all modifications proposed by RFC Editors. 

If Boris has deeper insight in some changes, he will let us know.

Thank you for your work.

dol@

> 8 марта 2024 г., в 01:26, [e-mail] написал(а):
> 
> 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 on https://www.rfc-editor.org/search. -->
> 
> 
> 2) <!--[rfced] May we remove the expansion, as GOST has not previously been 
> expanded in RFCs, and our understanding is GOST is more recognizable than 
> "GOsudarstvennyy STandart"?
> 
> Original:
>   Algorithms GOsudarstvennyy STandart(GOST) R 34.10-2012 and GOST R
>   34.11-2012 are Russian national standards.
> 
> Perhaps:
>   GOST R 34.10-2012 and GOST R 34.11-2012 are Russian national standards.  
> -->
> 
> 
> 3) <!-- [rfced] Please review the "type" attribute of each sourcecode element
> in the XML file to ensure correctness. If the current list of preferred
> values for "type" (https://www.rfc-editor.org/materials/sourcecode-types.txt) 
> does not contain an applicable type, then feel free to let us
> know. Also, it is acceptable to leave the "type" attribute not
> set.  
> 
> In addition, review each artwork element. Specifically,
> should any artwork element be tagged as sourcecode or another
> element?
> -->
> 
> 
> 4) <!--[rfced] Section 2.1: 
> a) For clarity, may we remove the word "algorithm"?
> b) Does 'Parameter set A" refer to the same mentioned in Section 2,
> i.e., id-tc26-3410-2012-256-paramSetA parameter set defined in RFC 7836? 
> If so, may this text be updated as follows or otherwise?
> 
> Original:
>   The OIDs in the structure above represent GOST R 34.10-2012 public
>   key with 256 bits private key length algorithm and Parameter set A.
> 
> Perhaps:
>   The OIDs in the structure above represent a GOST R 34.10-2012 public
>   key with a 256-bit private key length and parameter set A.
> 
> For comparison, we note that similar text in RFC 9215 does not include 
> the word "algorithm":
>   GOST R 34.10-2012 public keys with a 512-bit private key length are
>   identified by the following OID:
> 
> 
> Also, would you like to add "parameter set A" in Section 2 as follows,
> so that the reader knows what Section 2.1 is referring to?
> 
> Original:
>   We select the parameters for the digital signature
>   algorithm to be id-tc26-gost-3410-2012-256-paramSetA as specified in
>   RFC 7836 [RFC7836].
> 
> Perhaps:
>   We select the parameters for the digital signature
>   algorithm to be id-tc26-gost-3410-2012-256-paramSetA as specified in
>   RFC 7836 [RFC7836]; this document refers to it as "parameter set A".
> -->
> 
> 
> 5) <!--[rfced] FYI, the placement of the line break was altered so that the 
> example would fit the line-length limitation without the removal of the 
> left-hand indentation. Please let us know if you prefer otherwise.
> 
> Original:
> Private-key-format: v1.2
> Algorithm: TBA1 (ECC-GOST12)
> Gost12Asn1: MD4CAQAwFwYIKoUDBwEBAQEwCwYJKoUDBwECAQEBBCD/Mw9o6R5lQHJ13jz0
>            W+C1tdsS4W7RJn04rk9MGJq3Hg==
> 
> Current:
>   Private-key-format: v1.2
>   Algorithm: 23 (ECC-GOST12)
>   Gost12Asn1: MD4CAQAwFwYIKoUDBwEBAQEwCwYJKoUDBwECAQEBBCD/Mw9o6R5lQHJ13
>               jz0W+C1tdsS4W7RJn04rk9MGJq3Hg==
> -->
> 
> 
> 6) <!-- [rfced] RFC 5208 has been obsoleted by RFC 5958.  May we replace 
> the informative reference RFC 5208 with RFC 5958? If so, what section
> number should be used?
> 
> Original:
>   The private key here is presented in PrivateKeyInfo ASN.1 structure,
>   as described in RFC5208 [RFC5208], Section 5.
> -->
> 
> 
> 7) <!--[rfced] Regarding your note below, the numbers 23 and 5 were assigned, 
> so it does not seem that recalculation is needed. Please review.
> 
> Original:
>   [RFC Editor note: Note: Algorithm numbers 23 and 5 are used as an
>   example in this document, as actual numbers have not yet been
>   assigned.  If the assigned values will differ, the example keys and
>   signatures will have to be recalculated before the official
>   publication of the RFC.]
> -->
> 
> 
> 8) <!--[rfced] Vasily, regarding the postal address, is it necessary
> to list your organization twice, or may the second instance be removed?
> Also, may we update to typical abbreviations for building (Bldg.) 
> and street (St.)?
> 
> Original:
>   Vasily Dolmatov (editor)
>   JSC "NPK Kryptonite"
>   Spartakovskaya sq., 14, bld 2, JSC "NPK Kryptonite"
>   Moscow
>   105082
> 
> Perhaps:
>   Vasily Dolmatov (editor)
>   JSC "NPK Kryptonite"
>   Spartakovskaya Sq., 14, Bldg. 2
>   Moscow
>   105082
> 
> Original:
>   8 marta str., 1, bld 12
> 
> Perhaps:
>   8 Marta St., 1, Bldg. 12
> -->
> 
> 
> Thank you.
> 
> RFC Editor/ar
> 
> 
> On Mar 7, 2024, [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.