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

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

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