Open Stack

On Thu, 2013-04-25 at 15:38 +0100, David Chadwick wrote:
> 
> On 25/04/2013 14:51, Simo Sorce wrote:
> > On Thu, 2013-04-25 at 09:20 -0400, Davanum Srinivas wrote:
> >> Simo,
> >>
> >> Nice! feedback after a quick browse and compare with xml-dsig
> >>
> >> 1. Can we please allow additional algorithms? (see DigestMethod in
> >> [1]). HMAC-SHA-256 can definitely be the default
> >
> > Well as a principle I like keeping security code *simple* and well
> > defined, at least for an initial implementation. We might add additional
> > metadata in the future to specify different algorithms, but I would see
> > that as an additional feature to allow in the future.
> 
> I think you should differentiate between the code that implements 
> different algorithms, and the mechanism that is used to choose between 
> algorithms.

The problem is that crypto is hard, and considering all the implications
of how algorithms interact is something few can master.
so I tend to subscribe to the cabal :) that wants to dictate a very
strict set and not give much choice to the implementer when it comes to
how crypto is handled.

So my question really is: why do you want choice in this matter ?

>  The initial implementation should not be hard coded with any 
> specific algorithm, but should have the mechanism for choosing between 
> algorithms built into it from the start,

I object in principle to this :)

>  even if the initial 
> implementation only supports one algorithm. It then becomes relatively 
> straight forward to plug in new algorithms.

Yes, which is not necessarily a good thing. I am not saying we will not
end up doing this, but I want to hear a good reason for allowing
non-experts (ie the users or the packagers) choice in this matter.

The more options you add the more avenues of attack you add ...

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York