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.