Subject: Re: Compressed data type for S/MIME

From: [email-masked] (Peter Gutmann)
Date: Thu, 29 Jul 1999 03:06:27 (NZST)

Andrew Farrell <[email-masked]> writes:

>Also, you're not putting it in CMS, you're writing a supplmentary draft to a 
>RFC that going towards the light, so it'll be six months before you can even 
>get a draft of "CMS for S/MIME 4", which might make support of CompressedData 
>mandatory.

Given that it seems to take 1-2 years to get things from draft -> <anything
beyond a draft>, I don't think starting now will cause any major problems in 
switching over - implementors will have at least twelve months before they 
even have to think about whether they'll dedicate an hour before lunch or an 
hour after lunch towards plugging zlib into their existing code (it took me
longer to write the draft than to implement it, it really is that simple).  As
far as I'm concerned a non-MUST requirement is fine (either make it an explicit
SHOULD or an informational RFC), all I'm really after is a standard, non-
propietary (ie other than "define your own content type") way to integrate 
compression into CMS.

[My motivation for bringing up compression at this time was a request from 
 someone who's transmitting batched EDI messages of up to 100MB secured with 
 CMS.  This is used for medical and financial EDI, these guys *really* need 
 compression.  So far the end users I know of have been using hacked-in zlib 
 compression but I'd prefer to provide something standard rather than a 
 proprietary add-on which nothing else supports.  For this particular use a 
 SHOULD/informational RFC is fine, since the interoperability spec for 
 whatever it is they're doing can require "CMS with compression as per RFC 
 xyz".  If any of the EDI/HL7 crowd are reading this, maybe they'd care to 
 comment]

What would be the best way to handle this?  I can see several possibilities:

1. Supplementary draft with something like "MUST after 2000/2001/whatever"
   (or just an implied "MUST once this reaches RFC stage", which is probably
   the same thing)
2. Supplementary draft with SHOULD.
3. Informational draft.
4. <anything else?>

>A solution I came up with the last time someone walked up to me and asked me 
>this (which works inside the current solidifying structure) is to define new 
>oids for "this compression followed by this encryption" and "this compression
>followed by this hashing", but that run the obvious problem that you end up 
>with (# of hash algs + # of symmetric algs) * # of compression algs new oids. 

Ick.  That rapidly becomes unmanageable because of the explosion of OIDs.

Peter.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 28 Jul 1999 09:58:35 -0700

I think it is something that would be good to address if we are honest 
about how long it will take to get into products. It doesn't need any MUST 
or SHOULD. Wording to the effect of "future revisions to CMS SHOULD include 
this extension" is appropriate.

I think that your initial draft should also describe an option in 
sMIMECapabilities that says "receiver can handle compression types a, b, 
and c" so that S/MIME implementations can add this in in an orderly fashion.

--Paul Hoffman, Director
--Internet Mail Consortium