[CAP] Then Again... (was Re: CAP SecurityUsingDigitalSignatures)

[matt hoffman]

I agree with both sides here.  One option seems architecturally kludgy
(storing the original form of the message separately) and the other requires
canonicalization, which is a series of kludges to begin with.  But it all
seems to hinge on the state of XML canonicalization, and the tools that
implement it ... a brief glance around the current Java landscape inspires
some confidence (it's now in the standard Java distribution and passes the
W3C's tests:
http://www.w3.org/2007/xmlsec/interop/xmldsig/c14n11/report.html ) as
opposed to a year and a half ago, but I see only Java tools on that report.
Brian, or other implementers -- what languages are you working in, and do
you see valid C14N candidates there?
It seems relatively simple to work up a test, if people have a couple hours
to devote to it.


Matt


On Thu, Mar 12, 2009 at 7:43 PM, Art Botterell <acb at incident.com> wrote:

> On Mar 12, 2009, at 3/12/09 4:16 PM, Russo CTR Brian T wrote:
>
>> It just strikes me as absurd and incredibly klunky.
>>
>
> I don't disagree... and if folks out there have confidence that the current
> crop of XMLSIG tools can canonicalize and verify successfully, then we can
> move ahead with smiles on our faces.  I just kept hearing horror stories of
> folks crying "Run away!" because they got frustrated by C14N's brittleness
> and couldn't get past it to the benefits of D-SIGs.
>
> Then again... once an alert has been verified on receipt, I'm not sure
> there's always a lot of need for the signature to persist in a local data
> structure... not unless the node plans to archive or forward it, in which
> cases it would simply retain a full copy of the original instead of just the
> signature.  Not entirely elegant, but not a crushing burden, either...
> particularly not if the alternative doesn't work!
>
> Anyway, the reason I suggested a "null" canonicalization was so we could
> plug in other C14N schemes later without putting an unstable component on
> the critical path to success.
>
> But if that's not necessary, by all means let's not do it that way!
>
> - Art
>
>
> _______________________________________________
> This list is for public discussion of the Common Alerting Protocol.  This
> list is NOT part of the formal record of the OASIS Emergency Management TC.
>  Comments for the OASIS record should be posted using the form at
> http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency
> CAP-list mailing list
> CAP-list at lists.incident.com
> http://lists.incident.com/mailman/listinfo/cap-list
>
> This list is not for announcements, advertising or advocacy of any
> particular program or product other than the CAP itself.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.incident.com/pipermail/cap-list/attachments/20090312/1aaa21b7/attachment.htm>