Paul Hoffman / IMC wrote:
This seems like the easiest solution to this issue. I'll add a sentence
that says "messages using application/mime are subject to the same encoding
rules as message/* and multipart/* types" to the next version of the draft.
Adding a sentence to the spec is not sufficient--many existing
transports and such will happily transfer-encode subtypes of application
that they don't know anything about.
This case does not arise in practice since the contents of an
application/smime object are entirely 7bit. If there are lots of
implementations
out there that run around encoding purely 7bit data I certainly haven't
run into them.
To apply encoding rules, the type
has to be moved underneath the message top-level type.
Which would be fine in my opinion.
With the encoding restrictions, the type then becomes useless for
protecting the contents against transport encoding restrictions.
This was never the intent of the type. We get all the protection against
gratuitous change of encoding by restricting the encodings used inside of
multipart/signed to begin with.
The intent of the type was to protect against gratuitous alteration of the
overall message structure at the hands of gateways. This was the issue that
started the discussions that led to the development of application/mime. Most
MIME to cc:Mail gateways, for example, will cheerfully walk inside of any
subtype of multipart, extract the individual parts, and put them all inside of
a cc:Mail message. And the signature is ruined by this treatment. (My gateways
don't do this, of course, but I'm the exception. Most gateway vendors don't pay
the same sort of attention to RFCs that I do.)
The MIME specification, after all, clearly implies that this is the right thing
to do. And in fact it is the right thing to do -- sometimes. When you don't
have MIME or signature support on the cc:Mail side you certainly don't want
things tunneled. But when you do have this support the right thing to do is
tunnel the multipart/signed through as a discrete object. I think tunneling
should be the default, as a matter of fact. And application/mime lets us regain
this default at the hands of gateways. That's all the does, really. It is a
workaround for a major problem that is seriously jeopardizing the deployment of
signature services -- the number of users on proprietary LAN email systems is
enormous.
I'm left wondering what value it really has.
See above.
Stuff encapsulated in this
type won't be readable by existing MIME implementations.
Depends on what you mean by "readable". It may not be processed as MIME,
but the text will be there as mostly-readable text.
If the
generator is willing to take the unreadability hit, why wouldn't they
use something which can really protect it against the transport, such as
signedData?
Because with signedData the content is TOTALLY unreadable without an
S/MIME engine.
John, this is all old news -- we've discussed these issues at enormous length
in the past. I strongly suggest that you review the archives of this list so as
not to spend a huge amount of time recovering old ground.
Ned