ietf-smime
[Top] [All Lists]

Re: application/mime and binary data

1997-07-31 12:39:48
James M. Galvin wrote:
I should say that I'm not fundamentally opposed to application/{signed or
mime}, I just want to make sure we agree on the facts and the reason why we
need it.

That's similar to my position.  We need to understand that we have
mutually incompatible requirements here.  The usual method of obtaining
a specification through successive approximations made in response to
raised issues does not work well in this situation.  To obtain a good
solution, people need to keep in mind the entire problem set and keep
straight which modes of operation address which requirements.  This is
difficult to do in a typical list forum, where the group attention span
is rarely longer than two messages.

So you're recognizing that in spite of the utility of application/{signed
or mime} it has its own set of problems.

Absolutely.  This is a key point I'm trying to make.

You're comparing apples and oranges.  PGP and PEM are secure email
protocols.  Multipart/signed is not.  mp/signed works only in conjunction
with a secure email protocol; it does NOTHING standalone, from a security
point of view.

mp/signed is a framework, it's a wrapper, for conveying email that has been
secured by a secure email protocol from here to there.

Multipart/signed is a framework for secure email protocols.  Plug any
valid specification for what goes into the second part and the result is
a secure email protocol, comparable to PGP or PEM, which has the
properties I describe.

Ok, so when I claim that multipart/signed has particular properties,
It's really shorthand for claiming that all systems which consist of the
combination of multipart/signed plus a valid specification for what goes
into the second part of multipart/signed have said properties.

Now, this longhand form doesn't add anythng to understanding the core
problems, it just makes things longer to type and harder to follow.  So
can we just use the shorthand from from here on out?

Armoring or not is a transport, or MIME decision, not mp/signed.  mp/signed
provides some explicit requirements about ensuring the 7bit nature of the
object to be conveyed but that's as close it gets to a transport.

Since multipart/signed is a composite MIME type, it (or all systems
which consist of a combination of it plus a valid specification for what
goes into the second part of it) inherits the property from MIME that it
cannot itself be tranfer-encoded and it cannot be armored by an
enclosing type without losing its property of making the signed content
visible to existing MIME UA's.

It is not relevant whether these properties come from the
multipart/signed specification itself or whether they are inherited from
MIME.  Multipart/signed (or all systems which yada yada yada) has these
properties.

When conveying text, mp/signed is blue if the object to be signed is C-T-E
7bit; it is red otherwise, since the object must encoded prior to signing.

The key phrase here is "prior to signing".  Red systems are capable of
encoding after signing, so arbitrary content can be signed.

PGP, PEM, and S/MIME combine the decision of armoring with the secure email
protocol.  mp/signed doesn't care where the decision is made about
armoring, whether it be the secure email protocol or the MIME transport.

Again, multipart/signed cannot be armored at a higher layer without
losing its property of being blue (visible to existing MIME UAs).

The issue, as I see it, is that MIME is fundamentally flawed from a
security point of view: there is no way to guarantee the integrity of an
object in all cases, i.e., you have to use MIME in a perverted way to
achieve the goal of integrity.  More specifically, MIME neither permits
nested encodings nor guarantees the opaqueness of composite objects.

I'll sort of agree with that.  MIME was developed without the input or
attention of the security community.  These are the tools we are given
to work with.

Now that we have an installed base of a "broken" MIME and the motivation
for backward compatibility is no longer present, application/{signed or
mime} solves a problem in a way that is "compatible" with the installed
base, however perverse when judged against the MIME philosophy.

I don't agree that the motivation for backward compatibility is no
longer present, nor do I agree that appication/{signed or mime} is
"compatible" with the installed base.  A cost of application/signed or
application/mime is incompatibility with the installed base.

Blake Ramsdell wrote:

The big win is for people who value the signatures more than the
content.  Some people might argue "What good is a signature if you can't
verify it?"

It is clear that in a public forum, the content is considered to be more
important than the signature.

You make a good point that there are situations where the requirements
are different.

 if it ain't signed, bounce it.

I find that level of service to be strange.  What good is a signature if
you don't know anything about the identity that has been proven? 
Anyway, this is a side issue.

We have implemented our user interface in such a way that the user is
isolated from this decision.  In the event that all of the recipients
are "preferSignedData", then we send the message as signedData -- no
problem.

In my opinion, you've still pushed the problem too far towards the
sending user.  If a signature is so vitally important to a receiver, it
is reasonable to require them to have the infrastructure to preserve the
signatures.  If deploying support for multipart/signed throughout their
infrastructure is impractical, then perhaps they should deploy an edge
gateway which converts multipart/signed into an appropriate armored type
along with the UAs which understand signatures.

My hope was that the discussion of application/(signed or mime) would
lead us to a suitable replacement for signedData since it could be a
single MIME part that could encapsulate with transfer encoding a
multipart/signed entity.  This would solve the problems that signedData
solves (integrity during transmission and keeping the content and the
signature together in a verifiable way), without the nasty side-effect
of giving non-S/MIME clients a PKCS #7 encoded pile of junk with their
MIME strewn about inside of it.

So instead of a PKCS #7 encoded pile of junk they get a MIME encoded
pile of junk.  This IS an improvement since MIME encoded piles of junk
are easier to add support for, but it needs to be understood that to the
installed base it is still just a pile of junk.

Paul Hoffman wrote:
Well, it appears to be a natural law that you can have "red" or "blue",
but not both.

You can allow both types to be sent and describe how recipients should
handle each. That's what's in the S/MIME spec.

But what is specified in the S/MIME spec does not affect what the
installed base does.
 
Some people are saying that they have a need for "red"
properties.  I'm saying that if there is a sufficiently strong need for
something "red", then design something that is good at being "red" and
which can be easily converted from and to things which are "blue".

The latter part does not describe signedData since it cannot be easily
converted by a human reader.

None of the proposed opaque types can be easily converted by a human
reader.  I was talking about conversion by intermediary programs.

Don't try to design something which is both sort of "red" and "blue" at
the same time, as you're going to end up with something which is
neither.  Drive on one side of the road or the other, don't drive on the
median.

I think you're missing the point in S/MIME: you can choose either.

My point is that application/mime in its proposed form of having
encoding restrictions is akin to trying to drive on the median.

This is a conscious design decision to, if necessary, make messages more
likely to be human readable than to be dispatchable by MIME-aware UAs that
do not follow the S/MIME spec. Said a different way, app/mime will probably
break the signature-verifying capabilities of a small number of non-S/MIME
UAs but will let the large number of people with non-S/MIME UAs read the
messages sent to them.

Application/mime will hinder the ability of the installed base of MIME
UAs to read the messages sent to them.  It shares this property with all
armored-signature systems.

So, people are therefore expected to
run around changing their installed base of UAs to be able to deal with
the shim,

They don't need to do this if they followed the S/MIME spec.

Well, if they followed the S/MIME spec, then by definition they are not
the pre-existing installed base of UAs.

Also, it is unclear how many non-S/MIME UAs that can process
multipart/signed X.509 signatures exist. I believe the number is
vanishingly small. The few PGP/MIME UAs deployed can't handle X.509
signatures, so they don't count. I think that leaves PEM clients. We are
saying "those few PEM clients aren't as important as people who don't have
S/MIME being able to read a signed message."

You're incorrectly equating "process the signature" with "read a signed
message".  Of course non-S/MIME UAs can't verify the signature.  But all
of the MIME UAs can read the content part of a multipart/signed, and
having them able to do so is an important requirement.


<Prev in Thread] Current Thread [Next in Thread>