I was in the process of responding to a private message from Amanda on a similar
point when Jeff's reply to Theodore arrived, so I'll make the same comments more
generally.
If you have an implementation that wants to only implement the RFC 1422
subset under MIME/PEM, there's nothing in the MIME/PEM draft, by my
reading, that would prohibit this. (This is modulo the key selector
issue --- the key selector issue means that you have to store one
additional bit of information in your X.500 directory, but X.500
directory are supposed to be the best thing since sliced bread, and
they're flexible enough to handle this, right?)
The question is, what does it mean to be compliant with MIME/PEM? Do
you get to pick and choose like this, and if so, what will it mean if
a vendor touts MIME/PEM compatibility if they only implement what they
feel like? They won't interoperate with someone else who has picked
and chosen a different part.
I think that the draft is responsible for stating what is needed for
compliance and what is not. Some people, and unfortunately this
includes the authors, think this is a "local issue" and that the draft
does not have to address compatibility.
You mention that all you have to do is "store one additional bit of
information in your X.500 directory". To someone who wants to use an
existing database to simply work with MIME-formatted messages, it is
not a small deal to rework the database just to do this, if that is
required to be MIME/PEM compliant.
This is a big objection of mine to the current draft. I think the
ambiguity on this point - of what information the database is required
to carry for compliance - must be cleared up. It is inexcusable to
leave an implementor out in the cold in this issue.
I agree with Jeff. And perhaps more to the point, I'd like to deliberately limit
the number of options available, not only to enhance interoperability but to
more
or less gently guide users to do the "right" thing.
A very valid argument could be made as to how far we should go in the design
and
architecture of the system to protect some of the more naive users from
potentially
serious security mistakes. If someone were to accuse me (and some of the other
designers of Classic Coke) of paternalism, I would plead mea culpa.
Even (especially?) within relatively large organizations, few people pay a lot
of
attention to security. Even if it costs nothing, there is still a price in user
inconvenience, additional training, etc. As a result, it is typically ignored
until
after a flaming disaster has occurred. Then those who didn't happen to get
burned,
generally by some lucky break, point an accusing finger at all of the less
fortunate ones, while muttering "There but for the grace of God go I."
I don't have any doubt at all that you (Amanda), Ned, Jim, Ted, Jeff, Rhys, or
I,
or in fact almost of the readers of pem-dev would perfectly be able to structure
their own personal systems in the way you describe (i.e., to implement an
RFC-1422
subset only based on the PEM/MIME structure and options).
However, I have some rather grave doubts as to whether I can get everyone else
in
the organization to go along with that. GTE may be atypical -- we don't
have a corporate director for telecommunications, security, or MIS -- each
strategic business unit does things their own way, but I think we are far from
being totally unique.
As a result, I have some doubt as to whether I will be able to so easily
reject
messages that might not be signed in that manner from somewhere else in the
organization, or worse yet from the outside. And I have almost no confidence
that I
will be able to instill the necessary discipline to make everyone else in the
corporation do things the "right" way.
And if I can't do it within my own company, I have no hope at all of being able
to
prevent innocent users in the mass market from potentially screwing themselves
by
accident, which might lead ot a backlash of ill-advised consumer "protection"
legislation, etc. Some distrust of the technology will begin to develop, and a
lot
of work toward develo0ping a public key infrastructure may be lost, or at least
delayed substantially.
So yes, I hope that we can whittle down some of the plethora of options that
are
presently available in PEM/MIME, many of which simply go too far in the
direction
of anarchy and chaos, IMHO. If that means that some of the really paranoid
radical
right or radical left can't get all of the traffic flow security and perfect
anonymity that theiur hearts might desire, well too bad. I'm certainly NOT a
stalking horse for the FBI or NSA, but my primary orientation is toward
facilitating business uses of this technology, not in indulging private
conspiracies.
If you only implement the RFC 1422 subset, then of course you have a
interoperability problem, but if someone is sending you a message that's
outside of your strict hierarchy, you don't *want* to interoperate with
them. After all, you've decided you only want to communicate with
entities that can be proven (up to a liability of $X million dollars)
came from a specific human being that you can sue.
If you implement the whole shebang, then you can accept messages from
both people in the strict hierarcy, *and* people who decided that a
looser, Volksmail approach is acceptable for their requirements.
What's the problem?
I think you're right that implementing only a subset prevents
interoperability. And I think that many people (including myself,
RSADSI, perhaps whoever Bob Jueneman advises, etc.) will only
implement the subset that makes sense. To reiterate, the "problem" is
that we may not have a standard if no one will be able to interoperate.
Agreed. And I firmly believe that the scheme that I laid out, including the use
of
self-signed certificates and a PCA domain that facilitates the quasi-automatic
certification of user's certificates based on their e-mail connectivity DOES
allow
complete syntactic compatibiltiy between the strict hierarchy, set up everything
very caredfully, top-down folks and the looser, "let's try a few simple test
cases
first" bottom-up Volksmail approach.
This still begs the question of cross-PCA domain trust, or even cross-CA
_trust_,
as opposed to identity verification. That is still an issue that has to be dealt
with via the direct trust model, root key manipulation, or a whole new set of
authorization certificates. But I believe that this approach will allow us to
reach
a concensus, move forward and build something expeditiously, and provide a
platform
for further development. In particular, it will support the further use of MIME,
which I am beginning to believe can evolve to a reasonably robust, general
purpose,
and secure representation of complex objects.
P.S. Please, everyone, let's remember that if we elevate MIME/PEM, it's
to a *proposed* *standard*. We're allowed to change proposed standards.
We're allowed to deprecate them later on, even. Vendors who ship
proposed standards as products have no standing to gripe if we change
things later on, especially if we have a good reason --- that's the
definition of proposed standard. I think we're setting bar unreasonably
high for MIME/PEM.
Maybe Ned Freed or someone who has seen several standards lifecycles
can comment. It's true that you can expect to work out a few bugs
when you move to a proposed standard. But is this true for major
issues?
Having been around long enough remember SPOOK (Supervisory Operating System over
Other Kinds) on the 7090 (back before a number of the people on this list were
even
born, I'd guess), to have installed pre-beta software on the first IBM
System/360,
and to have contributed directly to the architecture of IBM's SNA, I can
definitely
say that it is MUCH easier to get it right while systems are still in the
design/standards phase. The old phase, "there is never enough time to do it
right,
but there is always enough time to do it over" isn't true -- once systems are
released they become a legacy (otherwise known as an albatross), and you can't
do
them over at all.
The vendors can (and unfortunately usually do) walk away from them, saying, "Oh
well, we don't support those old systems any more. You'll have to update to
release
xx.y." But the users and the system administrators remain stuck with them alomst
forever, usually until the very last user of that release has given up. And then
your archive of old messages can no longer be read, because you can't afford to
do
the conversion that would be required to bring them up to the new level. Try
going
back several levels of word processor or even e-mail routines and reading your
old
messages, and you'll probably see what I mean.
I fully understand that vendors have made substantial investments in their
developments, and that time is money and they need to recoup their cash flow.
And
no one wants to get these systems out there and working any more than I do. But
I
don't want to have to do it, and re-do it, and re-do it again until we get it
right. I also understand that there comes a time when you have to shoot the
designers and ship the product, and that the better becomes the enemy of the
good
enough. I don't think we are quite there, however, but we are getting close. I
sincerely hope that we can achieve a concensus in the near future and then move
forward.
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