Peter,
Your criticism is what seems bizarre. The one sentence omitted
from what you quote below states that it DOES go beyond 2038. An
INTEGER number of seconds since Jan 1 1970 will go until the
heat death of the universe and beyond.
The question for more rational discussion is: is a binary signing time
value useful? If the answer is yes, the only remaining questions are
epoch and resolution. Since there were very few CMS digital
signatures in existence before 1970, using an epoch of 1600 or 1904
would seem to offer little benefit. It is also difficult to articulate
a rationale for specifying the moment of signing to nanosecond
resolution.
The reason for a binary attribute in the first place is primarily
space efficiency. CMS can be used to sign large numbers of
small objects, and certificates don't need to accompany
those objects. ASN.1 structures can be PER encoded, but
PER offers minimal compression of UTC or Generalized Times
(7 bits vs. 8 per character). Once you have squeezed out all bits
permitted by the standard, you look for additional opportunities.
Defining a binary time attribute is one such opportunity.
Will this be useful for S/MIME? Of course not. But it is
useful for some other applications of CMS.
Dave
Peter Gutmann wrote:
Russ Housley <housley(_at_)vigilsec(_dot_)com> writes:
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.
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.