"David P. Kemp" <dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil> writes:
The one sentence omitted from what you quote below states that it DOES go
beyond
2038.
Yeah, sorry, it was late at night and I read through it very quickly.
The reason for a binary attribute in the first place is primarily space
efficiency.
As Peter Sylvester has pointed out, in order to be compatible with existing
apps, you'd need to include *both* attributes (the TLS WG has just had a debate
about the 10-year old obsolete known-insecure SSLv2 protocol and why virtually
everything still has to support it by default for backwards-compatibility, so
you'll never get rid of the existing signing time). As a result, you won't save
a few bytes in the time encoding, you'll double the space through having to use
two different formats.
In addition the space saving is insignificant, a few bytes. I can save the
same amount by not encoding the optional NULL parameter in algorithm
identifiers, and that without breaking backwards compatibility like
binary-time does.
If saving a few bytes really is so critically important then this should be
pursued by creating a new ASN.1 time type so that everyone may benefit from
it. If it's part of the standard time CHOICE then it can be used everywhere
where UTC/GeneralisedTime is currently used.
Peter.