Peter,
Thanks for your extended reply. I don't know about others, but it actually
does help me see your point of view better.
Your main point, as I understand it, is that X.509 is evolving in ways that
accommodate the same concerns we've addressed, and that it would have been
-- or is still -- reasonable to adhere closely to the 1421 and 1422
framework and make minimal changes to the existing specifications.
Had MIME not been a pressing force, I suspect we all would have waited for
the evolution of X.509 and worked out the naming and trust issues within
that framework. Perhaps we still should. What we (the authors) set out to
do was to integrate MIME and PEM in a more intimate way than simply
allocating a new content-domain header. In the course of this, we also
took on the problems of opening up the naming scheme and the trust models,
and we did this in the context of the MIME work. The result is now out,
and we provided extensive intermediate previews along the way.
At this point, it's primarily a matter of choosing which approach is
desirable and pressing forward. If you and/or others want to draft a
specification that is based on incremental change to X.509 and use of the
content-domain header, the process is open. At the same time, I think the
approach we took toward designing security services into MIME as a first
class extension and not just an arms length lashup of the two mechanisms is
(also) a worthwhile endeavor.
With respect your closing paragraph, the sense I intended with "the spec is
on the table" is that the specification is fully in front of everyone and
can be discussed openly and completely. Nothing forces the WG to accept
this specification, and the design approach you're advocating is perfectly
reasonable. I don't think any of the authors are inclined to ignore
contentful criticisms or comments. Of course, at least some of the likely
criticisms and comments have been anticipated. We may not come to agree on
everything, but I think there heas been and continues to be a commitment to
listen and consider.
Steve
At 7:14 PM 12/13/94, Peter Williams wrote:
>From: crocker(_at_)cybercash(_dot_)com (Steve Crocker)
>Subject: Re: voting
>Date: Tue, 13 Dec 1994 06:51:09 -0500
>Peter,
>
>I'm very interested in understanding your message fully, but your
>references to undermining the goals of the working group are not erxplicit
>enough for me. Can you elaborate a bit? Let's leave aside the question of
>whether ARPA and/or TIS is pursuing private goals; we can discuss that
>later.
>Both of these goals are motivated by experience with PEM without reference
>to MIME. To put it another way, even if MIME did not exist and there were
>no pressure to change the material in 1421, these two goals would still
>exist.
Your group is the only source of such a concrete contention; others
have shown (some 12 months ago) some immature experience with ISO
information technology (X.509 and its X.500 relationship) traditional
in some parts of the IETF; and yet others display lots of technological
bigotry (also lauded in the IETF, unprofessionally, and
unfortunately). The logic is consistently one of justification based
on experience of piloting TIS-PEM. Few of the experiences have been
backed up by other wholly equivalent pilot groupings (except that PEM
did not catch on well, that is). The directly equivalent pilot of MSP
and key management within the DoD pilot clearly shows well documented
evidence that the technology is fully usable on a large scale, if
sufficient care is put into the implementation. That a decent, usable
key management system is very costly, does not suprise me. the X.400
(1988) security and kety management solutions Ive seen operational in
several Euro banks were also very costly)
The only intellectual challenge to the PEM goals comes from the PGP
philosophers. And they wish PGP so stay distinct whatever happens to
PEM, being a (successful) product, rather than a standards effort. So
its really a non-issue in this framework.
Each of your goals can be accomodated by an incremental and limited
change to 822 PEM. This I show logically below; If I was a member of
the WG with funds to attend IETFs for 2-3 real working meetings, Id
help write this up. But Im not. So here is just a schema; no more can
I do:-
(1) shifting to 1993 certificates allows a universal encoding rule for
identifiers (you shove in any 8-bit code and syntactic format you can
get your market segment to accept)
(Colin Robbins and others explained this to you. Your requirement is
real; the response was wrong, as you attacked the goal, not the
mechanism, provoking conflict. Those communities who do not wish to
migrate to the greater functional capability, do not have to, and can
maintain a closed operational working environment for as long as they
wish.)
(2) shifting to 1993 extended certificates allows the support for
multiple certification and liability policies within a single
infrastructure, segmented interally by naming model, assurance and
liability policy, and trust model
(Warwick Ford explained this to you. Your requirement was right; the
placement of the adoption and choice of trust model was wrong, as you
attacked the goal, not the mechanism, provoking conflict. PEM 1422
stays just as it did for its domain of influence, as does DSSA, and
MOSAIC and Type I key management. PGP fits in somewhere in cypherspace
known only to its paranoid author... what evolved was the authentication
framework of X.509, which is the type of evolution Id expect after 10
years of service)
(3) a MIME-formatted message architecture can be protected through
the use of the Content-Domain field already provided.
(Such an approach requires the assumption that we have an SMTP-based
MTS, which is consistent with the goals of the group, and the 822 PEM.
Its also consistent with using PEM as a security message-wrapper for
http, and many other messaging passing protocols. Its also consistent
with the way X.400, MSP, and PKCS handle such messaging requirements
without the contortions of encoding and reencoding evident in
MIME-PEM.
That the new MIME standard for A&P might be relevant to the hypermedia
interactions between http and hgml, and some perculiar security
interactions which occur thereby, suggests further work may be
necessary to address how http reuses some of the secured MIME
technology within its message passing protocol. Looks like a topic for
some research work)
So, with such a design backwards compability is assured - given the way
the ISO
people handled the
certificates and chain processing issue in the ASN.1 and the procedural issues,
and allows existing deployments to continue to work (not fully
interwork though, given the shift of security goals in some cases)
whilst allowing general migration as understanding from field
deployment is obtained. This *is* or used to be the IETF way for mature versus
prototype work. Few if any impacts are present on other parts of the
parts of the standard when addresssing your goals in this manner. No
competing or conflictive choices are then presented. Consensus and
multi-laterial contributions are then possible. Deadlock is avoided.
>If these are the goals you're referring to when you suggest we're
>undermining the goals of hte working group, then I agree this needs careful
>discussion.
I dont believe I have anything more (usefully!) to say on this
meta-issue. Im all talked out. If the response continues to be "take
it or leave it" "there it is on the table", then we are in gunboat
diplomacy. This will be met by a predictable reaction by those who
object to such behaviour.
--------------------
Steve Crocker
CyberCash, Inc. Work: +1 703 620 1222
2086 Hunters Crest Way Fax: +1 703 391 2651
Vienna, VA 22181
crocker(_at_)cybercash(_dot_)com