>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.