Re: [xri] xml dsig profile

[Brian Eaton <beaton@google.com>]

For the record, I agree that if we want to start having multiple
objects in a single XML object with different signatures, we should
use XML DSIG and be done with it.

I don't think that's a real use case for XRDs.

On Tue, Mar 3, 2009 at 12:32 PM,  =JeffH  <Jeff.Hodges@kingsmountain.com> wrote:
> Below's Scott's succinct summary of our rationale wrt the "SAMLv2.0 HTTP POST
> 'SimpleSign' Binding".
>
> =JeffH
> ------
> Subject: RE: [xri] xml dsig profile
> From: "Scott Cantor" <cantor.2@osu.edu>
> Date: Tue, 3 Mar 2009 11:39:50 -0500 (08:39 PST)
> To: "'Peter Davis'" <peter.davis@neustar.biz>,
>        "'Jeff Hodges'" <Jeff.Hodges@KingsMountain.com>
>
> Peter Davis wrote on 2009-03-03:
>> the XRI TC is looking at variations of the simple-sign work done for
>> the SSTC, and I have suggested that we should not introduce a new
>> model unless we are very compelled to do so.
>
> Unless you're working with a messaging model in which you're just trying to
> sign essentially everything you're expressing in XML, I doubt that it's a
> good model. Something that has to be composed of different pieces and
> potentially include signed objects and unsigned objects within the same
> document, which strikes me as a need for things like XRDS, probably needs to
> use XML Signature.
>
>> Can you provide any background wrt the model you choose
>> (optimizations, work-arounds, deployment experiences) that i can
>> reflect back to the XRI TC?
>
> I have no deployment experience with it. Far as I know, only AOL has used it
> a bit. Generally when people reject XML Signature, they've also rejected XML
> to begin with, and being able to solve the signing problem just changes the
> excuse they use.
>
> The model we chose was really to address two issues:
>
> - avoiding c14n as currently defined (note even for the "simple" spec, we
> had to go around a few times to come up with a workable signing model, so
> c14n is always a problem, even when you deal with data as a blob)
>
> - expressing the signature without using the ds:Signature element, because
> there's no way to build a signature Reference to a set of form elements in
> an HTML page
>
> The goal we had was to sign messages bound to HTML forms, so that didn't
> leave much in the way of existing options. I've raised that point with the
> W3C working group. I think it would be better if we could build references
> to parts of IETF protocol messages such as HTTP but still reuse the
> ds:Signature element and reference model. At the moment, that's pretty
> impossible to do.
>
> We weren't trying to solve the more general signing problem OAuth took on,
> but clearly one could reuse that piece of OAuth (which shouldn't be part of
> OAuth to begin with) to handle this kind of signing.
>
> In terms of implementing this, you need essentially all the same crypto
> dependencies you would need for XML Signature, and you end up calling into
> the raw PKCS1 signing code that the signature library would be using.
>
> We reused the ds:KeyInfo structure so that key material expression was
> consistent between XML and Simple signing in SAML.
>
> My impression from my participation in the W3C group right now is that they
> "get" the problem. Nobody is happy with c14n as currently defined, and
> there's a serious proposal [1] right now to essentially start over with a
> simpler spec. If that happens, I believe it would be a mistake to continue
> with these workarounds.
>
> -- Scott
>
> [1] http://www.w3.org/TR/2009/WD-xmldsig-simplify-20090226/
>
> ---
> end
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>