AMEN, Brother!
My only suggestion would be to specifically state that
is is allowed for the signature to be computed first, and
then the object compressed, followed by encryption if
desired. Just because an object is signed shouldn't
prevent it from being compressed.
Now if we can just get rid of all of the in-band certificates!
BTW, I suspect that a compression algorithm that is
optimal for text might not be so good for spreadsheets,
JPEG images, sound files, etc. Let's not lose the MIME
functionality while we're doing this. One and only one
algorithm might be too constraining. On the other hand,
I hate standards that grandfather in everybody who
was on the committee, so lets make some intelligent choices.
Bob
Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
bjueneman(_at_)novell(_dot_)com
"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."
"The most dangerous strategy is to cross a chasm in two jumps."
"Jim Schaad (Exchange)" <jimsch(_at_)EXCHANGE(_dot_)MICROSOFT(_dot_)com>
05/18 1:59 PM >>>
I was recently informed that it was criminal that we where not doing
anything to provide for compression in our encrypted mail. While I would
not go that far, it is true that this is one of the few features that PGP
currently has over S/MIME and if you encrypt mail compressing protocals
(such as modems) cannot do any compression on the data themselfs. This is a
suggested way to address the problem. Please note that thoughout this I
will use the algorithm name MIS (message is shrunk) since I have not yet
done the research to find what is the perfered IETF compression algorithm.
I recommend that we select one such compression algorithm and stick to it.
Please note -- If we are going to do this I would much perfer to do it now
and get it over with.
Note: Additional edits (such as for section 2.4.1) would be required if
this is adopted.
Insert New section:
2.4.2 Compressed Content Type
Sending agents MAY use the id-ct-smime-mis content type identifier to
indication the message has had compression applied to it. This content type
is only used within EnvelopedData content types. This content type MUST NOT
be used in a SignedData content type. This content type does not provide
any security services.
When this content type is used, the body is compressed using MIS and the
result of the compression operation is encoded as the eContent in an
EnvelopedData object.
The reason that this object cannot be used in a SignedData object is that
the signature needs to be applied to the original body, but if the body is
compressed and then encoded in a SignedData object the signature would be
applied to the compressed object. Additionally, the requirement for
applying compression to SignedData objects is not as high as they will tend
to respond to externally applied compression since the source data is merely
encoded and not scrambled.
Compression would only be applied if the SMIMECapabilities of all receipents
indicated that a compressed body is understood.
---------------------
I would assume that a new OID would be added to the SMIMECapibilities input
list. This would be either the content type oid or a different oid. I
don't really care which.
jim