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

From: "Tony Capel" <[email-masked]>
Date: Wed, 28 Aug 2002 10:30:28 -0400

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: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Tony Capel
> Sent: July 9, 2002 10:24 AM
> To: 'Peter Gutmann'; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> 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: [email-masked]
> [mailto:[email-masked]] On Behalf Of Peter Gutmann
> Sent: July 9, 2002 4:49 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt
> 
> 
> "Blake Ramsdell" <[email-masked]> 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.

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 29 Aug 2002 10:21:22 -0400

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

---

From: "Tony Capel" <[email-masked]>
Date: Fri, 30 Aug 2002 10:32:48 -0400

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

> On Behalf Of Housley, Russ
> Sent: August 29, 2002 10:21 AM
> To: Tony Capel
> Cc: [email-masked]; [email-masked]; 'Peter Gutmann';
> [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt:
CompressedData
> I think that we need to offer guidance in MSGbis for S/MIME
applications
> on

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 30 Aug 2002 10:55:40 -0400

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

---

From: "Tony Capel" <[email-masked]>
Date: Fri, 30 Aug 2002 11:45:43 -0400

Russ:

Sorry, I have misled you with my message.

I agree with Peter and with your "I can live with it" conclusion.  The
problem I see is that although we must allow the user to be able to
select either method; we have the problem of telling the software
implementer what to do today in the absence of a decision (which will be
made by users in the future).  Do we have implementers/vendors flipping
a coin or making value judgements themselves on the pros and cons?
Rather than that, we say: 1. "the order should be capable of being
specified by the local user" and (really optionally) 2. "the default
behaviour is as follows". If we fail to do this, we will have
implementations with one or the other order decision embedded (and
potentially unalterable) in the implementation. Also there are some alg
types where compression first is mandatory for technical reasons.

tony

> From: Housley, Russ [mailto:[email-masked]]
> Sent: August 30, 2002 10:56 AM
> To: Tony Capel
CompressedData
> select one ordering, and another application could appropriately
select
> the
> pick a single ordering for this context.  This is the position
expressed
> by
> > > make different decisions, but MSGbis should set the conventions
for
> > > S/MIME.
> > > To maintain maximum capability with this specification, we have
two
> > > choices:
> > > >reference to RFC3274, Peter's compression rfc, to Section 2.5.2
of
> >MSG
> > > >If 2.5.2 is updated to address the preferBinaryInside issue maybe
now
> >is
> > > >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
> > > >applications will prefer signing first (sign-what-you-say, e.g.
to
> >meet
> > > >required if lossy compression were to be used). I suggest we
dodge
> > > > > many of us like your compression addition and would like it
widely
> >(if
> > > > > One perceived barrier to the adoption of s/mime is the
expansion
> >of
> > > > > 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
> > > > > >I didn't see much uptake on this besides Russ saying "MAY",
and
> >I'm
> > > > > are a couple of apps which support it out there though, so
having
> >it

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 30 Aug 2002 16:24:17 -0400

Tony:

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