-----BEGIN PGP SIGNED MESSAGE-----
Bill Stewart wrote:
Realistically, PGP Inc. does get a bit of extra slack in OpenPGP.
Colin Plumb, Derik Atkins and the nameless others at PGP slaved for some
3 years on this codebase[1].
There are 110,000 lines of C code[2] in pgp5.0. Now, at 200 working
days and 10 lines per day, that's five and a half man years of effort.
Or, at valley costs of say 100k per programmer, that's a half a million
(ignoring the support costs, probably have to double that to be
realistic).
PGP Inc is getting a lot of slack cut by having their existing code base
validated.
Remembering that PGP Inc did not release any information about packet
formats until the release of pgp5.0 in paper form (feb this year?), and
then in July this year, the real online code was made available via
Stale's scanning effort. That means that any competitors, including the
people I work with, have had less than 6 months to catch up [3].
I had always assumed that the IETF had a strictly non-commercial role,
but this standards process, if it succeeds, amounts in economic terms to
an enourmous subsidy to PGP Inc [4]. I personally am prepared to accept
that subsidy on the grounds that the benefit to the community of a
standard RFC on Open PGP is something worth having.
Not being a shareholder in PGP Inc, and thus not a direct beneficiary in
the subsidy, I must contain my enthusiasm to that of being a stakeholder
in Open PGP. However, as a stakeholder in an open standard, I have yet
to see a convincing reason why any one competitor should receive
preferential treatment.
In particular, if the field really was defined in 5.0 (not necessarily
used, but defined), and probably even if it only appeared in 5.5,
then accepting key records containing it should be part of the standard,
though I strongly agree that any semantics of what to do about it
shouldn't be in the standard.
I am prepared to accept, in general, the pgp5.0 code being used as the
basis for this standard.
However, our purpose here is valueless and we would be negligent if we
did not scrutinise the decisions made in that code. If we make no
changes to the pgp5.0 base this would signal one of two things: that we
have not done our job, or that PGP Inc has done its job perfectly.
Obviously, the converse (that we make changes and have therefore done
our job) is not likely to hold either.
Changes can be expected. How PGP Inc wish to treat any changes is of
course up to them. Given the nature of the IETF subsidy, however, I am
continually surprised by the keenness with which PGP Inc pursues its
commercial agenda.
John W. Noerenberg wrote:
As much as possible, this discussion must remain apolitical and without
philosophical rants. We are here to make decisions about the
implementation of cryptographic messages. We must recognize that we may
disagree with some legitimate uses of cryptography. But if there is a
legitimate need, then we must seek to allow it.
This is of course the crux of the argument. There is a camp that
states, to paraphrase, that there is no legitimate need for this
feature. Indeed, they assert that there is a serious danger. I won't
review these arguments here, they are well recorded elsewhere.
The community is split on this issue. Split violently. PGP Inc are now
in the interesting position of having to accept the most severe
criticism from their root community. By severe, I mean, commercially
damaging, which is of course, their choice.
For this standards process to accept *either* viewpoint, by including
any mention of the issue, runs the risk of promoting or accepting some
arguments that the community itself has not accepted as a whole.
If we fail to do that
constituencies on which wide acceptance of this protocol depend will not
accept it, and it will fail to gain standard status.
True.
But to clarify, there will be limited acceptance if we *exclude* valid
or legitimate activity. By dropping mention of the CMRK subpacket, we
do not exclude its use. PGP Inc would be free to pursue this as a
commercial choice, just as they are doing now. In fact it would not
impinge them in their current commercial endevours one iota. Please
correct me if I have missed something here. Proponents of this method
or any alternative would also be free to promote an RFC that extends the
current work, which is arguably a more appropriate place for all of this
issue.
On the other hand, to include the CMRK subpacket will signal acceptance
of this. To avoid any such acceptance by the IETF, one would need to
insert strong verbage listing the dangers of such, and that is
unrealistic from any point of view.
In the current understanding of the community, the only plausible
alternative is to simply omit all mention of the CMRK subpacket from the
standard.
- --
iang systemics.com
FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com
[1] searching the code, there 455 C files. Plumb and Atkins get credit
in some 160 of those, and the rest were presumably written by the
various programmers at PGP Inc.
[2] I stripped empty lines and empty comments, and only *.[ch]
[3] Yes, we are currently working on the signature bug. At least if we
had a standard, we could work out who had the bug.
[3] BTW, the subsidy is not 1 million dollars, it is the cash flow
resulting from that investment over time. A better estimate is a
valuation of the PGP Inc company, but I don't know how much the current
investors value it at.
-----BEGIN PGP SIGNATURE-----
Version: Cryptix 2.21
iQCVAgUANFcnWJUdDk1bRs+FAQGdqAP5AcOFHovJynnlqp5XcOhWCkKUYZzDZZCB
NP+t5BsWmK3479OT3SYVF+XWO3jWYplDAEply75c2c6/GHdYqUK3w8w7BUKw2sOL
3j78IdoVUW80qq0lYLnQAQlA5rr7u1R8wU+xkhQlJkyPDbnQ/SoRbmEbxtmY+Noy
a+z7vESZQRE=
=qAJQ
-----END PGP SIGNATURE-----