Subject: Re: [Last-Call] Last Call: Moving RFC 4491 to Historic

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Jan 2022 08:47:00 +1300

Naive question:

RFC 4491 (currently a PS) formally updates RFC 3279 (also a PS). How will a reader of RFC 3279 in future know that they need to look at RFCxxxx ("a new document being
progressed in the Independent Submission Stream")? Will RFC 4491 receive an "Obsoleted by" tag?

Regards
    Brian Carpenter

On 08-Jan-22 06:08, The IESG 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-to-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
> [email-masked] mailing lists by 2022-02-04. Exceptionally, comments may
> be sent to [email-masked] 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-to-historic/ballot/
> 
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 07 Jan 2022 15:22:06 -0500

Brian,

Thank you for opening the can of worms.  Watch for a more detail
discussion of several of what emerged (not just this issue) that
I've been working on for a couple of hours soon.

best,
   john

--On Saturday, January 8, 2022 08:47 +1300 Brian E Carpenter
<[email-masked]> wrote:

> Naive question:
> 
> RFC 4491 (currently a PS) formally updates RFC 3279 (also a
> PS). How will a reader of RFC 3279 in future know that they
> need to look at RFCxxxx ("a new document being
>> The IESG has received a request from an individual
>> participant to make the following status changes:
>> 
>>      (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 IESG plans to make a decision in the next few weeks, and
>> solicits final comments on this action. Please send
>> substantive comments to the [email-masked] mailing lists
>> by 2022-02-04. Exceptionally, comments may be sent to
>> [email-masked] instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>

---

From: John C Klensin <[email-masked]>
Date: Fri, 07 Jan 2022 15:40:55 -0500

Hi.

I don't think I have a problem with this but it does seem to
raise multiple other issues including the one Brian Carpenter's
identified (this note was started a few hours before his
arrived).  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)?   Hence a few questions,
all mostly out of curiosity as well as a bit of concern that, if
we are changing any precedents, we do so explicitly and not by
side-effect and do not leave loose ends. 

(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?

(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 :-(

(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.

...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).

(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.  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.  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".

Assuming the IESG does not just pause this document waiting for
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).

best,
   john

--On Friday, January 7, 2022 09:08 -0800 The IESG
<[email-masked]> wrote:

> 
> The IESG has received a request from an individual participant
> to make the following status changes:
> 
>     (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

---

From: Russ Housley <[email-masked]>
Date: Fri, 7 Jan 2022 16:20:30 -0500

It looks like draft-deremin-rfc4491-bis is in the works to replace RFC 4491.  Why is this action needed before the bis is approved to replace it?

Russ

> On Jan 7, 2022, at 2:47 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Naive question:
> 
> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: Василий Долматов <[email-masked]>
Date: Sat, 8 Jan 2022 08:52:11 +0300

> 8 янв. 2022 г., в 00:20, Russ Housley <[email-masked]> написал(а):
> 
Moreover, consider https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/ <https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/>

"However, the only instructions in 2026 for its use are in section 6, and those are to move full "Internet Standard" status documents to "Historic" status, thereby "retiring" the technology in the standard. This differs from the "Obsoletes:" header that is put on documents as per RFC 2223. The "Obsoletes:" header indicates a replacement version of the same technology, rather than a retirement of the technology itself. Using "Obsoletes:" is simply a matter of indicating this in the header of the RFC. Moving a document to "Historic" status requires a specific IETF-wide Last Call and a formal action of the IESG.»

Header  «Updated» or «Obsoleted» is definitely more appropriate in this case.

Proposition for assigning of «Historic» header must be elaborated to fit the scope IESG statement of «retiring _the_technology_ itself».

Current proposition contains nothing except reference to the deprecation of usage of given algorithms in the
«systems presented for certification» in the given certification system. 

There are a number of algorithms in IETF documents database with the same current status of being deprecated for usage in certified systems, but none of them is being attempted to assign a «Historic» header in IETF (cf. MD5, SHA-1, etc.).

I think that more  consistent approach to usage of this header should be developed, and «shortcut» procedure #1 from the quoted statement of assigning it should be considered the first candidate for applying it <grin>. ;)

dol@

---

From: Adrian Farrel <[email-masked]>
Date: Sat, 8 Jan 2022 08:41:33 +0000 (GMT)

Hi, just chiming in to say draft-deremin-rfc4491-bis does not obsolete RFC 4491 (that would involve crossing the streams) or in any way mention RFC 4491 (except in the slightly confusing file name that is a legacy of an early version of the draft).

draft-deremin describes how to use the latest versions of the GOST algorithms in conjunction with IETF specifications and practices. It makes no comment on previous versions of GOST algorithms.

RFC 4491 is the product of the IETF stream. In discussion with one of the SEC ADs it was determined that it would also be useful to make the RFC Historic as it refers to a set of algorithms that have been withdrawn by their original publisher and that are strongly deprecated on security grounds. In order to help facilitate that, the ISE and the draft author invented some text for last call announcement and gave it to the AD, however the choice of words and the decision to call to mark 4491 Historic is an IESG action that requires IETF consensus.

If there is any need to order the publication of draft-deremin ad an RFC and the status change of RFC 4491, I am unaware of it.

Best,

Adrian (as ISE but from my personal email account)

On 07/01/2022 21:20 Russ Housley <[email-masked]> wrote:

Russ

Naive question:

Regards

Brian Carpenter

and CRL Profile)

[email-masked]

--

last-call mailing list

[email-masked]

--

last-call mailing list

[email-masked]

---

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Sat, 8 Jan 2022 17:37:07 -0000

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
> issues can be sorted out (see below)?

I see no harm in waiting given the time frame.

> 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.

> 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.

> 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).

> "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 &#128522;

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...

> Stream Informational.

Maybe precedent is not always a good guide to what we should next time
around?

> Especially when there are interactions
> 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

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?

> 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),
[email-masked]

>> https://datatracker.ietf.org/doc/status-change-old-gost-pkix-t
>> o-historic/ballot

---

From: John C Klensin <[email-masked]>
Date: Sat, 08 Jan 2022 12:37:06 -0500

--On Friday, January 7, 2022 16:20 -0500 Russ Housley
<[email-masked]> wrote:

> It looks like draft-deremin-rfc4491-bis is in the works to
> replace RFC 4491.  Why is this action needed before the bis is
> approved to replace it?

Russ, as discussed in my rather long analysis (somewhat
reinforced by Vasiliy's (I hope that transliteration if correct,
if not, apologies) and Adrian's notes), this is a bit of a
tangle involving RFC 3279.   Very briefly, up to some point, the
practice was to publish specifications that extended the list in
3279 is Proposed Standards updating 3279.  Presumably, if those
extension specifications were replaced, they would simply
obsolete the earlier versions and the lists of updates to 3279
adjusted to reflect the new versions.  For better or worse, that
showed the relationships very clearly.  

More recently, at least for the relevant GOST specs, the
practice has apparently shifted to publishing them as
Informational in the Independent stream.  It is not clear to me
why that shift occurred (if it is documented somewhere, I have
not been able to find it) but, as Adrian points out, one
implication is that having the new document replace (aka
"obsolete") 4491 would involve some cross-stream issues.  As
Adrian also points out, one way out is not to have the I-D
"replace" 4491 at all and rather to independently kill off 4491
by making it Historic.  I think that is just a way to confuse
people and assume the inter-Stream problems could be overcome
with a little bit of effort.  However, listing an Informational
document from outside the IETF Stream as updating RFC 3279 would
be, I think, much more complicated in spite of its being, as
Vasiliy points out, obviously The Right Thing to do.  

So, it seems to me that a delay in this action is desirable but
not sufficient and that we have some sorting out to do... and
that we should start with 3279, figure out what the Right Thing
is, and then how to make it happen.

best,
  john

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 8 Jan 2022 18:11:14 +0000

>    Will someone pick up 4491 by mistake? I hugely doubt it

    Independent Stream

As someone who has been involved with implementations of national crypto standards for years (I helped the GOST implementors get re-sync'd with OpenSSL, and played a part in getting SM2/3/4 documented in the IETF and implemented in OpenSSL), I just want to say that it is my view that the views of Adrian quoted above are exactly right.

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 8 Jan 2022 18:19:16 +0000

practice has apparently shifted to publishing them as
    Informational in the Independent stream.

They are also sometimes published because specification, or standard, exists outside of the IETF, and the IETF cryptography community prefers items published by the IETF, rather than external documents that might change or are located behind a paywall, are in a language other than English, etc. CFRG has documented things before (RFC 9106 and 7748 come to mind), and Simon Joseffson [1] has been notably active in doing this kind of thing.

I recall discussions about doing this taking place at various TLS and CFRG meetings, but I have no idea if a policy is written down anywhere.  I'm sure it's not.

[1] https://datatracker.ietf.org/person/Simon%20Josefsson

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 9 Jan 2022 11:46:24 +1300

> As someone who has been involved with implementations of national crypto standards for years (I helped the GOST implementors get re-sync'd with OpenSSL, and played a part in getting SM2/3/4 documen…

Yes, but neither labelling 4491 "Historic" (rather than both "Historic" and "Obsoleted By", nor updating RFC 3279, solves the problem of how an implementor of RFC 3279 is to find the current list of algorithms that are valid/deprecated/forbidden.

In some ways that is an orthogonal problem, but relying on all implementors to be attentive readers of the relevant IETF mailing lists is not a solution.

Within our current practices, RFC3279bis establishing an IANA registry
of algorithms might be one solution.

     Brian

---

From: John C Klensin <[email-masked]>
Date: Sat, 08 Jan 2022 19:49:45 -0500

--On Sunday, January 9, 2022 11:46 +1300 Brian E Carpenter
<[email-masked]> wrote:

>>      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
>> 
>> As someone who has been involved with implementations of
>> national crypto standards for years (I helped the GOST
>> implementors get re-sync'd with OpenSSL, and played a part in
>> getting SM2/3/4 documented in the IETF and implemented in
>> OpenSSL), I just want to say that it is my view that the
>> views of Adrian quoted above are exactly right.
> 
> Yes, but neither labelling 4491 "Historic" (rather than both
> "Historic" and "Obsoleted By", nor updating RFC 3279, solves
> the problem of how an implementor of RFC 3279 is to find the
> current list of algorithms that are valid/deprecated/forbidden.
> 
> In some ways that is an orthogonal problem, but relying on all
> implementors to be attentive readers of the relevant IETF
> mailing lists is not a solution.
> 
> Within our current practices, RFC3279bis establishing an IANA
> registry of algorithms might be one solution.

Yes.  Or, the more I think about it, the more I like the idea of
an Applicability Statement that could slightly update 3279 (or
be incorporated into an update) and, perhaps in conjunction with
such a registry, start distinguishing between things the IETF
Recommends (endorses, encourages the use of), those about which
we have little opinion but believe the community should have
information about, and those that we have looked at and believe
are obsolescent, dangerous now and going forward, etc.   It
would not be hard to write IANA Considerations or other text for
such a document that would make it easy for any national or
international standard to make it into the registry (we could
decide whether English translation was a requirement) but to
require some sort of IETf action to annotate the registry entry
with a recommendation status) 

And that would get us out of the hole we seem to be digging (and
that you and I have identified in different ways) rather than
digging ourselves in deeper).

   john

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 9 Jan 2022 01:57:11 +0000

>    Yes, but neither labelling 4491 "Historic" (rather than both "Historic" and "Obsoleted By", nor updating RFC 3279, solves the problem of how an implementor of RFC 3279 is to find the current lis…

They will be consulting Russian specifications, not IETF documents.

>    In some ways that is an orthogonal problem, but relying on all implementors to be attentive readers of the relevant IETF mailing lists is not a solution.

It is *completely* an orthogonal problem. No version of GOST, Streebog, etc., is required by any IETF standard.

In a separate message on this thread, John wrote

>  and going forward, etc.   It would not be hard to write IANA Considerations or other text for such a document that would make it easy for any national or international standard to make it into the registry (we could decide whether English translation was a requirement) but to require some sort of IETf action to annotate the registry entry with a recommendation status)

The issue is not as simple as the above implies. National standards (Russian GOST, Chinese SM2/3/4, Korean SEED or Aria, etc) tend to be written in their own language. Requiring English adds a burden, especially when it's translating cryptographic work; while it makes sense for IETF documents, who is going to do the work to get high-quality accurate English translations, and for what purpose?  The "recommendation status" suggestion is another potential minefield. The TLS WG spent a lot of time refining the "recommended" column for ciphers (it now says YES or NO-ANSWER), and is looking at revising it again, now. As one of the three designated experts of those registries, I would HATE for us to put anyone other than IETF Consensus in charge of making that recommendation. Certainly IANA is not competent to do so.

---

From: John C Klensin <[email-masked]>
Date: Sat, 08 Jan 2022 21:15:52 -0500

--On Sunday, January 9, 2022 01:57 +0000 "Salz, Rich"
<[email-masked]> wrote:

>>  and going forward, etc.   It would not be hard to write IANA
>>  Considerations or other text for such a document that would
>>  make it easy for any national or international standard to
>>  make it into the registry (we could decide whether English
>>  translation was a requirement) but to require some sort of
>>  IETf action to annotate the registry entry with a
>>  recommendation status)

> The issue is not as simple as the above implies. National
> standards (Russian GOST, Chinese SM2/3/4, Korean SEED or Aria,
> etc) tend to be written in their own language. Requiring
> English adds a burden, especially when it's translating
> cryptographic work; while it makes sense for IETF documents,
> who is going to do the work to get high-quality accurate
> English translations, and for what purpose?  The
> "recommendation status" suggestion is another potential
> minefield. The TLS WG spent a lot of time refining the
> "recommended" column for ciphers (it now says YES or
> NO-ANSWER), and is looking at revising it again, now. As one
> of the three designated experts of those registries, I would
> HATE for us to put anyone other than IETF Consensus in charge
> of making that recommendation. Certainly IANA is not competent
> to do so.

Please read what I wrote.  To repeat in different language:

* Any national cryptograph standard should make it into the
registry associated with RFC 3279, _without_ any inherent
recommendation status.

* I was talking only about 3279.  Whether that should apply to
TLS, or that TLS should use the same registry, is an entirely
separate question.

* The question of whether an English translation should be
required (for registration, just for positive (or positive and
negative) recommendations, or neither) would be a decision to be
made by the IETF in specifying such a registry. (For reasons
similar to the ones you give, I would personally recommend
against it, certainly for anything but the "recommended" ones.)

* The use of "RECOMMENDED" and "NOT RECOMMENDED" for an
Applicability Statement comes straight out of RFC 2026, not
anything associated with TLS or any recent set of specific
specs.  And because Applicability Statements are Standards Track
documents, the _only_ way those assignments can be made is by
IETF Consensus.

In addition, given that documents have recently been published
saying "stop using that, it is obsolete" for TLS, if the TLS
registry does not have provision for something equivalent to
"NOT RECOMMENDED" in addition to "YES" and "NO ANSWER", then I
suggest the revision effort should be considering that if it is
not already.

So I think that probably we are in complete agreement.  If we
are not, one of us is seriously confused.

best,
   john

---

From: Василий Долматов <[email-masked]>
Date: Sun, 9 Jan 2022 17:33:29 +0300

> 8 янв. 2022 г., в 21:19, Salz, Rich <rsalz=[email-masked]> написал(а):
> 
> They are also sometimes published because specification, or standard, exists outside of the IETF, and the IETF cryptography community prefers items published by the IETF, rather than external documents that might change or are located behind a paywall, are in a language other than English, etc.

Yes, that was exactly the reason for publishing _algorithms_ as Informational RFCs. To have a source of information and reference.

The implementation of these algorithms in given protocols - is quite different thing,

IMO it should go through ordinary way (and use algorithm description Informational RFC as a reference), so I wonder a way 4491bis goes,..

In any case this has no relation to the questions I asked before. I repeat it in other words:

 - why it was suddenly requested to put «Historic» label on one given algorithm, without any attempt to make «historic»  other algorithms, which deserves it much more for decades.
 - why the procedure exists which makes possible to start the process of labelling «Historic» something by request of some anonymous «participant» with one paragraph «rationale».

dol@

> CFRG has documented things before (RFC 9106 and 7748 come to mind), and Simon Joseffson [1] has been notably active in doing this kind of thing.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 9 Jan 2022 14:54:14 +0000

This was the point I missed.  (And I was only using TLS registry as an example with which I am familiar)

Yes, this is under discussion.

We seem to be yes.  Good. Probably my confusion.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 9 Jan 2022 17:16:28 -0000

Hi,

> - Why it was suddenly requested to put «Historic» label on one given
>   algorithm, without any attempt to make «historic»  other algorithms, 
>  which deserves it much more for decades.

I don't believe there is a request to mark an algorithm as historic, just to mark an RFC that described how to use the algorithm as historic because another body that owns the algorithm has replaced it.

Why that should come now is because "it was noticed" while producing draft-deremin-rfc4491-bis that the old algorithms were no longer approved by their issuing body.

Why other RFCs that use or describe the use of other algorithms are not marked as historic might be because no one has asked for them to be marked as historic. It turns out that this is not hard to do, but someone has to ask.

> - why the procedure exists which makes possible to start the process
>   of labelling «Historic» something by request of some anonymous
>  «participant» with one paragraph «rationale».

I think you may have misunderstood the process and the history here.

The draft authors observed that some algorithms were no longer approved for use by their originating body.
The AD said, in that case we should mark 4491 as historic.
The draft authors (along with the ISE) drafted some text for the AD to use if he wanted to.
The AD issued a call to make 4491 historic.

It is really a significant misstatement to suggest that a request was made by any participant, let alone an anonymous one.

However, yes, the procedure exists by which anyone can make an observation or request to the AD for an RFC to be moved to Historic. However, it is then up to the AD to craft a "status change document" and issue a last call. The community is then free to object to the change citing any reasonable reason (including that insufficient rationale was provided).

Cheers,
Adrian

---

From: Василий Долматов <[email-masked]>
Date: Sun, 9 Jan 2022 20:31:08 +0300

> 9 янв. 2022 г., в 20:16, Adrian Farrel <[email-masked]> написал(а):
> 
> Hi,
> 
That is new information. IESG announcement  referred to some «participant» not referring to AD.
If it was an AD, I think that elaborated statement could be issued by AD with explanation why this very update of algorithm strictly demands marking its predecessor as «historic», while no other cases (SSL vs TLS, MD5& SHA-1 vs new hashes) followed that way.
 
> However, yes, the procedure exists by which anyone can make an observation or request to the AD for an RFC to be moved to Historic. However, it is then up to the AD to craft a "status change docume…
IESG statement quoted by me contained _three_ options.
 I fully agree with processes described in options #2 & #3 and with your description (which, in fact coincides with #2&#3 options), the only question from me was about option #1, which seems arbitrary and unappropriate.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 10 Jan 2022 16:26:21 -0800

Hello,
>The supporting document for this request can be found here:

The announcement does not mention who requested the status 
change.  Would it be possible to disclose that information?

GOST R 34.11-94 is no longer recommended for maintaining 
compatibility since 2018.  The hash function algorithm 
(informational) specification was neither obsoleted nor reclassified 
as Historic.  Should the specification be reclassified too?

The "document" to support the request does not contain much 
information to form an opinion about the status reclassification 
request.  Could the IESG please consider providing moreinformation, 
e.g. who forbid the use of 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?

Regards,
S. Moonesamy