Re: ECC in OpenPGP proposal

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.  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