RE: [xri] Re: Constrained XML dSig decision (was RE: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-06-04)

["Drummond Reed" <drummond.reed@cordance.net>]

Nat,

So to sum it up, what you are saying is that option (A), which would be
specifying own as-simple-as-possible XRD signing method, may be a better
option than (C), the constrained XML dSig profile.

That's a completely valid viewpoint. (I'm assuming you are rejecting (B),
which is to try and do BOTH (A) and (C), because that's the most complex.)

So how do you propose to proceed with option (A)? Of the various proposals,
is there one specific super-simple-signing-proposal that you have in mind?

How can we determine as quickly as possible if: a) that one method will work
for the different scenarios that have been discussed, and b) that it can be
implemented pretty much anywhere in an hour or two? (Note that Dirk
mentioned the same thing on the last call, so maybe you and Dirk have the
same type of thing in mind.)

=Drummond 

> -----Original Message-----
> From: Nat Sakimura [mailto:n-sakimura@nri.co.jp]
> Sent: Tuesday, June 09, 2009 12:09 AM
> To: Drummond Reed; 'XRI TC'
> Subject: [xri] Re: Constrained XML dSig decision (was RE: [xri] Minutes:
> XRI TC Telecon 2-3PM PT Thursday 2009-06-04)
> 
> 
> 
> --------------------------------------------------
> From: "Drummond Reed" <drummond.reed@cordance.net>
> Sent: Tuesday, June 09, 2009 1:41 PM
> To: "Sakimura Nat" <n-sakimura@nri.co.jp>; "'XRI TC'"
> <xri@lists.oasis-open.org>
> Subject: Constrained XML dSig decision (was RE: [xri] Minutes: XRI TC
> Telecon 2-3PM PT Thursday 2009-06-04)
> 
> >> > Drummond Reed wrote;
> >> >
> >> > Following are the minutes of unofficial telecon of the XRI TC at:
> >> >
> >> > Date:  Thursday, 04 June 2009 USA
> >> >
> >> > Time:  2:00PM - 3:00PM Pacific Time (21:00-22:00 UTC)
> >> >
> >> [...snip...]
> >>
> >> >
> >> > # DECISION: For XRD signing, we will proceed with option A, "XRD
> >> > Signatures", a constrained profile of XML dSig as defined by SAML
> Core
> >> > Section 5.
> >> >
> >> Nat wrote:
> >>
> >> I actually did not fully agree to this one.
> >> I still think that we need to test the water at various communities for
> >> both "complexity" and "performance" before making this decision.
> >>
> >> [...snip...]
> >
> > Nat, I understand that not everyone is completely comfortable with this
> > decision yet, and I was careful to note that the next step is Will
> adding
> > this text to the next Working Draft, which still needs review before a
> > Committee Draft vote.
> >
> > But the point I made several times on the call is that we have been
> > discussing this for six months now and it's time to "fish or cut bait".
> In
> > other words, the case for picking one method -- the constrained XML dSig
> > profile -- and going with currently enjoys the most support of any
> > alternative we have looked at. If anyone wants to make a different
> > proposal
> > for something simpler, then the decision tree becomes:
> >
> >  A) Adopt new proposal only (and give up XML dSig compatability)
> >  B) Adopt BOTH new proposal and constrained XML dSig profile
> >  C) Reject new proposal and just stick with constrained XML dSig profile
> >
> > The cost of (A) is that everyone who wants to process XRD signatures
> will
> > need to implement the new signing method, even if they already support
> XML
> > dSig. That's a pretty high cost.
> 
> I am not so sure about it.
> As some people in the TC noted, the non-canonicalization method is
> pretty trivial to implement. It should not cost more than 1 or 2 hours.
> This is much cheaper than compatibility headaches that many of us has
> run into with XML Dsig in the past. Hopefully it is not the case anymore,
> but I have not seen any evidence. Note that the document that was sited
> a few weeks ago are old documents that we evaluated long time ago.
> 
> That's why I am keep saying that we have to test the temperature level
> of the communities.
> 
> >
> > The cost of (B) is that now there will be two ways to to XRD signatures,
> > and
> > now everyone adoption XRD signatures will need to deal with the
> increased
> > complexity and interoperability issues of multiple signature options.
> > That's
> > a pretty high cost.
> 
> I am not so sure about it. Non-canonicalization method, especially
> base64ed
> inline version is pretty bullet proof when it comes to the signature
> verification.
> As it is quite trivial to implement it, it is not much more of the cost.
> 
> >
> > By itself, this don't automatically mean we should choose (C). But it
> does
> > mean that the new proposal MUST be so compelling that it is worth going
> > down
> > either path (A) or (B).
> 
> You know, the option (C) is essentially the same as the Trusted Resolution
> of XRI 2.0. It is actually using the constrained XML DSig of SAML core.
> Has anybody implemented it?
> 
> We need a reality check there.
> 
> From the point of view of a spec writer, sticking with XML DSig is
> very attractive. When you flip your point of view to the community
> implementers, the way it looks may be completely different.
> It should be able to be implemented in various scripting language
> on a hosting account with very limited capability to modify the system.
> Also, we should be looking at supporting old
> 
> What I want to make sure is the situation that people do not use
> signed XRD.
> 
> >
> > So far, I haven't heard anyone saying that the constrained XML dSig
> > profile
> > is inherently either too complex, or has serious performance issues.
> I've
> 
> Well, that's what I have been hearing from bunch of community
> developers in the past. e.g., if the system is still using Java 4,
> JCE lacks some functionality and it is not so easy to use XML DSig.
> 
> Also, Wikipedia sites the performance issue :-)
> I am not buying that, but I need to double check.
> 
> > only heard that it is possible that implementations with adequate
> > performance MAY not be available in certain communities yet. If so,
> Will's
> > point on Thursday's call was we don't so much need to "test the waters"
> as
> > simply help figure out how the necessary libraries that provide
> sufficient
> > performance can be provided in those communities.
> 
> This may not be as easy as we might think.
> How do you provision those to the hosting environments?
> That's the kind of questions that we should be asking.
> 
> >
> > Do you agree with this analysis? Or do you think we should continue to
> > look
> > at options (A) or (B)?
> 
> Yes. I think it still is premature.
> We should do a quick survey on the communities.
> 
> >
> > =Drummond
> >
> >
> 
> ---------------------------------------------------------------------
> 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