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.
I don't think we are at a point to discuss whether some piece of
additional data creates or does not create in which area.
- The proposed indication presents information that is already
being carried in another indication.
- The proposed indication doesn't provide anything new.
- No argument of a concrete need has been given.
- All arguments concerning complexity of treatment are extreemly weak
even without comparing to what has to be done already for CMS SignedData
- If one assumes the availability of a PER coder/decoder and a DER
signature creation/validation at the same time, then complexity
is even less an argument.
- If someone has problems with embedded systems that maybe some
very simple subset of BER and a much more limited syntax than
SignedData could be used, why stay with CMS at all?
- If you want to save data, then code all relevant information inside
data, and not within attributes.
- unless there is an existing example for that use, included as
an example inside the text, I don't think that we are even at
an experimental state.
- The proposition below about an alternative way does not mean
at all that I think that the whole concept is useful at all,
or in other words, I just made a joke.
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.
I guess you are right with your observation about potential
problems (cf my last point above).