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

[Russo CTR Brian T]

If it's acceptable to remove the capability to deserialize objects and
require everyone to maintain 2 copies of the alerts - the ones they use and
the original text (if they want to forward it or verify it) - then sure by
all means adopt this. It is much simpler, no doubt.

This is potentially a much bigger deal than people realize though. So let's
be honest about what we really need to do if this is chosen.

Thinking forward, I can foresee a lot of situations where I'd want to do
this - for example I can store all my CAP alerts in an XML database. Now
you're saying I basically need 2 copies of every message in order to
actually use the format AND to maintain signatures and that oh by the way -
as soon as you start using the format you've lost the signature associated
with since the signature is for the _representation_ of the message and
strictly speaking not the message content itself. It just strikes me as
absurd and incredibly klunky. 

So now my CAP message (as stored) looks something like this:

struct cap_msg_container {
 String signed_cap_msg;
 XMLDoc xml_cap_msg;
}

Which is pretty silly any way you look at it..

Potentially problematic if somewhere along the line you "lose" the
association between the original message (with signature) and the actual
object I am doing Xpath queries or whatever on. Certainly I would think that
the fact you break the signature the minute you load it is a problem -
unless you enforce strict rules about deserialization but I think that's
likely to be fruitless.

I agree that c14n/dsig is not very mature and that doing signatures "The XML
Way (tm)" is perhaps a hopeless proposition to start with. But recognize
that if you do this you do lose some real capabilities in exchange for
admittedly an easier implementation.

 - bri

-----Original Message-----
From: cap-list-bounces at lists.incident.com
[mailto:cap-list-bounces at lists.incident.com] On Behalf Of Art Botterell
Sent: Thursday, March 12, 2009 12:23
To: cap-list at lists.incident.com
Subject: Re: [CAP] Then Again... (was Re: CAP
SecurityUsingDigitalSignatures)

I look at it kind of the other way 'round, Brian.  If the digital signature
is applied to the message as originally authored, there's no ambiguity and
all a recipient needs is a clean copy of the original and the sender's
public key.  Whereas if we attempt to canonicalize, every recipient (at
least, any one that wants to be able to verify a
signature) will need to become, and remain, fluent in one or more C14N
schemes... and it doesn't look, from those W3C documents, as if that
technology has fully stabilized yet.  Which to my mind raises even larger
practical problems of interoperability.

The canonicalization kerfluffle does offer a good excuse to do nothing and
wait a few more years for the dust to settle.  And under some circumstances
that might be appropriate.  However, given the systems slated to roll out
over the next couple of years, I think it could be  
a serious mistake that we'd be forced to live with for a long time.   
Thus my suggestion that we might want to get started by using one approach
that everyone can understand in exactly the same way, using tools that are
currently available.

Certainly I do understand that some programmers, particularly ones who are
wholly dependent on off-the-rack frameworks, might find the null-
canonicalization approach challenging.  And maybe in the long run it'll
prove unnecessary, in which case everybody wins.

But if we don't start demonstrating some end-to-end authentication solutions
soon, I'm concerned we'll find ourselves getting locked into one or more
stovepipe authentication domains.  And that *would* be a betrayal of the
purpose of CAP.

- Art

On Mar 12, 2009, at 3/12/09 2:52 PM, Russo CTR Brian T wrote:

> I think not performing C14n would be a mistake because then you open
> yourself up to a whole mess of bugs and interoperability issues  
> involving
> text encoding.. whitespace.. etc.. Not all of which would accurately  
> be
> characterized as bugs since many would involve legal serializations.
>
> If I can't load an infoset, then turn around and deserialize it  
> without
> changing anything - and have my implementation of XML "break" your
> signature, then I consider that a problem. I understand how many  
> wouldn't
> but in the long run you're just shooting yourself in the foot for some
> upfront convenience.
>
> And if you don't have an easily interoperable format.. Then what's the
> purpose of CAP?
>
> - bri
>

_______________________________________________
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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://lists.incident.com/pipermail/cap-list/attachments/20090312/c23b138c/attachment.bin>