Request for comments: Sorting fields in signature generation
Barry Ferg
barry at sxip.com
Tue Sep 26 22:51:34 UTC 2006
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!
More information about the specs
mailing list