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

[Nat Sakimura <n-sakimura@nri.co.jp>]

I need a reality check before I make any opinion out of it.

(Well, we use XML Dsig everyday so I am personally ok with XML Dsig, but...)

1. List of supported libraries for each language.
    (Perl, PHP, Python, Ruby, Java4, etc.)
2. Opinion of the wider community.
    In the past, when I proposed XML Signature, I have had a surprising
    amount of resistance. We need to make sure this "allergic"
    response would not happen any more.

=nat

--------------------------------------------------
From: "Drummond Reed" <drummond.reed@cordance.net>
Sent: Friday, May 29, 2009 10:09 AM
To: "'XRI TC'" <xri@lists.oasis-open.org>
Cc: "'Eran Hammer-Lahav'" <eran@hueniverse.com>; "'Brian Eaton'" 
<beaton@google.com>; "'Dirk Balfanz'" <balfanz@google.com>; "'Breno de 
Medeiros'" <breno@google.com>; "'Ben Laurie'" <benl@google.com>
Subject: [xri] Proposal for XRD 1.0 signing to use constrained XML dSig

> 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.
>
>
>
>
> ---------------------------------------------------------------------
> 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
>
>