Will Price wrote:
This forum is indeed narrowly technical, should remain narrowly technical,
this discussion is inappropriate for this forum, and if you want to discuss
it please take it to the many other lists that would be more appropriate
such as the cypherpunks list. We are jumping *way* ahead of ourselves by
discussing it at all at this time on this list when we don't even have a
draft spec yet. There will be ample time to discuss this later in the
context of OpenPGP when issues like this become relevant and after all the
hypotheses about it have been cleared up and people have actually tried the
product rather than making false assumptions.
The problem is, as Bill Frantz wrote:
Just a quick reality check here. Frequently implementations have proceeded
IETF standards.
Would PGP seriously stand for 'their' standard being incompatible with
their latest product (PGP 5.5)? If the finished OpenPGP standard rejects
their GAK compliancy fields, will they remove them from the product?
Even more practically, how hard will PGP fight against proposals from
others to do so? Is it fair that they should use their reputation,
corporate weight and 'look we've already implemented it' to do so within
an IETF working group?
Will Price is right: "we don't even have a draft spec yet". Will this
draft spec include the CMR fields? Ian Grigg asked that they forget
these contentious issues for now and just release the PGP 5.0 spec,
without the CMR. I'm unclear as to whether PGP 5.0 already supports CMR.
Ian answered the question in the original post.
I think this
debate is raising issues that threaten the integrity of the process,
so a fullsome and noisy debate on open-pgp is unavoidable.
This is something we need to sort out quickly. PGP Inc do as well, if
their "commitment to open standards " (J. Seybold) means they will have
to withdraw PGP 5.5 if the IETF group rejects their CMR proposals and
they want "an open and completely interoperable international standard."
Ian.