¿Qué puede hacer contra los riesgos de obsolescencia en RFC?

Question

The RFC 4880 , un documento que describe la criptografía OpenPGP Estándar, encuentra sus raíces en RFC 2440 , publicado en 1998 (eso es hace dieciséis años < / em>, supuestamente antes de que surgieran los sistemas de 64 bits). Ambas especificaciones dicen lo mismo sobre cómo se manejan las marcas de tiempo:

3.5 . Campos de tiempo

Un campo de tiempo es un número de cuatro octetos sin firmar que contiene el número De segundos transcurridos desde medianoche, 1 de enero de 1970 UTC.

debe tratar de seguir los RFC lo más cerca posible (y, aquí, enfrentar a un dulce Año 2038 Bug ¡Un día)? ¿Es "arriesgado" para que un desarrollador no siga las partes de las normas / especificaciones / RFC (especialmente cuando se trata de criptografía), cuando se considera que ya es posible obsoleta?

Tengo un poco de miedo de preguntar porque la pregunta suena tonta, pero si "implemento RFC 4880", pero a mi manera, ya no es lo oficial. Entonces, ¿Qué es lo mejor que un desarrollador debe hacer contra lo que ve como partes "obsoletas" de las especificaciones? nada?

Answer 1

Primero: creo que el ejemplo en su pregunta es incorrecto. RFC4880 utiliza un entero de 32 bits sin firmar.El problema de Y2K38 es un problema para firmado enteros de 32 bits.Según Wikipedia, los enteros sin firmar 32 bits funcionan hasta el año 2106. Un poco más de tiempo.

para responder a su pregunta: Creo que la mejor manera es ponerse en contacto con el grupo de trabajo de RFC / los autores del RFC y contarles sobre la obsolescencia.Tal vez, un RFC de seguimiento solucionará ese problema.

Por su ejemplo, creo que puede abstenerse de ponerse en contacto con el Empezar el WG OpenPGP.Creo que, hasta 2106 habrá muchas actualizaciones y sospecho que las claves V5 tengan campos de tiempo de 8 octetos.