On Friday, August 01, 1997 9:09 AM, Ned Freed
[SMTP:Ned(_dot_)Freed(_at_)innosoft(_dot_)com] wrote:
Well, I for one disagree with this assessment. The problem with having two
formats is that it then becomes a matter for the sender to choose which one
to
use. And that's simply wrong -- this choice cannot in general be made
intelligently by the sender. (I'm sorry, but a lot of situations exist where
knowledge of the recipient doesn't exist, and I've yet to see a proposal
that
deals with what happens when the capabilities of the recipient change over
time.) What you're again trying to do is second-guess any gateways that may
be
present. And while I continue to think that this is mostly harmless, I also
continue to think that it is mostly futile. Use application/mime and my
gateway
will treat it as composite. Nothing gained or lost. Use application/smime
and
my gateway will treat it as composite. Nothing gained or lost. Play around
with
encodings and my gateway will decode them all. Nothing gained or lost. Use
signedData in the process raising the bar for gateways to play, and get
widespread deployment and you'll get two things: You'll have pissed off the
gateway vendors and you will force them to implement a lightweight PKCS#7
parser. Here all you gain is the emnity of the gateway implementors, so that
when you do decide to call upon them for a real solution you won't get
anywhere.
(Sorry about the big quote). Ned, I can't sit by and not have secure
email until the gateway vendors evolve their products to accommodate
this recent (multipart/signed is two years ago -- not so recent)
development. There are some gateways that are simply not in active
development, attached to networks that are simply too large to roll out
a new version because this faction of the Internet community would like
it to happen. I would even argue that there are some gateways that will
stay exactly the way they are until they are thrown out and replaced --
they will never be modified.
I know that sometimes the recipient capabilities are not known (I've
even pointed it out). In that case, you shoot for content preservation,
not signature preservation. As far as changing over time, at one point
we specified that the signingTime attribute in a message was coupled
with the SMIMECapabilities so that newer capabilities could be recorded.
I will check on that, since you're right -- it is important, and I
don't see it in the current draft.
I am willing to yank out any stopgap measures that I have put in, as
soon as we reach Gateway Nirvana. The preferSignedData attribute will
eventually fall out of use when we reach this point, and clients will
automatically start working "the right way". Of course, this is likely
to be at the point where we don't have to use CTE and everything is
binary also, but that's beside the point.
As far as a gateway tunneling into signedData, I think at that point it
is really over the edge. The gateway has gone to the point where it
would implement PKCS #7 unwrapping code, and it has deliberately not
stopped to consider the consequences of modifying signed data. This is
generally destructive to the use of digital signatures, and is in my
opinion a suicidal move in the face of their increasing popularity.
Right now, the use of signedData might make gateway vendors hopping mad,
but I still have my signatures intact. Maybe the gateway vendors will
take pause and understand that what I do is not out of malice or spite,
but out of necessity to enforce the sender's will over that of the
gateway, which does not understand the sender's goals of sending a
signed message.
Right now we have accommodated for the sometimes conflicting goals of
the gateway (make sure it gets taken apart as best as it can, so that
the content is preserved in a meaningful way -- preservation of content)
and the sender (usually, I don't care if the signature gets eaten so
preservation of content is important. But dammit, sometimes I want to
make sure that the signature is preserved!) If the recipient's gateway
implements tunneling to attack signedData, then it is making a value
judgement -- it believes that mangling the content is more important
than the sender's wish that it not be mangled, even though the sender
has explicitly made the decision to keep the signature intact
(otherwise, he would have sent it unsigned or as multipart/signed).
This is a hard issue.
If PKCS #7 tunneling evolves without intelligent handling of the fact
that it is munching a signature, then I will encrypt all of the messages
also. At some point my goals of on-demand guaranteed integrity,
non-repudiation and authenticity will be accomplished. You're right,
this isn't healthy. Neither is diving into PKCS #7 signedData to grab
the MIME out and discarding the signature like a dirty tissue.
I am in the position of developing both client and gateway products.
Our latest product is a gateway product that makes very hard, thoughtful
decisions about monkeying with signedData. In the event that a
modification would need to happen to a signed part (signedData or
multipart/signed), there are very clear, administrator definable rules
as to what should happen. These rules can be (among other things) the
modification of the content (and removal of the signature), or the
notification of the sender and quarantine of the message. I believe
that a similar level of intelligence is required for other gateway
products to evolve to the point where the sender's wishes are not
ignored due to the "I know better" attitude of some of the current
gateway technology that is still stuck in the early '90s, which
interferes with conducting business-grade email. In my opinion, I would
prefer that gateways return messages that are signed to the sender with
a notification that the gateway needs to perform processing on the
message which would invalidate the signature. At that point, the sender
could come up with some way to deal with this development (send the
message unsigned) and continue on his way.
FWIW, I do not see application/[s]mime as a second format option. I would
expect it to be used unconditionally if it is used at all. I would also
expect
to see a rapid response from gateway vendors if it comes into widespread
use.
OK, so you use it unconditionally which pisses off every single mail
client that is not aware how to process these constructs. What am I
missing here? I get the impression that you're not considering the
clients right now. The installed base, as John points out.
Have we seen rapid response from gateway vendors with multipart/signed?
Is the use not widespread enough? I'm honestly asking.
No. What is really needed is a single format and rules for how gateways have
to
handle it. The IETF needs to stop pretending that gateways don't exist and
can
be ignored or worked around.
No one is suggesting that we ignore the gateways, they are most
certainly important. Maybe what needs to happen is that gateways need
to stop ignoring the goals of constructs like multipart/signed and
signedData, and instead stop screwing them up and deliberately working
around them. You cited before that Internet standard non-compliance is
a great wakeup call to gateway vendors to fix their products. I guess
that since RFC 1847 is just Standards Track, it isn't really a standard
yet, so the vendors wait until that "STD" shows up, and then become
compliant. I'm not referring to you, of course, but to the ones that
don't work and play well with multipart/signed.
So what can we add to multipart/signed to clarify this? There is
already language that says that you ***MUST NOT*** modify the first part
(which still happens), and the content is not always carried intact
through the gateway to keep the integrity of the signature. Is there
something ambiguous about the way that multipart/signed is worded that
seems to make gateway vendors think that modifying the first part, or
not presenting the first part intact along with the signature
information, is not necessary for signature validation? I don't think
gateways are dumb -- it's just that sometimes they are behind the times,
which is quite apparently the case with multipart/signed. I still don't
see what the problem is with having a stopgap measure (signedData /
application/mime / application/signed / whatever) to get around
compatibility with older technology. I further don't see what the
problem is with having two encapsulation methods with clear rules to
decide when to use each one, so that as much compatibility can be
achieved before some future time where the world is better.
Blake
--
Blake C. Ramsdell
Deming Internet Security, a Worldtalk Company
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103 Fax +1 425 882 8060