Request for comments: Sorting fields in signature generation

[Granqvist, Hans]

Does this problem exist if SIGNALL goes away?  

Hans
 

> -----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.
> 
> 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 at openid.net
> http://openid.net/mailman/listinfo/specs
> 
>