Does this problem exist if SIGNALL goes away? Hans
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Barry Ferg > Sent: Tuesday, September 26, 2006 3:52 PM > To: specs@openid.net > Subject: Request for comments: Sorting fields in signature generation > > We have encountered a situation in which the signature > generation method outlined in draft 9, section 7.1 is > insufficiently specified, and would like to solicit feedback > in order to build a consensus to amend the specification in > future drafts. > > Motivation: > > Pass-through (or "echo") parameters and potentially some > OpenID extension parameters may include fields with multiple > values in order to communicate arrays of data, etc. This > means that field names would be duplicated, each instance > having a distinct value. The current sorting algorithm does > not sort based on both names and values, so multiple equally > valid signatures may be generated for such a message. > > Solution: > > The signature generation algorithm specifies that the fields > to be signed be ordered in byte order form. It seems to be > implied that the ordering is based on using the field names > as sorting keys. We would like to have the specification > updated to explicitly state that the ordering is based on the > field name, followed by the field value in byte order form. > This enhances the signature generation method to > unambiguously handle name-value pair sorting. > > Tightening up the signature sorting method in this way will > have no impact on the existing authentication core protocol. > This assertion may be further strengthened by extending the > specification with clauses to ensure that existing parameters > be single value only. > > Objections: > > When this issue was raised privately, resistance was > encountered because of possible implementation difficulties > in some versions of PHP. While we recognize that this may be > an issue, note that: > workarounds do exist for the problem of multi-valued POST > parameters in PHP, and as outlined above, the proposed > changes should have no impact on the core protocol. > > > We welcome your comments! > > _______________________________________________ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs