Request for comments: Sorting fields in signature generation
hgranqvist at verisign.com
Tue Sep 26 23:03:09 UTC 2006
Does this problem exist if SIGNALL goes away?
> -----Original Message-----
> From: specs-bounces at openid.net
> [mailto:specs-bounces at openid.net] On Behalf Of Barry Ferg
> Sent: Tuesday, September 26, 2006 3:52 PM
> To: specs at 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.
> 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.
> 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.
> 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 at openid.net
More information about the specs