[OpenID] Signing method for XRD

[John Bradley]

Good feedback.

I will see if we can code up some test signed XRD on test-id.net with  
the other openID tests I have.

We have a couple of people working on sample canonicalization for PHP  
etc now.

John B.


On 16-Jun-09, at 12:49 PM, John Panzer wrote:

> Thanks for the background and info.  My concerns still remain about  
> requiring both servers and clients (and all the libraries they  
> depend on) to implement canonicalization properly in order to both  
> generate and verify signatures.  The problems that OAuth has had  
> with people trying to rely on differing library implementations of  
> escaping and (basically) canonicalization of URLs makes me very wary.
>
> One suggestion would be to actually implement and deploy just this  
> piece in many real environments to see what issues arise.  Don't  
> worry about syntax or semantics except for this bit; just fire up a  
> test suite of {Java,PHP,C++,Python,Ruby,Perl,...} clients and  
> servers and see what issues arise when just seeing if the signature  
> can be verified.  See what common bugs are reported.  Deploy these  
> on various environments to see what deployment issues arise (hosting  
> providers not allowing native library installations, etc.).  It's a  
> fair amount of work of course, but it would mitigate a lot of risk,  
> and would provide a good basis for later interop testing as you know  
> they can all at least read, parse, and verify signatures from each  
> other's data.
>
> On Mon, Jun 15, 2009 at 11:55 AM, John Bradley <john.bradley at wingaa.com 
> > wrote:
> ...
>
>
> It's true that it's more work to handle 2 pieces of data separately,  
> transport them, store them, etc.  On the other hand the signature  
> really is metadata about the document and there are often good  
> reasons to separate the two.  The signature is also optional in all  
> the proposals I've seen.  And getting embedded signatures right  
> seems like it's significantly harder than getting detached  
> signatures right (based on prior discussions and feedback).
>
> With the fully detached signature we need to treat the XRD as a  
> binary object, base64 encoding it etc if it is to be preserved.   
> That potentially makes life harder if it is also used by non  
> signature aware apps.
>
> Non signature-aware apps don't care whether it's been binary- 
> preserved or not, right?  Usually a don't-care makes things easier,  
> not harder.  If you mean that we need a different transport to  
> prevent hop to hop proxies from munging things -- I think that a non- 
> XML content type would be a very, very minor speedbump.
>
>
>
> The nice thing about the XML signature approach is that non  
> signature aware apps can just ignore the signature and don't need to  
> do anything special to preserve it.
>
> I think this is a feature of all of the proposals, right?
>
> Note that non signature aware apps are highly likely (IMHO) to munge  
> the XML, even if they don't drop the signature, so that the  
> signature becomes irrelevant and possibly somewhat annoyingly wrong  
> (it fails, which looks like somebody is hacking, when the right  
> answer is "this document has been munged").  This may be more of a  
> concern with feeds, which get syndicated, than with XRDs, which  
> presumably don't.
>
> (Is there a way to provide better debuggability of canonicalization  
> issues with a new DSig scheme without causing security problems?)
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090616/6a3ccb9f/attachment.htm>