Peter Gutmann wrote:
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.
You read past the part about this being useful for CMS but not for
S/MIME. The situations where saving a few bytes is useful occur when
1) the objects being signed are small, 2) signature values are small
(i.e. DSA/ECDSA, not RSA), and 3) encoding overhead is small (i.e. PER,
not BER/DER). There are no existing applications in this space, and
thus no backwards compatibilty issues. But CMS and a newly defined
attribute can be applied to future applications without having any
impact on existing apps.
The other Peter's suggestion:
Time ::= CHOICE {
utcTime UTCTime,
generalizedTime GeneralizedTime,
epochSeconds INTEGER}
is fine with me, but I'm not sure existing applications would deal with
an unrecognized CHOICE value as gracefully as they would with an
unrecognized attribute. To avoid problems, the S/MIME -msg spec would
have to state that epochSeconds MUST NOT be used by sending applications.
Dave