I have forgotten:
The proposed format and SMIME attributes serves the same purpose as
an existing one, i.e. id-signingTime
Nothing is said about what to do when both attributes are present,
how they should be treated when available together.
One probably wants to set both, so instead of saving data and cpu,
one will add.
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.