Peter Williams, Bob Jueneman, Steve Dusse and Paul Lambert raised a
number of issues. Some of the issues are related to the process,
e.g. voting, consensus, the current status of the draft, etc., and
some are related to the substance of the specification. Here's my
attempt to clarify things. But first some disclosures and
disclaimers.
DISCLOSURES and DISCLAIMERS
o I am one of the authors of the MIME-PEM specs and I participated
strongly in their direction. Until recently, I also directed the
TIS effort in this area and take full responsbility for the
decisions. The other co-authors -- Ned Freed, Jim Galvin and Sandra
Murphy -- all participated vigorously and are fully cognizant of the
design. (We probably differed on some aspects of the design, but
there were certainly no deep divisions or differences among us.)
Jim Galvin led the actual implementation with the assistance of
several others.
o The implementation effort was funded by a combination of ARPA and
TIS funds. In the usual tradition of ARPA-funded efforts, ARPA gave
TIS broad latitude to conduct the funded work. TIS is ultimately
responsible to ARPA for the effectiveness of the work.
ARPA program managers -- primarily Mike StJohns -- were kept
informed of the MIME-PEM work as it progressed. However,
responsibility for the specification rests with the authors, and
responsibility for the implementation rests with the TIS group.
o I did not participate in the scheduling or running of the PEM WG
meeting. Jeff Schiller filled in for Steve Kent because Steve could
not come. I was unaware that Steve K would not be coming until
shortly before the actual meeting.
SUMMARY OF ISSUES
The main issues that have been raised by Peter W, Bob J, Steve D and
Paul L are the following. (Please add or correct this list if it's
not a fair summary.)
Process violations:
o The specification was rammed through the approval process at the WG
meeting.
o No debate has taken place on the pem-dev mailing list.
o The authors are not responsive to criticisms that have come forth.
o TIS implemented the specification without consensus of the WG.
Technical weaknesses:
o There are too many forms of identifiers.
o The trust model is unspecified.
RESPONSES
o The specification was rammed through the approval process at the WG
meeting.
The PEM WG meeting was indeed short and quieter than usual. It lasted
between a half hour and an hour, and there was little discussion. The
main point that was discussed was how close the specifications are to
previous drafts which had been discussed at length.
A "consensus check" was indeed taken and it was determined there was
no objection to moving forward with the specifications. However, it
is well understood by all involved that the WG is not limited to those
present at a particular physical meeting, and that it is necessary to
reach consensus via the mailing list as well.
It was made very clear at the meeting that discussion on the mailing
list is indeed the next order of business. It's evident this is
underway, and that's good and healthy.
o No debate has taken place on the pem-dev mailing list.
Most of the details in the current specification have actually been
discussed in the open in one form or another. Even so, nothing
precludes further discussion.
o The authors are not responsive to criticisms that have come forth.
I think the authors have been and continue to be responsive.
"Responsive" does not mean agreeing with every suggestion, of course.
It's unpleasantly easy to discover differences of opinion on various
matters, some large and some small, even within very small subsets of
the active participants in this group. In the end, reaching consensus
on all matters requires compromise in some cases and simple expediency
in other cases. As far as I'm concerned, nothing in the specification
is cast in concrete. There is a cost, however to continued change, so
it's important to weight the benefit of change against the expected
improvement. If there are proposed changes which are important
enough, they should be incorporated.
o TIS implemented the specification without consensus of the WG.
Yes, and there are two reasons for this. We felt it was important to
get something working. As noted above, in terms of producing an
implementation, the implementation team is responsbile to ARPA and TIS
management, not to the WG. In the previous effort which resulted in
1421 through 1424, the TIS implementations tracked and stayed behind
the WG consensus process. This was expensive and ultimately
unproductive. I believe we all would have been better off if there
had been an implementation frozen and available earlier, even if it
didn't track the specification precisely.
The other reason for providing an implementation prior to consensus is
the community can now gain experience with the design and not just
read about it. This is strongly in keeping with the tradition of the
IETF to have implementations ("running code") and not just piles of
paper.
Whether the current implementation will continue to track whatever
changes are adopted by the WG will depend on judgment by TIS
management and one the availability of resources. But rather than
worry overly much about this right now, it's probably more useful to
attempt to understand whatever technical issues people believe are
outstanding and then make an assessment about the future of the
implementation.
o There are too many forms of identifiers.
I agree there seems to be a small explosion of forms of identifiers.
However, except for support of the original X.509 distinguished name and
certificate structure, none are very complicated or require much code
to support. Speaking for myself, I'd have no objection seeing some
simplification in this area.
From my point of view, the essential issue was to permit name forms
other than X.509 distinguished names, and most particularly to permit
the use of e-mail names. We might be able to reduce the number of
forms of identifiers, but if we retract back to the limitations of the
X.509 distinguished names, a major goal of the design will be lost.
o The trust model is unspecified.
The trust model is probably the most divisive issue we've faced, and
it has impeded our progress at every turn. Very roughly, part of our
community believes it's essential to specify the policies accompanying
the use of signatures, and another part of our community believes it's
essential to field the mechanism and let the policies evolve. I plant
myself in the second camp, although I fully expect it will be vital to
have effective policies once the mechanisms are available.
The current specification makes it possible for a subcommunity to
adhere to whatever trust model it chooses, including the schema in
1422, but it does not mandate any particular model. The original PEM
model was restrictive, expsnsive to administer and did not meet the
needs of a broad portion of the community. To me, the widespread use
of PGP makes it evident that the tight specification and enforcement
of a trust model is not the best approach.
I doubt we'll all ever agree on this point. One thing we can all
agree on, however, is that unless we find a way to move past this
point, nothing will ever emerge.
BOTTOM LINE
1. Specs are now on the table. The process is open, and no one is
circumventing the process.
2. An implementation is available. This is a TIS output, not a PEM WG
output, and it will evolve (or not) under the usual pressures of
resources, feedback, etc.
Steve
TEXT OF MESSAGES FROM PETER W, BOB J, STEVE D AND PAUL L
Date: Thu, 08 Dec 1994 13:07:04 PST
To: pem-dev(_at_)tis(_dot_)com
From: Peter Williams <williams(_at_)atlas(_dot_)arc(_dot_)nasa(_dot_)gov>
Subject: voting
The one line of feedback I got from those who attended the 3.5
minute long meet ing was that in that space of time, the issue of
MIME-PEM was proposed, argued, voted, and ratified, before anyone
knew what the hell was happening. The meeting then adjourned before
the chairs stopped rattling.
If this is true, its shameful for a standard's and engineering task
force and the consensual process promoted by the IETF.
Are there any other versions of the story?
My current understanding of the issue as a mailing list member is that
the measurement of consensus required to move the particular suite of
technical work from the WG into the standards process has been just
stage-managed. This brings the IETF consensus process into significant
disrepute and shows complete and actual disregard for the mailing list
members and their contributions.
Now, is there another story to even out the argument?
"Voting is a bad idea in the IETF. Bad voting practices are even worse."
===========================================================================
Date: Fri, 09 Dec 1994 12:32:55 EST
To: Peter Williams <williams(_at_)atlas(_dot_)arc(_dot_)nasa(_dot_)gov>,
pem-dev(_at_)tis(_dot_)com
From: Jueneman(_at_)gte(_dot_)com
Subject: Re: voting
My current understanding of the issue as a mailing list member is that
the measurement of consensus required to move the particular suite of
technical work from the WG into the standards process has been just
stage-managed. This brings the IETF consensus process into significant
disrepute and shows complete and actual disregard for the mailing list
members and their contributions.
I heartily concur. Many, perhaps most, of the contributors to this
list in the past have not had either the time or the budget to
personally attend the IETF meetings. We have therefore relied on a
full and frank exchange of views on a given subject, and through
this process slowly (admittedly) developed a concensus. In many,
many cases, the initial presentations and discussion of ideas,
including mine, were substantially modified and improved through
this process. Errors and ambiguities were uncovered, and a certain
amount of education took place, drawing the uninitiated into the
fold.
About a year ago, however, a faction within the PEM community
apparently grew tired of trying to get people to agree with them,
and ceased most public discussion. Instead, a succession of Internet
drafts have appeared with relatively little commentary or
explanation, and were presented as more or less a fait
accompli. (The fact that they were distributed using a variation of
the MIME standard that was being discussed and which was
incompatible with several products which support MIME made them even
more difficult to read.)
A number of the more significant issues that have been holding back
the widescale deployment of PEM are still not resolved, the support
infrastructure is still lacking and perhaps not even understood, and
we seem to be retrogressing. Two years ago, I thought we were about
one year away from effective, commercial grade implementations of
encryption and digital signatures. Now I think that we are two or
more years away from our goal, and things are getting worse, not
better.
"Voting is a bad idea in the IETF. Bad voting practices are even worse."
Amen.
Bob
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
617/466-2820
Jueneman(_at_)GTE(_dot_)COM
===========================================================================
Date: Fri, 09 Dec 1994 12:18:46 PST
To: pem-dev(_at_)tis(_dot_)com
From: spock <spock(_at_)rsa(_dot_)com>
Subject: Public key identifier
>So, *do* you actually have any legitimate issues to be raised
>regarding the PEM-MIME document? If you do, please raise them now.
>This is the time!!!
Thanks Ted for that compelling invitation.
Of all the identifier forms outlined in the PEM/MIME draft for use in
Originator-ID and Recipient-ID fields, we believe that the public key
identifier alone is sufficient:
<id-publickey> ::= "PK" "," <publickey> [ "," <id-subset> ] CRLF
<publickey> ::= <encbin>
; a printably encoded, ASN.1 encoded public key (as
; defined by the 'SubjectPublicKeyInfo' production
; specified in X.509)
The optional <id-subset> should be omitted.
Our position is that the public key is a sufficient key identifier for
use in signing and encrypting and that adding name forms or key
selectors in the main messaging protocol is an unnecessary
complication:
* The public key is sufficient information for the application to
determine the name it has bound to the key, whether it be a
distinguished name in an X.509 certificate, an email address in an
authenticated table, etc. The application may then present the name
to the user.
* Putting a name form such as a distinguished name or email address in
the message is cryptographically irrelevant. Especially in the case
there there are multiple names associated with a key pair, only the
public key is used for encryption (or the associated private key for
signing), and therefore only this can be cryptographically verified. A
secure application should not trust any transmitted name information.
Instead, it should use its own certification or other local
authentication mechanisms to look up the trusted name binding based on
the public key and display this to the user.
* An application has the option to "suggest" a name/key binding when
sending a message by including an application/key-data body part
containing a certificate. The receiving application can use this, for
example, to get a candidate distinguished name if a directory server
is being used which cannot be indexed by public key.
* For similar reasons, there is no need for "backwards compatibility"
with the issuer/serial identifier from RFC 1421. If an application is
converting from an RFC 1421 message to a MIME message, it can use the
issuer/serial to look up the public key to put in the MIME message.
And an application which has a certificate database from an RFC 1421
implementation already has the public keys. No new information is
required.
For use in Originator-ID and Recipient-ID field, we find no cogent
argument, either in the Draft or in the various discussions, for the
complication of the variety of name forms and key selectors.
Therefore, in our cryptography toolkits and implementations we intend
to only support the public key identifier.
Since there seems to be no "minimal subset requirements" surrounding
the key identification (and since the spec. feedback process seems to
be broken) we are left with the assumption that our implementation will
not be compliant.
For anyone interested in interoperating with our applications and
applications which use our toolkits, we are asking for prompt
feedback as we proceed in designing the next version of our software.
Have you found a compelling reason why we should use other than just
the public key identifier?
Steve Dusse
RSA
===========================================================================
Date: 09 Dec 1994 14:44:00 CST
To: Jueneman(_at_)gte(_dot_)com
cc: pem-dev(_at_)tis(_dot_)com
From: Paul_Lambert-P15452(_at_)email(_dot_)mot(_dot_)com
Subject: Re[2]: voting
I agree with the comments that the current MIME-PEM draft may set
back the deployment of PEM.
A number of the more significant issues that have been holding back
the wide scale deployment of PEM are still not resolved, the
support infrastructure is still lacking and perhaps not even
understood, and we seem to be retrogressing. Two years ago, I
thought we were about one year away from effective, commercial
grade implementations of encryption and digital signatures. Now I
think that we are two or more years away from our goal, and things
are getting worse, not better.
Many of the technical changes in MIME-PEM (versus RFC 1421) are
useful improvements, but "opening the door to new trust models"
complicates the industries work to field workable certificate
management systems. The numerous options within MIME-PEM will also
delay the fielding of interoperable systems.
Suggestions:
- Reduce the number of MIME-PEM options (remove most of the
identifier forms)
- Document a suggested trust model (maybe several if necessary).
Paul