I think you're on a roll here. Now if we can find a way to collapse the
multipart/signed and application/s/mime into a single entity, we may be
able to move forward with a single format that meets everyone's needs.
something like:
application/mime-multipart-pkcs7-signature (??!)
which always contains exactly one multipart/signed and is optionally
CTE'd depending on how much you trust the path to the recipient...
If we could migrate to a single such signature format, it would also
resolve the last ambiguity with application/pkcs7-mime (because that
would always indicate encryption).
-steve
----------
From: Blake Ramsdell[SMTP:BlakeR(_at_)deming(_dot_)com]
Sent: Friday, July 25, 1997 11:20 PM
To: 'Ned Freed'; 'John Gardiner Myers'
Cc: 'ietf-smime(_at_)imc(_dot_)org'
Subject: RE: application/mime and binary data
On Friday, July 25, 1997 6:19 PM, Ned Freed
[SMTP:Ned(_dot_)Freed(_at_)innosoft(_dot_)com] wrote:
Hmm. An interesting idea. It would certainly eliminate one level of MIME
structure and would limit the utility of this type. And perhaps gateways
would
learn to leave this alone, since its function is clearly associated with
signatures. I think I like it... Note, however, that the implications of
2.2.1
would also apply to application/signed.
In the barrage of messages that formed the Great multipart/signed vs.
signedData War of '96, a very small exchange took place with the subject
"application/smime". For this discussion, the most pertinent paragraph
from that exchange was:
From: "Lewis Geer (Exchange)" <lewisg(_at_)Exchange(_dot_)Microsoft(_dot_)com>
Date: Sun, 22 Sep 1996 12:34:33 -0700
The mime in application/mime is probably too generic. It's possible
that people would start using it to tunnel other standards that might
not make it intact thru gateways, like mime encapsulated html (mhtml).
The problem with this is there is no easy way for the receiving agent
to tell if the application/mime content is s/mime, mhtml, or any other
standard (mhtml in particular is difficult as it is just a subclass of
multipart/related). Because of this, it's possible that the receiving
agent may send mhtml to an s/mime helper app. The fix is to call
application/mime something like application/smime.
The prospect of making Lewis' idea more generic to accommodate *any*
multipart/signed entity (the application/signed type that is being
discussed) is probably a good idea, and it isn't as much of a chainsaw
as application/mime, so innocent bystanders will be safe.
The idea is that any multipart/signed thing can be tunneled using
application/signed, presumably using appropriate CTE on the
application/signed part, the opacity is not as objectionable as
signedData, and it is not overly general to allow potential misuse.
Special language can also be drafted that explains why this might be a
good thing and what situations you might use it in, and the work does
not have to be redone for any other multipart/signed tunneling effort.
Blake