Re: using application/octet-stream in multipart/encrypted
Barton E. Schaefer (schaefer@z-code.ncd.com)
Thu, 7 Mar 1996 11:23:01 -0800
On Mar 7, 10:03am, Michael Elkins wrote:
} Subject: using application/octet-stream in multipart/encrypted
}
} Could someone please refresh my memory as to why the "consensus" was to
} use application/<specific> instead of application/octet-stream in the
} second part of a multipart/encrypted message?
[...]
} The motivation for the change seems to be so that currently broken
} software can still dispatch PGP and S/MIME messages to the appropriate
} engines, therefore I'm concerned.
Right.
My recollection of the argument was that using application/<specific>
means that clients that interpret multipart/* as multipart/mixed can
recognize <specific>. If (as in the PGP case) that application doesn't
require the information from the first section of multipart/encrypted,
then such a client can decrypt the second part even without knowledge
of security multiparts.
} If RFC1847 is indeed adopted and changed so that the first part can be a
} multipart containing several different certificates (but with the same
} key, I suppose), then the second body really isn't specific to any
} system...
Correct. I don't think these are necessarily in conflict, though. If
the second part really is generic, in the sense that any of several
different controls from the first part could be used to decrypt it, go
ahead and make the second part application/octet-stream, or some other
generic label. Otherwise use application/<specific>.
Is there a technical reason why a revised version of 1847 should not
permit this? A client that is using the control information from the
first part to select the decryption engine doesn't need to pay much
attention to the type of the second part anyway.
--
Bart Schaefer Vice President, Technology, Z-Code Software
schaefer@z-code.com Division of NCD Software Corporation
http://www.well.com/www/barts