Hi, Replying to this one specifically because John rubbed the magic lamp and muttered my name... > If we have already waited two years since use was > "forbidden" and eight years since the relevant GOST specs were > deprecated, would harm be done by delaying this until those > issues can be sorted out (see below)? I see no harm in waiting given the time frame. > (1) I can guess, but who is doing the "forbidding" and is that > any more binding on potential users of international voluntary > standards or binding national standards outside that country > than a SDO requirement that something should be used? Should > that be reflected in the tracker notice? Weeeell, who can forbid anything on the Internet? So, perhaps, more context to this forbidding would have been better. It is probably (but don't quote me) that the use of these algorithms in Russian government infrastructure and associated public services in Russia is forbidden. > (2) Did the revised GOST standards and/or the deprecation or > "forbidding" actions provide technical explanations of why > continuing use of the specifications is a bad idea? If so, > should the documents containing that explanation be referenced > in the tracker notice and/or the ISE and authors of the new > document strongly encouraged (especially since IESG review seems > to be in progress -- see below) to include explanations and/or > references? Adrian, consider yourself encouraged :-( There are two very separate things here. 1. Should the Status Change notice (generated by the IESG) include more explanation or references? I think we are all free to encourage the IESG to collect this information and include it. 2. Should draft-deremin-rfc4491-bis make reference to the "deprecation" of the old algorithms? I think not - indeed, the original version of the draft did make that reference at a high level (hence the draft name), but since that: a. resulted in an Independent Submission changing the status of an IETF Stream document b. was not actually relevant to the purpose of *this* document ...I instructed the authors to remove all mention of RFC 4491. Sorry if the file name served to confuse anyone, but this isn't the first time a file name has not kept up with the content of a draft. For reference, *this* draft describes how to use the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms with the Internet X.509 Public Key Infrastructure. So it is similar to RFC 4491, but for a different set of algorithms. > (3) If there is a document "being progressed in the Independent > Submission Stream" (I assume, after a quick search, > draft-deremin-rfc4491-bis-10, now in IESG review), is there some > reason to not delay the action of this Last Call and > corresponding explanation until that document is approved and > assigned an RFC number (at least a pre-publication one) so that > RFC or other document can be cited? Since the I-D has not yet > been approved for publication, there is, at least in principle, > a possibility that it will never be published. In that case, > part of the explanation would become retroactively incorrect. Yes, it is *possible* that it will never be published, but I would be "disappointed". Is there harm to the delay? No. The move to Historic is needed, but as you say, it has already been two years. Is there value to the delay? I don't think so. This new document and RFC 4491 are independent. They have similar purposes, but apply to different algorithms. Will someone pick up 4491 by mistake? I hugely doubt it. An implementer will be looking out for how to implement a specific GOST algorithm with the X.509 PKI and so they will look for the RFC that mentions that algorithm. They will be responding to the environment for which they are implementing (which is the environment that has rendered 4491 historic). > ...Perhaps more important substantively and longer-term: > > (4) RFC 4491 is identified as updating RFC 3279. Given Brian's > question and multiple controversies on other lists (most > recently ART) that I would characterize as about the risk that > moving documents to Historic may leave other specifications that > they update or reference in confusing and/or silly states, has > that been considered? I believe it is not the case here and > that 4491 just added to the list of IETF-recognized algorithms > that should be included in the 3279 list. However, if that is > the case, should the explanation of this change explicitly > identify that? The collection of updates that add some > algorithms, deprecate or modify others, and move still others to > Historic without explicit metadata links from 3279 (see, e.g., > RFCs 6149 and 6151) and the similar collections for RFC 3121 > (itself referenced from 3279) appear to be creating a > hard-to-follow, spaghetti-threaded collection for 3279 that is > strongly reminiscent of the motivation for the NEWTRK ISD > proposal. Assuming the IESG is not inclined to reopen that > issue and proposal, is it time to replace 3279 with a version > that sorts the issues out and perhaps puts more reliance on a > registry of applicable specifications and/or an Applicability > Statement (see below)? Such an RFC3279bis could handle the > assorted new, Obsolete and Historic specs in a way that would > much more clearly define their status and role (including the > "IETF Endorsement" issue discussed below). You know how no-one knows what "Updates" means? It appears (to me) that RFC 4491 updated RFC 3279 only in the sense that it supplemented the list of algorithms. I don't think I would have considered that as an Update when I was on the IESG 😊 However, making a document Historic when it had previously made an "Update", surely just means that the "Update" is no more. The "IETF endorsement" is a whole different kettle of ballgames. But see below... > (5) When we publish references to, translations, or > explanations of documents from other standards bodies in the RFC > Series, I believe we have precedent for both publication as > Standards Track, IETF Stream Informational, and Independent > Stream Informational. Maybe precedent is not always a good guide to what we should next time around? > Especially when there are interactions > with Standards Track specifications, the decisions as to how to > treat them are normally made after due consideration by the > community. Such a decision was presumably made when RFC 4491 > was put on the standards track and as updating 3279. 2006 was a long time ago. The IESG evaluation record for RFC 4491 shows no Comments. The draft came through the PKIX working group. The IESG writeup shows... Initially this document was expected to be an Informational RFC, but when the PKIX WG Chair suggested that this document become a Standards Track RFC, there was no objection. Make of that what you like. > The > abstract of draft-deremin-rfc4491-bis-10, includes > > "This document does not imply IETF endorsement of the > cryptographic algorithms used in this document". > > While 4491 is a Proposed Standard, implying precisely that > endorsement of earlier versions of GOST R 34.10 and 34.11. If > the combination of this action and that document is intended to > actually deprecate recognition of these GOST specifications as > part of the RFC 3279 package, that feels like a Big Deal on the > IETF's part, not a simple move of an obviously obsolete > specification to Historic. Such a Big Deal clearly (at least to > me) needs documentation, especially if "we" have concluded that > the GOST specs are not technologically appropriate and should > not be recommended. Of source, RFC 2026 strongly implies that > attaching "Not Recommended" to a specification requires an > Applicability Statement. Those need IETF Last Call and RFC > publication. Such an A/S would be a reasonable alternative to > replacing 3279 and would perhaps be an even easier way to > explain the status of the assorted documents that have attached > themselves to it as "updates". I can't be definitive, but I suspect that the processing of 4491 did not consider the implication that the IETF was endorsing the specific GOST algorithms. Of course, we have moved forward a lot with crypto since those days and are much more careful about what the IETF endorses. > Assuming the IESG does not just pause this document waiting for "this document" is the Status Change document? Right? > either 3279 or that A/S for it and related documents, would it > not be more appropriate for the IESG to move 4491 from Standards > Track to Informational (explaining the reasons for downgrading > the lineage in the process) and then use draft-deremin-... to > explain how the GOST specs are used for those who choose to use > them despite not being part of the 3279 collection any more? Of > course, if draft-deremin-rfc4491-bis were published in the IETF > stream, those steps, including further updating 3729 if > appropriate, could be handed cleanly with a single Last Call (or > almost as cleanly by the ISE being given permission to obsolete > an IETF stream Informational document and then asking for an > advisory call on its approval). I think it is highly doubtful that the IETF would endorse the publication of draft-deremin-rfc4491-bis in the IETF Stream. I would be happy to be proved wrong, but I suspect that access to the research on the algorithms concerned is tricky, and the Crypto Review Team would say "unproven". While it might be nice to request that the authors of draft-deremin-rfc4491-bis include other material and so provide a document to somehow downgrade RFC 4491, that is not the purpose of his document and so you might have to exert some persuasion. In fact, I think that *if* the Status Change document is not considered adequate for this purpose, what is needed is a separate document, run through the IETF (possibly AD sponsored) that describes the history and technical reasons to deprecate RFC 4491. It is possibly that the authors of the present draft would step forward to do that. Or not. In case anyone is lacking access to a search engine, https://www.russiangost.com/p-65695-gost-r-3410-94.aspx is a useful indication that GOST R 34.10-94 is "not effective - superseded" (I presume that means "not in effect", but possibly there is some method in the choice of language!). I presume similar statements can be found for the other algorithms. There are plentiful search results giving explanations of the changes in the algorithms and hinting at reasons. Btw. No one has mentioned RFC 4490. I wonder about that. Coda: I think that only part of this thread is relevant to the ISE and the Independent Submissions Stream. That part is the progression of draft-deremin-rfc4491-bis, and I am unchanged in my opinion that that document is ready to be published as an Informational RFC in the Independent Stream. The IESG conflict review (https://datatracker.ietf.org/doc/conflict-review-deremin-rfc4491-bis/) completed its ballot yesterday (Thursday 7th January) and shows "The IESG has concluded that this work is related to IETF work done in WG LAMPS, but this relationship does not prevent publishing." The ballot shows no objections, but a few useful Comments that will be addressed in a new revision of the draft before it is passed to the RPC. If the IESG would like to put a hold on this document, they should speak up "SOON" [1] Cheers, Adrian [1] https://www.ietf.org/archive/id/draft-farrel-soon-07.txt -- Adrian Farrel (ISE), rfc-ise@xxxxxxxxxxxxxx > --On Friday, January 7, 2022 09:08 -0800 The IESG > <iesg-secretary@xxxxxxxx> wrote: > >> >> The IESG has received a request from an individual participant >> to make the following status changes: >> >> - RFC4491 from Proposed Standard to Historic >> (Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R >> 34.11-94 Algorithms with the Internet X.509 Public Key >> Infrastructure Certificate and CRL Profile) >> >> The supporting document for this request can be found here: >> >> https://datatracker.ietf.org/doc/status-change-old-gost-pkix-t >> o-historic/ >> >> The IESG plans to make a decision in the next few weeks, and >> solicits final comments on this action. Please send >> substantive comments to the last-call@xxxxxxxx mailing lists >> by 2022-02-04. Exceptionally, comments may be sent to >> iesg@xxxxxxxx instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> The affected document can be obtained via >> https://datatracker.ietf.org/doc/rfc4491/ >> >> IESG discussion of this request can be tracked via >> https://datatracker.ietf.org/doc/status-change-old-gost-pkix-t >> o-historic/ballot -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
