Re: Proposal for XRD 1.0 signing to use constrained XML dSig

[Dirk Balfanz <balfanz@google.com>]

Hi guys,

a few questions before I can have an educated opinion:

(1) What's wrong with
http://wiki.oasis-open.org/xri/XrdOne/XmlDsigProfile? (I'm guessing
the answer is something like "different parts of the document need to
be signed by different people", but I was wondering whether someone
could point out a use case where this is necessary)
(2) I don't know anything about XML dSig, Q-names, SAML profiles,
etc., so I was wondering what the actual proposed (adopted?)
canonicalization/signature method is.
(3) My (limited) experience with OAuth tells me that canonicalization
is hard. Do we have some library somewhere that implements this, or do
we have multiple libraries, written in different languages by
different people, that actually interoperate?

Ok, the last one is more of an opinions, I guess:

- incorporating a SAML library for the purpose of getting the SAML XML
dSig mechanism into our step2 library (which does some
proof-of-concept XRDS signature verification) would probably have been
more work than the two lines of code it takes to generate and/or
verify the signatures without any canonicalization (see
http://wiki.oasis-open.org/xri/XrdOne/XmlDsigProfile).

Dirk.

On Thu, May 28, 2009 at 6:09 PM, Drummond Reed
<drummond.reed@cordance.net> wrote:
> Eran, Brian, Dirk, Breno, Ben (and any other XRI TC members who were not
> able to attend today's telecon):
>
> Thanks to Scott Cantor's input, those of us who attended today's call (Will,
> John, Peter, and myself) all ended out agreein that we should adopt a
> constrained version of XML dSig enveloped signatures as the signing
> mechanism in XRD 1.0.
>
> Please read through the minutes on this topic (excerpted below) and let us
> know: a) if you agree with this approach, and b) if you have any other
> questions or concerns.
>
> As this is the last big outstanding issue, we'd like to close this soon so
> we can have a complete Working Draft 02 within the next week.
>
> Thanks,
>
> =Drummond
>
> ******* EXCERPT FROM TODAY'S MINUTES *********
>
> 2) XML DSIG AND XRD SIGNING METHOD(S)
>
> The thread on the mailing list that currently ends with...
>
>        http://lists.oasis-open.org/archives/xri/200905/msg00045.html
>
> ...includes this excerpt from the last message:
>
> "[Will has] been talking with Scott [Cantor] about this a bit the last
> couple of days as well, and he's indicated a way of doing XML Signatures
> without needing to do full c14n [canonicalization].  I didn't entirely
> understand all of it (maybe some of you are already familiar with it), but
> have pasted his response below.  He's volunteered to join the TC call
> tomorrow if we want to pursue this further.  If we can find a way to do XML
> DSig in a way that is reasonably supported among the major programming
> languages, it would make this whole thing much cleaner (not having four
> different ways to deliver the signature)."
>
> Because he had to leave early, John began by advocating that we need as
> simple and strong of a signature method as we can get.
>
> Scott explained that the W3C XML dSig WG is looking at doing a 2.0 spec due
> to performance and canonicalization issues. A new proposed spec has not been
> drafted but the discussion is moving in a good direction. It looks like it
> will be "plug-compatible" with existing implementations.
>
> In this new 2.0 spec, there would be a subset of the XML dSig spec that
> would be appropriate for simplified signing of XML documents like XRDs.
>
> Scott feels that if there are sufficient constraints in place on the XML
> that is going to be signed, sufficient optimizations can be made to keep
> implementations much less complex and support adequate performance. In
> particular, he said that if you are just signing subtrees, canonicalization
> can be very straightforward.
>
> Another advantage to this approach is that XRD signing would be compatable
> with existing XML dSig implementations, requiring no new coding in
> applications that used them. In places where XML dSig implementations are
> not available, an implementation under these constrained conditions can be
> much simpler than a generic XML dSig implementation.
>
> Will asked whether these more narrow requirements are already profiled
> somewhere. Scott said yes, the SAML profile of XML dSig, which uses the
> enveloped signature option, already meets these constraints, and should be
> able to be referenced as is by the XRD 1.0 spec. Scott also believes that
> the IMI 1.0 (Information Card) spec uses a similar profile.
>
> John noted that he was also in favor of this approach because compatability
> with the SAML libraries is a benefit to adoption.
>
> Will is in favor because this approach would reduce four methods for signing
> an XRD to a single method, which has obvious benefits with regard to
> interoperability and reduced implementation complexity.
>
> Scott explained that biggest single factor in avoiding XML dSig complexity
> is avoiding Q-Names in our schema. We can also further reduce signature
> complexity by adding constraints such as requiring attribute ordering. He
> also noted that we need to add an ID attribute on our root element.
>
> Drummond asked whether XRD extensibility will be an issue. Scott said no;
> the fact that XRDs are extensible should not present a problem to achieving
> this simplified XML dSig capability. We can still publish guidelines and
> best practices for extensions.
>
> There is consensus among all the attendees on this call that using the SAML
> profile of XML dSig, together with constraints in the XRD spec that enable
> this profile to avoid common XML dSig problems, appears to be the best
> solution to XRD signing.
>
> We then discussed how to move to full TC-wide consensus on this decision.
> The general steps are:
>
>        a) Publish these minutes.
>        b) Send a special note to the list highlighting the proposal for TC
> members who were not on the call.
>        c) If we achieve TC-wide consensus, move to discussing it with other
> related communities, such as OpenID and OAuth.
>        d) If necessary, research support for simplified XML dSig in all the
> relevant platforms (this is the step that might need explicit funding).
>
> # DRUMMOND to post the minutes followed by a special email to the list
> regarding this proposal.
>
>
>
>