On 3/5/08, Ian G <iang(_at_)systemics(_dot_)com> wrote:
Andrey Jivsov wrote:
> My thoughts on MAY were that since this spec is MAY in relation to
> RFC4880, the explicit MAYs on defined or otherwise referenced algorithms
> are redundant. If we define a curve and don't list it as SHOULD or MUST,
> I assumed that it follows that it is MAY.
To me as an implementor I want to see what the defined sets
are. Commentary or definition on curves may be all very
interesting, but I would want to see the MAY set to
understand what the recommendation was.
from my querying of it, I hope it is clear that I would also like
to specifically see the (e.g.) ECC384 curve stated as a MAY.
And, just to justify this (and to show why 4880 is so readable):
9.1. Public-Key Algorithms
Implementations MUST implement ... SHOULD implement ...
* Implementations MAY implement any other algorithm.*
9.2. Symmetric-Key Algorithms
Implementations MUST ... Implementations SHOULD ...
... need to ... *Implementations MAY implement
any other algorithm.*
9.3. Compression Algorithms
Implementations MUST ... Implementations SHOULD ...
... *Implementations MAY implement any other algorithm.*
9.4. Hash Algorithms
Implementations MUST implement SHA-1. *Implementations
MAY implement other algorithms.*
I'd assume other
other implementors were also thinking around those MAYs. If
the question came up, I'd want the team leader to say
"implement only MAYs." She doesn't want them to go beyond
the clear compatibility consensus.
The code implementations take on a life of their own ... any
signals to reduce confusion and tie the implementations
within some distance of a common goal are good. A strong
MAY set is clearly something we should do if we are looking
for a complete implementation. In code world, nobody much
has time to do anything that doesn't lead to a clear
business imperative.
As a generalism, the people who implement the code know a
little crypto, but not a lot. They can't see very far.
They are employed for their good software skills, their
ability to turn specs into live code.
What to the crypto / institutional world may be elegence is
simply code to these guys. What might be a delicate path
through conflicting requirements is a nightmare to the
coders, they just don't know what was intended, and have
only each other to figure it out.
(Just another reason why agility is a nice idea in the
crypto tea room, but not robust in reality.)
iang