Re: BCP97bis and Informational-as-Standard

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 16 October 2021 20:38 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7518F3A0CB7 for <ietf@ietfa.amsl.com>; Sat, 16 Oct 2021 13:38:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNr4PUC7CBnI for <ietf@ietfa.amsl.com>; Sat, 16 Oct 2021 13:38:38 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2292A3A0CB5 for <ietf@ietf.org>; Sat, 16 Oct 2021 13:38:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id AF180181A3; Sat, 16 Oct 2021 16:39:02 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id j7-4mYWNLTyB; Sat, 16 Oct 2021 16:39:02 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1124A1808D; Sat, 16 Oct 2021 16:39:02 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CB846236; Sat, 16 Oct 2021 16:38:35 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Russ Housley <housley@vigilsec.com>, "Murray S. Kucherawy" <superuser@gmail.com>, IETF <ietf@ietf.org>
Subject: Re: BCP97bis and Informational-as-Standard
In-Reply-To: <C657F78F-FF99-4898-8A08-844B32589DDE@vigilsec.com>
References: <CAL0qLwbwvs2Cp_urgJ=hzc6yEMGDaz3C0xf6RQXRrB89wAx=Rw@mail.gmail.com> <CAL0qLwavK5dYdmYPVxdMT5rA=jBZv1cEyAsVBEWOD7p9MoZR1g@mail.gmail.com> <C657F78F-FF99-4898-8A08-844B32589DDE@vigilsec.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 16 Oct 2021 16:38:35 -0400
Message-ID: <18086.1634416715@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/077oxz6E32IeotzOakRzyTe9R6Y>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Oct 2021 20:38:44 -0000

Russ Housley <housley@vigilsec.com> wrote:
    > I have on concern and a few editorial suggestions.


    > CONCERN

    > Section 4.1 says:

    } o  A note is included in the reference text that indicates that the
    } reference is to a target document of a lower maturity level, that
    } some caution should be used since it may be less stable than the
    } document from which it is being referenced, and, optionally,
    } explaining why the downref is appropriate.

    > There are many cases where cryptographic algorithms are specified in
    > Informational RFC, and then a Standards-Track document is used to
    > specify protocol conventions for using that algorithm.  the algorithm
    > specification is not unstable, and requiring a note like this sends the
    > wrong message to the reader.

I think that this is really a process/RFC2026 process bug that maybe we could
find a way to slightly amend RFC2026 about.  (How many gendispatches ago was
the 2026 revision discussion...?)

I think that we document cryptographic algorithms as Informational because it
is not the IETF's goal to take change control over the algorithm.
It's not that we don't think of them as Standards-Track, it's that our
standards track rules say that can't unless we have change control.
The IETF RFC, because it's accessibility, often become the defacto industry
reference.   It is cited way beyond being cited in some other RFC.

Why doesn't the industry (and the IETF?) cite the original NIST,
etc. document?  Well, historically, because the documents predate the WWW, we
had RFC-by-FTP-email, and NIST didn't.

My thoughts are:

a) create some new category which is pseudo-authoritative standards track,
   which the IESG can annoit a document with.
b) cite the original documents/papers/NIST-etc. publications more often.

Perhaps CFRG has already struggled with this question before.
At this point, what I see is that there is significant original work being
brought to the CFRG *first*, that a CFRG RFC is becoming authoritative for
some algorithms. (No, I don't have an example.)





--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide