ietf-smime
[Top] [All Lists]

RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt: CompressedData

2002-08-29 15:19:01

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.