[PROPOSAL] Removing SIGNALL From Draft 10

[Dick Hardt]

+1 assuming that we solve the multivalue parameter issue somehow. See:
	http://openid.net/pipermail/specs/2006-September/000139.html

Agree with security issue. Motivator for it was support for multiple  
parameters of same name.

-- Dick


On 29-Sep-06, at 2:47 PM, Granqvist, Hans wrote:

> +1 on removing SIGNALL
>
> There are significant security risks with "signing unseen data",
> which SIGNALL in effect allows. Such chosen plaintext attacks can
> be devastating to protocols.
>
>
>> -----Original Message-----
>> From: specs-bounces at openid.net
>> [mailto:specs-bounces at openid.net] On Behalf Of Recordon, David
>> Sent: Friday, September 29, 2006 11:39 AM
>> To: specs at openid.net
>> Subject: [PROPOSAL] Removing SIGNALL From Draft 10
>>
>> While I know this was added in draft 9, I'd like to readdress
>> it as I'm concerned from a technical perspective.  My
>> understanding of the motivation was to allow a Relying Party
>> pass arbitrary key/value pairs to an IdP and have them passed
>> back in the signature.  I believe that this, minus the
>> parameters in the response being signed, can be achieved via
>> the "return_to" parameter.  This is a URL generated by the
>> Relying Party for where the Identity Provider should redirect
>> the End User upon authentication.  It thus can be used by the
>> Relying Party to maintain state between requests.
>>
>> My concerns:
>> 1. There is no manifest for the fields that get signed, which
>> makes it more vulnerable to certain kinds of attacks, if
>> weaknesses are found in the MAC generation algorithm.  This
>> could be corrected by using a signed list that used full keys
>> instead of leaving off the "openid.", but see (2).
>>
>> 2. The entire query becomes part of the OpenID message,
>> rather than just the prefixed fields. As I remember it, the
>> original motivation for using prefixed parameters was to
>> avoid collision with existing parameters of any applications.
>> Signing these parameters mixes them in with the
>> authentication request or response. One of the nice things
>> about OpenID 1.x is that it's really clear which parts of the
>> HTTP messages are OpenID-specific; I'd like to preserve that.
>>
>> Thoughts?
>>
>> --David
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>