John W. Noerenberg wrote:
...I expect to hear after the next IESG meeting (9/25) whether we're in
business .... for files and for email.
I know there are other things we need to tackle (PKI and Cert structure come
to mind). But other groups are also working those issues. In order to make
sure we get this group up and running, and to make sure we score some early
success, I would like to see us focus in on the packet structure, and use in
email. No group is currently handling those, so let's see how fast we can get
these two done.
I hear and concur. Fully, without reservation.
People,
PGP has taken us this far without a PKI, and without a certificate
structure. This is not to say that such potential enhancements are
not useful, but rather the beauty of PGP is that it can go *so* far
without such.
Let us consolidate what we have, in an open framework, in an Internet
spirit.
I believe that we need to take *existing* work and standardise it such
that developers across the Internet and across the world can produce
implementations that will deliver the privacy we need.
The need to deliver future works is pressing, and for this reason, I
would suggest that we need new teams, and new charters, and indeed, new
blood, to consider the difficult but necessary tasks of PKI, certificates,
and the like.
In doing so, I would also represent that such a mission necessarily
marches to a different drum, a different timetable. The need for a
standard commercial means of determining identity, or of non-repudiation,
or of value, is such that it cannot accept the same assumptions as those
that make the core of the PGP web of trust. The concepts that make up
the architecture of PGP were built on neighbourly trust, not commercial
transactions. Door-to-door community, and not commercial advertising.
So be it - we have a number of different issues on the table. I think that
most PGP hackers would agree that we can build the new requirements on top
of the base architecture. I believe this, as I have participated in such
projects. However, there is a fundamental difference between standardising
and building, between documenting and advancing.
The most pressing issue we have is the deployment of a standard in basic
packet communications. That is, in deploying a packet format that allows
all the various implementations of privacy communications to exchange
messages. Our task is only, in the short term, to define and standardise
what we can already do. So that implementors can produce the basic
framework that allows the future needs to develop. And so that builders
have a foundation upon which to build.
We need to document and standardise the *current* technology of PGP.
As far as I can see, there is only one short term decision. And even
this may already be taken, as I was not present at Munich. Is it PGP
2.6 or is it 5.0 ?
To my mind it is not important which. I am only here, in this forum, to
represent the interests of the Cryptix Development Team in producing a
stable crypto architecture based on the lead that has been provided by
past hackers. We, of the team, are looking for guidance, we do not
offer opinion on the goodness of the architecture, rather, we offer
crypto-labour and we wish to labour at this crypto.
It is unimportant that 5.0 is "PGP Inc" more than PGP, as long as the former
are willing to sign the former over to the latter. What is important is that
we have, as a community of Internet crypto coders, a single document that
describes the packets we will interchange.
Leave the flaws, the optional extras, the extras for later. Let's get the
defined PGP out there, and then let's look at building upon a solid, exising
definition.
OpenPGP charter:
An Open Specification for Pretty Good Privacy (OpenPGP)
October 1997: Submit first internet draft of OPEN-PGP key format and
message specification.
Today, by the posting of this email, is 0500, 19th of September 1997.
Therefore, there are about 2 weeks until October, or say 6 weeks inclusive.
We simply must choose one of two bases. We must choose the coding set.
And document it. There is no time for anything else.
iang