Re: [OAUTH-WG] Signature crypto

[John Kemp <[e-mail]>]

Infinity Linden (Meadhbh Hamrick) wrote:

[...]

> 
> so the moral of the story is that if you don't mandate a required 
> algorithm, you'll get MOSS.

And is that, in practice, a problem for anyone?

[...]

> a. if we don't have a required algorithm somewhere, you will find that 
> OAuth users will select whatever algorithm set they like. many times, 
> they will choose algorithms that other people don't use. when they start 
> to want to interoperate with these people, there will be a mild gnashing 
> of teeth as the two parties make a pairwise agreement over which 
> algorithm they'll use. it's not the end of the world, but this sort of 
> pairwise algorithm negotiation will occur all over the place.
> 
> b. if you put required algorithms in a second RFC, distinct from the 
> draft defining OAuth mechanisms, you will quickly see someone write an 
> additional draft with a new set of required algorithms. you'll then have 
> a mild amount of confusion over which one should be supported, possibly 
> ending when everyone decides to support both. in this case, you might as 
> well have defined both as being REQUIRED.
> 
> c. if chaos looms for longer than it takes for a FLOSS developer to 
> reasonably apply support to PHP, Python/WSGI and Java, then you'll see 
> whatever algorithm choice that developer makes become the de facto 
> standard (because it's available everywhere.) if we're unlucky, that 
> developer will make their algorithm choice based on the 1996 edition of 
> Applied Crypto which does not have suitable exhortations for developers 
> to eschew MD5.
> 
> so... it's probably less about it being absolutely necessary to select a 
> required algorithm for the spec, and more about what kind of chaos can 
> we live with?

Yes, I'd say that might even be roughly the choice but put it in 
different terms:

What kind of interoperability do we want?

If an implementation is forced to implement a particular hash algorithm 
in order to be "compliant" with the specification when it won't in 
practice use that algorithm, I don't see that as very useful. Either 
implementors will say their implementation is compliant, or they'll say 
that their implementation is not OAuth (or RFCXXXX). How does either of 
those things help anyone?

As Hannes noted, if we require a specific hash algorithm then every time 
we need to change the MTI algorithm(s) we also need to update the 
specification.

In any case, I wouldn't really call it "chaos" just because there are 
multiple OSS implementations. I hope that people will develop tools that 
work for them. And I suspect that the most important parts of OAuth to 
standardize on are a) the protocol itself, b) the HTTP authentication 
mechanism and c) a method of negotiating the relevant twiddly bits, as 
necessary (and where it should be noted that "no signature at all" is 
potentially an acceptable signature algorithm).

- johnk