Adam Back wrote:
Ian Brown <I(_dot_)Brown(_at_)cs(_dot_)ucl(_dot_)ac(_dot_)uk> writes:
"Additional request recipients" - as this is still such a controversial
topic, I don't think it should be included in this first version of the
standard.
Seconded.
Please let's concentrate on the core functionality without dragging in
controversial "message recovery" features.
I must have missed the start of this conversation.
I think there has been a lot of discussion on the issue. When the CMR
thing hit the mailgroups, traffic jumped from about 2 a day (on this
group) to something like 10 per day (on the subject, that I recorded).
It would appear that community remains split on this issue, with the
mostly PGP Inc-led proponents squaring off against the mostly Cypherpunk
crypto-programmers. This is highly unusual. Normally, technical
discussion results in consensus on these forums, as one would expect
when one puts many highly expert voices into one confined space.
I would suggest that nobody could deny the controversiality of the
ARR/CMR feature.
If we accept the controversy as something we must deal with, then there
appear to be several options:
1. Document the feature, and include views on the
pros and cons, in order to guide the future programmer.
2. Document the feature and say nothing.
3. Propose an alternative.
4. Stay silent.
The first option means that we have an opinion, and we have to express
it in words that will survive the critical assessment of generations of
coders. I judge this as too difficult; if there is no consensus in the
community, and by extension, no consensus in the WG, then we have no
opinion. Further, to write such an opinion will require an unbiased
editor, and we have none such.
The second, then, avoids the opinion and simply leaves the programmers
to pursue at their discretion. Such a tactic would seem innocuous, but
is in fact more insiduous than that. Programmers and managers tend to
avoid politics. Whilst those here are well versed on the topic, and
other in the core crypto community are equally capable of making an
independant judgement, not so the rest of the community.
Programmers, designers and managers alike look to and IETF standard as a
document of guidance. They have neither the time nor the patience to
pursue subtleties as they pursue the race to market. If the feature is
in there, it will be coded up. The appearance of the feature in the
standard is an open and solid endorsement by the WG of the merits of
this feature. Coders will give the WG its due.
I am guessing that the WG is not happy with silent endorsement of the
AAR feature. If it is, then the debate has not shown it, IMHO.
Proposal of an alternative is technically plausible, but not appropriate
in this forum. We are standards body, seeking to take existing good
protocols, tidy them up into a single document and all agree to use this
single document. Whilst there are many ways in which we can address the
general class of issues in mind, they are all experimental, and it is
not our job to sit here and write the methods in advance of market
acceptance. That latter approach is the forte of the ISO standards
committeess, which have not been shown to be a huge success.
That leaves us with the fourth option. Say nothing and do not document
it.
This of course will be problematic for programmers, as they test their
code against 5.x, and discover the strange packets. I don't however see
this as a problem, as there is little to stop PGP Inc from publishing a
separate document which can become known. As the programmers are coding
up the pgp code, and as this feature is only used by PGP Inc code, they
know where to ask.
One could say a lot more about the difficulties of ignoring a feature in
the standard. I've found some objections, such as existing code,
conformance with the code base, need for such a feature, and I don't
think they are sufficient under this most exceptional of circumstances.
I plumb squarely for the fourth option. Say nothing.
In summary, I think that the WG can attempt to describe the pros and
cons, but we have no obvious means for doing that. Or we can simply
document, at the cost of endorsing the feature as a WG supported
method. We are not in a position to start hacking in new ideas.
Or, we can simply say nothing and leave the feature as a new, untried
idea by one commercial venture in the marketplace for Open PGP product.
6.2 - I know the inclusion of ROT-n started as a joke - but it's in
there! Eeeek!
I thought Jon was joking about these! Remove at once please!
Yes, there should be no weakness. I know ROT-n is a joke to some, but
if Caeser used it, then so can others. If a test case is needed, it
should be plain and open. Not that I think one is.
--
iang systemics.com
FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com