Re: ECC in OpenPGP proposal

["David Crick" <dacrick@xxxxxxxxx>]

On 3/5/08, Ian G <iang@xxxxxxxxxxxxx> 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