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