Hmm. Well, I guess it could be that you subscribe to a set of very insular
mailing lists with participation only from folks stuck back in the Dark Ages of
networking. But I doubt it! Let me give you a couple of scenarios to illustrate
what I was talking about.
Suppose you get a message that says, "A new draft of such and such is now
available, but is too large to include in this message. If you want a copy, FTP
to blah, CD to foo and GET bar."
I have routinely received messages like this for over 10 years.
Someone might argue that of course the user realizes that the result of
resolving such a reference doesn't necessarily have the same security as
something that was actually in the message. Problem is, I have lots of
customers who deal with users that are incapable of understanding this nuance.
Nowadays, I'm more likely to receive something like, "A new draft of such and
such is now available. Here's the URL to retrieve it, just paste it into the
"Open URL" window that appears in Mosaic and you'll have the document."
Sorry, of course I understand the concept now that you explained it. I'm just
not
up to speed yet with all of the Mosaic terminology. For the last six months or
so,
since my wife had a mild stroke, I have been working at home over an often
unreliable PPP connection at 14.4kbps. Downloading lots of Mosaic stuff under
those
conditions is like watching paint dry,m so I haven't done much. I thought you
were
referring to some standard e-mail convention I had never heard of. (now that
I've
got the luxury of a 56kbps frame realy line as an experiment, I want to take
more
advantage of Mosaic and WWW. In fact, I keep thinking how great it would be to
have
an X.500 directory to help navigate around all this stuff, instead of having to
treat the Internet as some planet-wide Dungeons and Dragons.
Classic PEM actually suffers from this problem far more than MIME/PEM, in that
in classic PEM the user is left to resolve the reference themselves, and the
user may be in no position to assess the security implications of their
actions. One of the clear advantages of MIME/PEM is that the enforcement of
security is left to the implementor of the user agent, and that implementor is
free to implement these services in ways that make sense.
Were we to try to specify the entire gamut of future services we could ever
build, we'd end up with an extraordinarily complex document that nobody,
but
nobody, will understand. This is far worse than a simple document with
obvious properties -- a signature only covers the material that is signed,
and references within that material to unsigned things are inherently
unreliable.
As long as that is made reasonably clear, I'm quite happy.
I will take steps to insure that this point is clearly made in the next draft.
Presumably you ment to say that this was NOT a matter for the base spec to
deal
with? I'm merely asking whether the need for such awareness by the user
agent's
is
common knowledge, and as the expert you may not be the right person to ask!
I don't think user agent implementors are sufficiently aware of the issues in
this area -- especially the ones I raised myself about getting unwitting users
to send threatening messages. That's why I've taken steps to address this in
the next revision of the MIME specification.
I understand that we cannot neccessarily fix all of these problems all at once.
To
borrow the classic NADF joke, it would be a shame to eat such a fine pig all at
once. (optional URL available for those who have never hear joke number 137
before,
and are therefore still laughing.)
[Discussion of very amusing "do not press" button and rhetorical question about
lawyers deleted.]
This is precisely my problem with a lot of this discussion as well. Almost all
of the issues the security multipart mechanisms bring up existed with classic
PEM as well -- you could have references to other unsigned materials (and no
way to tell if users understood the ramifications of them), you could have
messages where only certain parts are signed, and you could have nested
security envelopes. These issues are not new, and if they are so all-fired
important, why weren't they discussed in the classic PEM specifications?
All security multiparts really do is give us are additional means of
*addressing* these matters, means that we didn't have before. As such, if these
matters really are so important, it seems to me that the most logical course of
action is to get these specifications out the door ASAP so we can start
building these add-on services to solve some of these problems.
In general, I agree, although God is in the details and I don't have a
completely
adequate grasp of them yet. But from what I can see, the security multipart
document is a very solid contribution, and I strongly support Rhys' piece(s)
(sorry
- couldn't help myself) that we move that portion ahead on the standards track.
You have been much less vocal on the issue of the key selector and the broader
question of certificate management, perhaps becasue it isn't as high on your
personal list of worries.
But I would be extremely interested to know what you think of my suggestion to
Amanda, namely that we roll back the key management portion of PEM/MIME to the
equivalent of classic PEM, add explicit support for self-signed certificates to
help jump-start the process and support the direct trust model (perhaps
co-opting
PGP and almost certainly RIPEM to move in a similar direction), add support for
e-mail DNs, either directly or as an option of the v3 X.509 standard, and
support a
e-mail based certificate responder that would be sort of midway between the RSA
commercial Hierarchy and the Persona hierarchy in terms of its trust model for
identity verification in the classic PEM, as opposed to direct trust model
sense.
My feeling is that if we can come to an agreement on such an approach, and carry
the security multipart portion forward as Rhys has suggested, we would be very
close to a complete concensus. Without going back and rereading the text again,
I
would think that most of the effort would be some fairly simple deletions. If
so,
the last three weeks would have been very worthwhile and productive, as well as
a
lot of fun.
Bob
--------------------------------
Robert R. Jueneman
Staff Scientist
Wireless and Secure Systems Laboratory
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-2820