Was kann man gegen Oric of Obsolescence in RFCs tun?

Question

the RFC 4880 , ein Dokument, das die OpenPGP-Kryptographie beschreibt Standard, findet seine Wurzeln in RFC 2440 , veröffentlicht 1998 (das ist sechzehn Jahre < / em>, angeblich vor 64-Bit-Systemen entstanden). Beide Spezifikationen sagen das Gleiche, wie Timestamps behandelt werden:

3.5 . Zeitfelder

Ein Zeitfeld ist eine vorzeichenlose Vieroktettanzahl, die die Nummer enthält von Sekunden seit Mitternacht, 1. Januar 1970 UTC.

sollte versuchen, RFCs so eng wie möglich zu folgen (und hier Gesicht eines süßen Jahr 2038 Bug eines Tages)? Ist es "riskant" für einen Entwickler, der keine Teilen von Normen / Spezifikationen / RFCs folgen kann (insbesondere wenn es um Kryptographie kommt), wenn sie bereits als potenziell veraltet angesehen werden?

Ich habe ein bisschen Angst, zu fragen, weil die Frage dumm klingt, aber wenn ich "RFC 4880" umzusetzen, aber auf meiner eigenen Weise ist es nicht mehr die offizielle Sache mehr. Also, was ist das Beste, was ein Entwickler gegen das tun sollte, was sie als "veraltete" Teilen der Spezifikationen sieht? nichts?

Answer 1

Erster: Ich denke, das Beispiel in Ihrer Frage ist falsch. rfc4880 verwendet eine unsignierte 32-Bit-Ganzzahl.Das y2k38-Problem ist ein Problem für 32-Bit-Ganzzahlen mit 32-Bit-Ganzzahlen.Laut Wikipedia funktionieren vorzeichenlose 32-Bit-Ganzzahlen bis zum Jahr 2106. Etwas mehr Zeit.

Um Ihre Frage zu beantworten: Ich denke, der beste Weg ist, mit der RFC-Arbeitsgruppe / der Autoren des RFC in Kontakt zu treten und ihnen von der Obsoleszenz zu erzählen.Möglicherweise fixiert ein Follow-up-RFC dieses Problem.

Für Ihr Beispiel denke ich, dass Sie nicht auf das OpenPGP WG wenden können.Ich denke, bis 2106 gibt es viele Updates und ich vermute V5-Schlüssel, um 8 Oktett-Zeitfelder zu haben.