Que peut-on faire contre les risques d'obsolescence dans les RFCS?

Question

the RFC 4880 , un document qui décrit la cryptographie openpgp Standard, trouve ses racines dans RFC 2440 , publié en 1998 (c'est il y a seize ans < / em>, soi-disant avant que les systèmes 64 bits sont émergés). Les deux spécifications racontent la même chose sur la façon dont les horodatages sont gérés:

3.5 . Champs de temps

Un champ d'heure est un numéro de quatre octets non signé contenant le nombre de secondes écoulées depuis minuit, 1er janvier 1970 UTC.

Devrait-on essayer de suivre les RFC aussi étroitement que possible (et ici, faites face à un doux Année 2038 Bug Un jour)? Est-il "risqué" pour un développeur de ne pas suivre des parties des normes / spécifications / RFCS (surtout en ce qui concerne la cryptographie), quand ils sont considérés comme potentiellement obsolètes déjà?

Je suis un peu peur de demander parce que la question semble stupide, mais si je "implémente RFC 4880" mais à ma manière, ce n'est plus la chose officielle. Alors, quelle est la meilleure chose qu'un développeur devrait faire contre ce qu'elle considère comme des parties "obsolètes" de spécifications? rien?

Answer 1

Premier: je pense que l'exemple de votre question est faux. rfc4880 utilise un entier non signé 32 bits.Le problème Y2K38 est un problème pour Signé 32 bits entiers.Selon Wikipedia, des entiers de 32 bits non signés fonctionnent jusqu'à l'année 2106. Un peu plus de temps.

Pour répondre à votre question: Je pense que le meilleur moyen est d'entrer en contact avec le groupe de travail RFC / les auteurs de la RFC et leur dire de l'obsolescence.Peut-être qu'une RFC de suivi résoudra ce problème.

Pour votre exemple, je pense que vous pouvez vous abstenir de contacter le WG OpenPGP.Je pense que jusqu'à 2106, il y aura beaucoup de mises à jour et je soupçonne V5 Keys pour avoir des champs de temps de 8 octets.