The document states the rationale. No conversion to operating system
representation and it is smaller. In what way do you find it limiting?
It doesn't go beyond 2038, whereas UTCTime at least goes to 2050.
Some thoughts:
The value is an ASN.1 INTEGER, not a time_t or whatever.
The format IS flexible because it allows any integre size. It may just
happen that implements will wake up 33 years and find out that their
asn1 decoding of this INTEGER cannot convert higher numbers..
There are machines where the internal format of time is not seconds
since 1.1.70, ...
Showing this time to a user always requires some conversion, while
displaying a generaizedtime does not.
The few octes advantadge over generalizedtime seems small compared to the
size of a signature. And treatment of generalized time is necessary anyway
because of dates in certs.
The proposal isn't so much limiting as... bizarre. The ASN.1 time formats
have been around forever. everything supports them, and this proposal is for a
format that isn't even as "flexible" as the not-very-flexible UTCTime. What
real problem is this addressing? Why a time_t? Why not a 64-bit time to keep
the Java guys happy? Or the Windows nanoseconds-since-1600 time? Or the
Macintosh seconds-since 1904? You could make it a choice, so no-one would
feel left out, with at least one of the choices being an identified-by-OID
value so everyone could add their own favourite oddball format...
Peter.