ietf-smime
[Top] [All Lists]

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

2002-08-30 13:30:21

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

At 11:45 AM 8/30/2002 -0400, Tony Capel wrote:
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

> -----Original Message-----
> From: Housley, Russ [mailto:rhousley(_at_)rsasecurity(_dot_)com]
> Sent: August 30, 2002 10:56 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 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.