What can one do against risks of obsolescence in RFCs?

Question

The RFC 4880, a document that describes the OpenPGP cryptography standard, finds its roots in RFC 2440, published in 1998 (that's sixteen years ago, supposedly before 64-bit systems emerged). Both specifications tell the same thing about how timestamps are handled:

3.5. Time Fields

A time field is an unsigned four-octet number containing the number of seconds elapsed since midnight, 1 January 1970 UTC.

Should one try to follow RFCs as closely as possible (and, here, face a sweet year 2038 bug one day)? Is it "risky" for a developer not to follow parts of standards/specifications/RFCs (especially when it comes to cryptography), when they are seen as potentially obsolete already?

I am a bit afraid of asking because the question sounds silly, but if I "implement RFC 4880" but in my own way, it is not the official thing any more. So, what is the best thing a developer should do against what she sees as "obsolete" parts of specifications? Nothing?

Answer 1

First: I think the example in your question is wrong. RFC4880 uses an unsigned 32-bit integer. The y2k38 problem is a problem for signed 32-bit integers. According to Wikipedia, unsigned 32-bit integers work until the year 2106. A little more time.

To answer your question: I think the best way is to get in contact with the RFC working group / the authors of the RFC and tell them about the obsolescence. Maybe, a follow-up RFC will fix that issue.

For your example, I think you can refrain from contacting the OpenPGP WG. I think, until 2106 there will be a lot of updates and I suspect V5 keys to have 8-octet time fields.