Re: [OAUTH-WG] Signature crypto

This case is interesting. 

Until recently I have also thought that one has to specify a
mandatory-to-implement algorithm in a security protocol since otherwise
interoperability would really suffer. When working in KEYPROV I learned
through Russ Housley that this is actually not true. 

He said:
"
Some specifications in the security area do not pick a mandatory to
implement algorithm.  RFC 5280 is one example.  Instead the companion
specifications tell what algorithm is appropriate for a particular
environment. 
"

There are a few reasons why you often cannot agree on a specific
algorithm. Examples are different usage scenarios that demand a certain
algorithm, certain software packages that may or may not support certain
algorithms at a specific point in time, different performance/hardware
requirements, IPR concerns, etc.

In any case it is likely that the chosen algorithm will get replaced in
a few years from now and one does not want to update the specification
every time. Hence, having some form of crypto-agility is generally a
good idea since you might want to negotiate a set of algorithms anyway
and it is quite likely that an algorithm is found that both parties
support. 

Ciao
Hannes

________________________________

	From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
Behalf Of ext Infinity Linden (Meadhbh Hamrick)
	Sent: 25 November, 2009 16:19
	To: Stephen Farrell
	Cc: OAuth WG (oauth@ietf.org)
	Subject: Re: [OAUTH-WG] Signature crypto

	+1 to stephen's comment. 

	when it comes to algorithm support and selection, i think the
consensus that's emerged is we should require an algorithm that "looks
good" at the moment the spec is being drafted, but allow the use of
other optional algorithms. ("looks good" here means that there are no
known successful attacks against the math of the algorithm and there's a
general consensus amongst cryptographers that there won't be one in the
next 20 years.)

	the rationale behind this may have to do with the experience
some implementers had with MOSS / MIME Object Security Services (aka
RFC1848.) MOSS was specified to address issues people had raised with
PEM (Privacy Enhanced Mail). The problem with MOSS is that it was near
infinitely flexible and you could create an implementation that strictly
adhered to the specification, but was non-interoperable if you chose to
support a different set of optional encipherment algorithms.

	so the concern here is that if you allow all hash algorithms to
be optional, you'll find some outlier who wants to use HAVAL with Rabin
Williams to generate signatures and will sell this solution into the
marketplace, then go out of business. people who bought the solution
won't think anything's wrong 'til they try to hook it up to someone else
who's using a more traditional SHA256+RSA or ECDSA solution. a great
wailing and gnashing of teeth will follow.

	but if we REQUIRE that everyone use SHA256 but allow other hash
algorithms, then we won't have this problem.

	-cheers
	-meadhbh

	--
	  infinity linden (aka meadhbh hamrick)  *  it's pronounced
"maeve"
	        http://wiki.secondlife.com/wiki/User:Infinity_Linden

	On Wed, Nov 25, 2009 at 05:52, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:

		Eran Hammer-Lahav wrote:
		> I think we have consensus that the spec should not
mandate a particular hash algorithm. This still leave the issue of
assigning algorithms short names for the purpose of negotiation and
declaration. Is there a registry available for such algorithms we can
use or do we need to create a new one?

		Sorry to have missed out on the thread where that was
discussed, but
		it'd be odd for an IETF security spec to not mandate
some algorithms
		and quite likely to generate comments later in the
process if there's
		no well-defined way to ensure interop. Do we have that?

		Ta,
		S.

		_______________________________________________
		OAuth mailing list
		OAuth@ietf.org
		https://www.ietf.org/mailman/listinfo/oauth