Russ:
On the receive side, we say that the S/MIME agent must be capable of
handling either order.
On the sending side, we say that the S/MIME agent can include a
default
method for handling this (either way), and they may optionally provide
a
setting for the user to change the ordering.
Russ
yes,
With respect to the sending side issue, I guess my concern was that
providing the implementer/vendor with a whole bunch of pros and cons may
not be helpful, since IF they are developing a general purpose messaging
system they will not know enough about its future use to decide.
Rather, it would be more helpful just to say that the order must be
capable of being set by the end user. In fact, for those end users who
care, it will likely be set by organizational signing policy (e.g. bound
to the profile of the desktop or certificate). End user organizational
security experts will hopefully decide, and although they may use the
s/mime standard for input, I would hope they would refer to more
specific documents to make their decision (e.g. ETSI signing
directives). Similarly for implementers of specific-purpose messaging,
they should have access to additional requirements documentation to
allow them to decide. So I think we should keep this decision "out of
scope" for s/mime, since it is not an interoperability issue but rather
an organizational policy issue reaching beyond s/mime (impacting more
than just the order of signing and compression).
On the other hand, what about the 90+% of users who don't care? Should
we (or the vendor) suggest a default value, or should the
implementer/vendor "force" the end user to decide during installation,
the first time or every time it is used? I suggest we identify the two
cases where the order of compression is fixed for technical reasons
(compress before encryption and compress before sign if using non fully
reversible compression), then say all other cases should be set by the
end user but the default should be such-and-such since that will be
least wrong most often .... But if we are not comfortable suggesting a
default, we could leave it to the vendor to decide the default (I'm not
sure vendors will thank us for that).
By all means put the pros and cons in. But we should say that in those
cases where it is important, it is the end user who must decide based on
their own specific requirements. This implies that the end user MUST be
able to change it since there appears to be valid reasons for either
order. The pros and cons could be used to support the suggested default
value (if provided).
tony