[OpenID] Signing method for XRD

[John Panzer]

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/8d43874b/attachment.htm>