Tony:
I recall a discussion of this on the list quite some time ago; there are
tradeoffs. One size does not fit all. One application could appropriately
select one ordering, and another application could appropriately select the
opposite. For this reason, we do not want to mandate any particular
ordering for CMS.
Perhaps the user community of S/MIME is diverse enough that we should not
pick a single ordering for this context. This is the position expressed by
Peter Gutmann, and I can live with it. However, the text needs to provide
a discussion of the pros and cons for the supported orderings.
Someone writing a general purpose library should support arbitrary ordering
of CMS protection content types (at least on the receive side).
Russ
At 10:32 AM 8/30/2002 -0400, Tony Capel wrote:
Russ:
I understand your concern. I had hoped to dodge this by recognizing
that this decision is very instance-specific, i.e. dependant upon what
the end user is using the signed message for. But from the poor
programmer-of-messaging-software perspective she needs to know NOW what
to do for all future end user applications.
So maybe some guidance along the following line might be what is needed
(the first two of which are obvious):
1. Always compress before encrypt.
2. Always compress before sign if using a lossy or other non-fully
reversible algorithm.
3. In all other cases sign before compress if not instructed otherwise,
and provide a local (implementation specific) means for the user to
specify the other order.
The rationale for selecting signing first if the user does not specify
otherwise is based on the assumption that this will most often satisfy
the most stringent user signing policy (it will be wrong least often!).
However, implementations should permit the local configuration of this
based on user operational or other policies.
As far as getting into a discussion of why one way or another is
"better", it is not clear to me that s/mime is the right place for that.
This might be better treated in signature policy or other such
documents.
tony
> -----Original Message-----
> From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]
> On Behalf Of Housley, Russ
> Sent: August 29, 2002 10:21 AM
> To: Tony Capel
> Cc: blake(_at_)brutesquadlabs(_dot_)com; ietf-smime(_at_)imc(_dot_)org;
'Peter Gutmann';
> Francois(_dot_)Rousseau(_at_)CSE-CST(_dot_)GC(_dot_)CA
> Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt:
CompressedData
>
>
> Tony:
>
> I agree that the use of the compression algorithm identifier in S/MIME
> Capabilities is the right approach.
>
> I think that we need to offer guidance in MSGbis for S/MIME
applications
> on
> the order of operations. Other applications that make use of CMS
could
> make different decisions, but MSGbis should set the conventions for
> S/MIME.
>
> RFC 2634 describes the triple wrapper:
> sign-encrypt-sign.
>
> To maintain maximum capability with this specification, we have two
> choices:
> sign-compress-encrypt-sign; or
> compress-sign-encrypt-sign
>
> In support of the sign-what-you-say concept, I prefer
> sign-compress-encrypt-sign.
>
> Russ
>
>
> At 10:30 AM 8/28/2002 -0400, Tony Capel wrote:
> >Blake:
> >
> >I wonder if we could not close off the "CompressedData" discussion
> >simply by adding a few word (e.g. "...and compression, see RFC3274" )
> >reference to RFC3274, Peter's compression rfc, to Section 2.5.2 of
MSG
> >(and adding RFC3274 to the list of references)?
> >
> >If 2.5.2 is updated to address the preferBinaryInside issue maybe now
is
> >the time to do both (especially since both are aimed at reducing
> >messaging overhead).
> >
> >CompressedData use is listed as an outstanding issue for MSG in the
> >recent IETF WG meeting minutes:
> >http://www.imc.org/ietf-smime/mail-archive/msg01339.html
> >
> >It has also been raised in three threads on this list:
> >http://www.imc.org/ietf-smime/mail-archive/msg01295.html
> >http://www.imc.org/ietf-smime/mail-archive/msg01172.html
> >http://www.imc.org/ietf-smime/mail-archive/msg01241.html
> >
> >With respect to the order of compression and signing: For receivers
it
> >has been pointed out that the encoding unambiguously indicates the
order
> >upon receipt. Thus it would appear that no new mechanism is required
to
> >ensure interoperability (providing the receiver can process the
entities
> >in either order, and I THINK this what is implied by the current
text).
> >
> >With respect to whether the sender should sign or compress first:
Some
> >applications will prefer signing first (sign-what-you-say, e.g. to
meet
> >EU or other "directives" interpreted to require signing before
> >compression) and others will prefer compression first (signing the
> >compressed version, e.g. for processing efficiency or as would be
> >required if lossy compression were to be used). I suggest we dodge
this
> >bullet by arguing that this is an application issue best left to
> >mechanisms (if needed) outside s/mime.
> >
> >Adding a reference to RFC3274 would emphasize RFC3274's use of
> >corresponding compression algorithm OID(s) as an sMIMECapability to
> >specify receiver compression capabilities. Hopefully this will
promote
> >the implementation of compression which will reduce message overheads
> >benefiting mail system operators and users accessing e-mail over low
> >bandwidth channels.
> >
> >tony
> >
> > > -----Original Message-----
> > > From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
> >[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]
> > > On Behalf Of Tony Capel
> > > Sent: July 9, 2002 10:24 AM
> > > To: 'Peter Gutmann';
Francois(_dot_)Rousseau(_at_)CSE-CST(_dot_)GC(_dot_)CA;
> > > blake(_at_)brutesquadlabs(_dot_)com; ietf-smime(_at_)imc(_dot_)org;
rhousley(_at_)rsasecurity(_dot_)com
> > > Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt
> > >
> > >
> > > Peter,
> > >
> > > many of us like your compression addition and would like it widely
(if
> > > not ubiquitously!) implemented.
> > >
> > > One perceived barrier to the adoption of s/mime is the expansion
of
> > > message size due to the repeated application of transfer (base64)
> > > encoding at each wrap. Messaging system operators become alarmed
when
> > > told message sizes may more than double as a result. (Indeed the
NIST
> > > draft profile depreciates such coding of inner wraps to address
this
> > > issue.)
> > >
> > > The ability to offer compression also addresses overall message
> > > expansion and will be an important capability to offer in
compensation
> > > when "marketing" the adoption of s/mime by large organizations.
> > >
> > >
> > > Tony Capel
> > >
> > >
> > > -----Original Message-----
> > > From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
> > > [mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of
Peter Gutmann
> > > Sent: July 9, 2002 4:49 AM
> > > To: Francois(_dot_)Rousseau(_at_)CSE-CST(_dot_)GC(_dot_)CA;
blake(_at_)brutesquadlabs(_dot_)com;
> > > ietf-smime(_at_)imc(_dot_)org; rhousley(_at_)rsasecurity(_dot_)com
> > > Subject: Re: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt
> > >
> > >
> > > "Blake Ramsdell" <blake(_at_)brutesquadlabs(_dot_)com> writes:
> > >
> > > >I didn't see much uptake on this besides Russ saying "MAY", and
I'm
> > > worried
> > > >about compatibility. I will put a slide in my presentation about
> >this
> > > for
> > > >Yokohama.
> > >
> > > AFAIK the major use at the moment is in EDI environments (large,
> >highly-
> > > compressible messages, and everything is "by prior arrangement"
> >anyway).
> > > There
> > > are a couple of apps which support it out there though, so having
it
> > > mentioned
> > > would be nice just to let implementers know it's there.
> > >
> > > Peter.