花了将近一年的时间，但 NIST 发布了此公告，解释了更新并提供了SP 800-52 修订版 1的更新文档。

您的问题的答案在公告中表达：

NIST 于 2005 年发布了 SP 800-52 的原始版本，但在 2013 年 3 月将其撤回，因为该指南尚未根据新版本的 TLS 和已知漏洞进行更新。这份新出版物是 SP 800-52 Rev. 1 的最终版本，其中包含对 2013 年秋季制定的草案版本的公众意见。

SP 800-52 中最主要的变化是政府服务器和客户端迁移到 TLS 1.1 和 1.2 的建议。它还建议他们采用具有 NIST 批准算法的密码套件，以支持 112 位和更高的安全强度。

更新：请参阅 Ryan Fisher 对这个问题的回答，SP800-52 第 1 版后来发布，它的大小是原始 2005 版本的两倍。它被撤回是因为它缺乏有关当代 TLS 版本和已知安全问题的信息（即防止误导，直到它可以更新）。

它不是“退休”（或“过期”），它是“撤回”，诚然是一个小的语义区别。NIST对此有以下概括性说明：

此页面包含已被更新的 SP 取代或不再受支持且未发布更新版本的已撤销特殊出版物 (SP) 的列表。

既然 是 没有（明显）的继任者，可以不再受支持。值得注意的是，它的存在理由现在已经不少于 17 年。

我建议主要动机是（选择性）消除一种或多种 3DES/TDEA、MD5（NIST长期以来不喜欢）或 SHA-1。官方声明是 3DES 在2015 年（或2030 年）之前都很好，TLSv1.1放弃了强制的TLSv1.0密码 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 支持 TLS_RSA_WITH_3DES_EDE_CBC_SHA，而TLSv1.2放弃了支持 TLS_RSA_WITH_AES_128_CBC_SHA。

TLSv1.0 之后的 TLS 版本仍然支持 MD5，但由于 SHA-1 已被弃用，并且今年出于某些目的必须离开，因此 TLSv1.1 及更高版本具有明显的优势，包括对 MD5/SHA-1 的依赖较少和更好的支持通过扩展的任意密码或散列函数。

（所以，CodesInChaos说了什么，但有更多的挥手、猜想和超链接 ;-)