在RFC中的过时风险有什么可以做些什么？

Question

rfc 2440 ，在1998年发布（那是十六年前< / EM>，据说在64位系统出现之前）。两种规格都讲述了如何处理时间戳的同一件事：

3.5

时间字段是包含该数字的无符号四八位字节编号 自午夜自1970年1月1日起午夜以来经过了几秒钟。

应该尝试尽可能地按照rfcs遵循（以及，在这里，面对一个甜蜜的年2038个错误一天）？对于开发商而言，它不会遵循标准/规格/ RFC的部分（尤其是在加密），当它们被视为可能已经过时时，是“危险”，当然已经过时了？

我有点害怕问，因为这个问题听起来很傻，但如果我“实施RFC 4880”但是在我自己的方式，这不是官方的。所以，开发人员应该对她所看到的东西所做的最好的事情是什么，因为规格的“过时”部分？没有？

Answer 1

首先：我认为问题中的示例是错误的。 RFC4880 使用 unsigned 32位整数。Y2K38问题是签名 32位整数的问题。根据维基百科的说法，未签名的32位整数在2106年之前工作。

回答你的问题： 我认为最好的方法是与RFC工作组/ RFC的作者联系并告诉他们过时。也许，后续RFC将解决该问题。

对于您的示例，我认为您可以避免联系OpenPGP WG。我想，直到2106将有很多更新，我怀疑v5键有8个八位字节的时间字段。