On Mon, 29 Jun 1998, Paul Hoffman / IMC wrote:
At 05:16 AM 6/29/98 -0400, dontspam-tzeruch(_at_)ceddec(_dot_)com wrote:
Because all these terms have no meaning to the end user, and probably not
to many of the implementors.
Well, end users won't be seeing this stuff if the implementors do it right.
If the implementors don't understand the terms, we're in deep trouble.
It doesn't matter if I understand the difference between MUST, SHOULD and
MAY if there is ambiguity or contradiction in what I must, should or may
implement. Implementors can "do it right" but still not interoperate
because there is more than one way of doing it right. Most, if not all,
of the problems occur in the MAY sections of the specification.
The problem is not that the MAY algorithms are MAY, it is that many aren't
well enough defined to implement unambiguosly, but when I point the
implementation interoperability problems out the response is to the effect
that it doesn't matter *because* it is a "MAY".
I assume that RFC 2119 does not imply that "MAY" means that if implemented
"correctly" you can still have diverse noninteroperable implementations of
whatever is covered in the MAY. I thought it only said there was
nothing wrong in leaving something out, although that something should be
clearly defined.
Compression is a MAY (2.3), but ZIP is a SHOULD (9.3)? But at least there
are no ambiguous algorithms, so if I do compress, I must use one of two
algorithms in the manner detailed in other RFCs (except to limit the
window size to interoperate with PGP 2.6). If I want to use bzip2, it is
experimental and I don't have to worry about if the block size is 100k or
900k. If there was a compression algorithm "3 - BZIP2" it would need to
specify the minimum compression block size and any other parameter which
might affect interoperability. But in other areas things are less well
defined.
It is one thing if you do algorithm 6, and I do not, and such cases are
handled. It is a different thing if you and I do algorithm 6 in
incompatible ways, so that I send you a message using your preferred (MAY)
algorithm that you can't decrypt although both implementations are correct
as far as the spec says.
Take EC. It is a MAY (and you are going to add an RFC pointer for "MAY",
but not for "EC" - does one exist?). There is no detail about what the
order of the parameters used for the keys are. No two implementors are
likely to pick the exact same format. So although many implementations
might use EC, no two will be able to decrypt messages made by a different
one. But I still MAY implement EC. Any way I choose? It has been
suggested that HAVAL - which has two reference implementations and enough
detail to be useful - be deleted if it doesn't get an OID. EC has nothing
beyond an algorithm ID, so why keep it?
For something that cannot be unambiguously implemented, should it be
deleted or kept as a "MAY"? Everyone kept telling me that "It doesn't
matter that it isn't well defined and will be implemented 20 different
ways, don't worry, it is just a 'MAY'". So you can see where my semantic
confusion comes from. If MAY means what people are saying it means now,
then for any algorithms that lack either an RFC or other final
specification, and/or reference implementation, or cannot be implemented
correctly (e.g. hashes which lack OIDs) as of the close date, they should
be changed to "Reserved for XXX" or deleted entirely to prevent
impelmentation.
As I already pointed out, Blowfish was a MAY that already was implemented
two non-interoperable ways. I have caught many of these but doubt I have
caught all. And I may have gotten things wrong in what I already have
implemented. Remember that I have actually been using the spec to create
real code, and have generally succeeded. But at the same time I have
found pitfalls. I can interoperate with GNUPG and the PGP programs. But
in doing so I found things that weren't done in exactly the same way and
needed to be unified.
I can change lots of subtle things that would not violate the spec in any
way but not be interoperable. Now people want to delete things that at
least are well enough defined to implement, and add other things without
giving enough detail. When I warn about this the attitude is to shoot the
messenger.
--- reply to tzeruch - at - ceddec - dot - com ---