Dear IANA,

Please make the following update to match the edited document at 
https://www.rfc-editor.org/authors/rfc9906-diff.html.

Under the "Digest Algorithms” registry 
<https://www.iana.org/assignments/ds-rr-types>:

OLD:
   GOST R 34.11-94 

NEW:
   GOST R 34.11-94 (DEPRECATED)

Thank you!

Karen Moore
RFC Production Center
 

> On Nov 5, 2025, at 11:58 AM, Karen Moore <[email protected]> wrote:
> 
> Hi Wes,
> 
> We have noted your approval on the AUTH48 status page 
> (https://www.rfc-editor.org/auth48/rfc9906).
> 
> We will now ask IANA to update the "Digest Algorithms” registry to reflect 
> “DEPRECATED” for "GOST R 34.11-94” (to match "GOST R 34.10-2001 
> (DEPRECATED)") . We will inform you when the update is complete.
> 
> Best regards,
> 
> Karen Moore
> RFC Production Center
> 
>> On Nov 5, 2025, at 3:13 AM, Wes Hardaker <[email protected]> wrote:
>> 
>> Karen Moore <[email protected]> writes:
>> 
>>> Thank you for your replies.  We have updated our files accordingly;
>>> please review.  We noted Warren’s approval of the document on the
>>> AUTH48 status page. We now await approval from Wes.
>> 
>> Looks good to go thank you very much!
>> -- 
>> Wes Hardaker
>> Google
> 
> 
>> On Nov 4, 2025, at 5:13 PM, Karen Moore <[email protected]> wrote:
>> 
>> Hi Wes and Warren,
>> 
>> Thank you for your replies.  We have updated our files accordingly; please 
>> review.  We noted Warren’s approval of the document on the AUTH48 status 
>> page. We now await approval from Wes.
>> 
>> --Files--
>> Note that it may be necessary for you to refresh your browser to view the 
>> most recent version. Please review the document carefully to ensure 
>> satisfaction as we do not make changes once it has been published as an RFC.
>> 
>> Updated XML file:
>> https://www.rfc-editor.org/authors/rfc9906.xml
>> 
>> Updated output files:
>> https://www.rfc-editor.org/authors/rfc9906.txt
>> https://www.rfc-editor.org/authors/rfc9906.pdf
>> https://www.rfc-editor.org/authors/rfc9906.html
>> 
>> Diff files showing all changes made during AUTH48:
>> https://www.rfc-editor.org/authors/rfc9906-auth48diff.html
>> https://www.rfc-editor.org/authors/rfc9906-auth48rfcdiff.html (side by side)
>> 
>> Diff files showing all changes:
>> https://www.rfc-editor.org/authors/rfc9906-diff.html
>> https://www.rfc-editor.org/authors/rfc9906-rfcdiff.html (side by side)
>> 
>> For the AUTH48 status of this document, please see:
>> https://www.rfc-editor.org/auth48/rfc9906
>> 
>> Best regards,
>> 
>> Karen Moore
>> RFC Production Center
>> 
>> 
>>> On Nov 4, 2025, at 12:49 PM, Warren Kumari <[email protected]> wrote:
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Tue, Nov 04, 2025 at 12:22 PM, Wes Hardaker <[email protected]> wrote:
>>> [email protected] writes: 
>>> Greetings, below inline are my thoughts. Thanks for all the help! 
>>> 1) <!--[rfced] We have updated the short title that spans the header of the 
>>> PDF file to more closely match the title. Please let us know of any 
>>> objection. 
>>> Original: 
>>> MUST NOT DNSSEC with ECC-GOST 
>>> Current: 
>>> Deprecate Usage of ECC-GOST 
>>> --> 
>>> Agreed, thank you.
>>> 
>>> 
>>> Yup, seems fine. 
>>> 
>>> 
>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the 
>>> title) for use on https://www.rfc-editor.org/search. 
>>> --> 
>>> I propose these: DNS, DNSSEC, GOST, algorithm, rollover, agility
>>> 
>>> 
>>> Warren snarkily points at "(beyond those that appear in the title)" :-) 
>>> 
>>> 
>>> 3) <!--[rfced] This document discusses no longer using the GOST R 
>>> 34.10-2001 and GOST R 34.11-94 algorithms but only "GOST R 34.10-2001" is 
>>> mentioned in the first sentence of the Abstract. Is that intended, or 
>>> should GOST R 34.11-94 also be included? 
>>> Original: 
>>> This document retires the use of GOST R 34.10-2001 (mnemonic "ECC- GOST") 
>>> within DNSSEC. 
>>> Perhaps: 
>>> This document retires the use of GOST R 34.10-2001 (mnemonic "ECC- GOST") 
>>> and GOST R 34.11-94 within DNSSEC. 
>>> --> 
>>> I agree that referencing both is correct. I need to speak with Warren to 
>>> double check this though.
>>> 
>>> ¯\_(ツ)_/¯. I believe that the current wording was chosen because GOST 94 
>>> was already retired (I believe by 2001) and so this doesn't doesn't 
>>> **really** do the above. But it does seem helpful to the reader, so even if 
>>> it is not technically 100% right it seems good…. 
>>> 
>>> 
>>> 
>>> 
>>> 4) <!--[rfced] We note that this document does not "update" RFC 5933 but 
>>> rather moves it to Historic status. For clarity, may we update the Abstract 
>>> to reflect this as shown below? 
>>> My understanding is that RFC5933 is already historic, so our document 
>>> doesn't make it so -- we're only making the IANA registries match the 
>>> status (and stating that it should not be used).
>>> 
>>> Thus the current text is right: 
>>> Current: 
>>> RFC 5933 (now historic) defined the use of GOST R 34.10-2001 and GOST R 
>>> 34.11-94 algorithms with DNS Security Extensions (DNSSEC). This document 
>>> updates RFC 5933 by deprecating the use of ECC-GOST. 
>>> Though we could remove "now" to take away any confusion that it's this 
>>> document that is making it historic.
>>> 
>>> Yup. This whole situation is complicated, but Wes is correct… 5933 is 
>>> already historic, so we are updating a historic doc…which is weird, but…  
>>> Removing "now" seems helpful… 
>>> 
>>> 
>>> 
>>> 5) <!--[rfced] This sentence reads oddly as it sounds like the DNS Security 
>>> Extensions were documented in RFC 5933 yet there is a reference to RFC 
>>> 9364. For clarity, may we rephrase this as shown below? 
>>> [...] 
>>> Perhaps: 
>>> The GOST R 34.10-2001 and GOST R 34.11-94 algorithms are documented in 
>>> [RFC5933] and their use with DNS Security Extensions (DNSSEC) is further 
>>> described in [RFC9364]. 
>>> Looks good!
>>> 
>>> 
>>> +1!
>>> 
>>> 
>>> 6) <!--[rfced] Would it be clearer to include the descriptive name "GOST R 
>>> 34.10-2001" (instead of the mnemonic "ECC-GOST") here for clarity? We ask 
>>> because "GOST R 34.11-94" was used in the previous paragraph. 
>>> [...] 
>>> Perhaps: 
>>> The GOST R 34.10-2001 algorithm [RFC5933] MUST NOT be used when creating 
>>> DNS Public Key (DNSKEY) and Resource Record Signature (RRSIG) records. 
>>> Validating resolvers MUST treat RRSIG records created from DNSKEY records 
>>> using this algorithm as an unsupported algorithm. 
>>> Looks good!
>>> 
>>> Errrrr… I disagree — the IANA registry calls it "ECC-GOST", and we want it 
>>> to be clear that that is the one that is being deprecated. We saw many 
>>> instances where people (including ourselves!) got confused by the 
>>> similarity of the strings "GOST R 34.10-2001" and "GOST R 34.10-2012".
>>> 
>>> Perhaps:
>>> "The GOST R 34.10-2001 algorithm [RFC5933] (mnemonic "ECC-GOST ") MUST NOT 
>>> be used…"
>>> Or something… 
>>> 
>>> Note: This is not a hill I'm willing to die on. I approve publication 
>>> whatever y'all decide...
>>> 
>>> 
>>> 7) <!--[rfced] Section 5. For clarity, may we update this text to reflect 
>>> all of IANA's updates? Also, should "DEPRECATED" be added to the 
>>> Description column for "GOST R 34.11-94" (to match the entry for 
>>> "GOST R 34.10-2001 (DEPRECATED)") as shown below? 
>>> [...] 
>>> Perhaps: 
>>> [.......] 
>>> Yep, I am fine with that (and matches what you suggested for sha1 too).
>>> 
>>> +1.
>>> 
>>> 
>>> 8) <!-- [rfced] FYI: We updated the reference entries for the IANA 
>>> registries to reflect the names of the registries rather than the registry 
>>> group names to match the running text. Please let us know of any objection. 
>>> Sounds good, thank you.
>>> 
>>> 
>>> Also +1. 
>>> 
>>> 
>>> 9) <!--[rfced] Since most of the names in the Acknowledgments were in 
>>> alphabetical order, we reordered a few names so that the full list is now 
>>> in alphabetical order. If this is not desired, please let us know. 
>>> Good idea, thank you.
>>> 
>>> 
>>> Yah! 
>>> 
>>> 
>>> 10) <!-- [rfced] FYI - To match the companion documents, we have added 
>>> expansions for the following abbreviations per Section 3.6 of RFC 7322 
>>> ("RFC Style Guide"). Please review these and each expansion in the document 
>>> carefully to ensure correctness. 
>>> DNS Public Key (DNSKEY) 
>>> Delegation Signer (DS) 
>>> Resource Record Signature (RRSIG) 
>>> Yep, also good.
>>> 
>>> 
>>> Yup!
>>> 
>>> 
>>> Thanks for the help!
>>> 
>>> +many lots!
>>> Thanks RFC Ed!
>>> 
>>> W
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Wes Hardaker 
>>> Google
>>> 
>> 
> 

-- 
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to