Re: [TLS] [Editorial Errata Reported] RFC8996 (7739)

Rebecca VanRheenen <rvanrheenen@amsl.com> Fri, 22 December 2023 06:01 UTC

Return-Path: <rvanrheenen@amsl.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503B1C14F5F7 for <tls@ietfa.amsl.com>; Thu, 21 Dec 2023 22:01:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level:
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InOTh95UbeRw for <tls@ietfa.amsl.com>; Thu, 21 Dec 2023 22:01:31 -0800 (PST)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4A8C14F610 for <tls@ietf.org>; Thu, 21 Dec 2023 22:01:31 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id B2014424B455; Thu, 21 Dec 2023 22:01:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-4XmK7z-ono; Thu, 21 Dec 2023 22:01:31 -0800 (PST)
Received: from [IPv6:2601:641:300:5fb0:9cb0:0:4ec8:6ed0] (unknown [IPv6:2601:641:300:5fb0:9cb0:0:4ec8:6ed0]) by c8a.amsl.com (Postfix) with ESMTPSA id 96B0A424B427; Thu, 21 Dec 2023 22:01:31 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Rebecca VanRheenen <rvanrheenen@amsl.com>
In-Reply-To: <20231222030238.C0E5219960D8@rfcpa.amsl.com>
Date: Thu, 21 Dec 2023 22:01:30 -0800
Cc: RFC Editor <rfc-editor@rfc-editor.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8C39118C-49D4-46E1-979B-FFF268BCA69F@amsl.com>
References: <20231222030238.C0E5219960D8@rfcpa.amsl.com>
To: Kathleen.Moriarty.ietf@gmail.com, Stephen Farrell <stephen.farrell@cs.tcd.ie>, tls@ietf.org
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/RKMGCxW6FDLVTyJm-Gkyj3U1C_o>
Subject: Re: [TLS] [Editorial Errata Reported] RFC8996 (7739)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Dec 2023 06:01:36 -0000

Greetings,

FYI - this report has been deleted as junk (identical text is listed in Original Text, Corrected Text, and Notes, and this text does not even appear in this RFC).

Thank you.

RFC Editor/rv


> On Dec 21, 2023, at 7:02 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC8996,
> "Deprecating TLS 1.0 and TLS 1.1".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7739
> 
> --------------------------------------
> Type: Editorial
> Reported by: mohamed abdurahman hassan <abdiamran65@gmail.com>
> 
> 96
> 
> Original Text
> -------------
> 
>   application.  The authorization server should take special care when
>   enabling this grant type and only allow it when other flows are not
>   viable.
> 
>   This grant type is suitable for clients capable of obtaining the
>   resource owner's credentials (username and password, typically using
>   an interactive form).  It is also used to migrate existing clients
>   using direct authentication schemes such as HTTP Basic or Digest
>   authentication to OAuth by converting the stored credentials to an
>   access token.
> 
> 
> Corrected Text
> --------------
> 
>   application.  The authorization server should take special care when
>   enabling this grant type and only allow it when other flows are not
>   viable.
> 
>   This grant type is suitable for clients capable of obtaining the
>   resource owner's credentials (username and password, typically using
>   an interactive form).  It is also used to migrate existing clients
>   using direct authentication schemes such as HTTP Basic or Digest
>   authentication to OAuth by converting the stored credentials to an
>   access token.
> 
> 
> Notes
> -----
> application.  The authorization server should take special care when
>   enabling this grant type and only allow it when other flows are not
>   viable.
> 
>   This grant type is suitable for clients capable of obtaining the
>   resource owner's credentials (username and password, typically using
>   an interactive form).  It is also used to migrate existing clients
>   using direct authentication schemes such as HTTP Basic or Digest
>   authentication to OAuth by converting the stored credentials to an
>   access token.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it 
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> will log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC8996 (draft-ietf-tls-oldversions-deprecate-12)
> --------------------------------------
> Title               : Deprecating TLS 1.0 and TLS 1.1
> Publication Date    : March 2021
> Author(s)           : K. Moriarty, S. Farrell
> Category            : BEST CURRENT PRACTICE
> Source              : Transport Layer Security
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG