ietf-smime
[Top] [All Lists]

Re: Compressed data type for S/MIME

1999-07-28 08:10:51
Andrew Farrell <afarrell(_at_)baltimore(_dot_)ie> 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.