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

Russo CTR Brian T brian.russo.ctr at usmc.mil
Thu Mar 12 17:12:34 PDT 2009 

Well there you have it, what I initially saw as a failing could actually
turn out to be a benefit and thus moot!

 - bri

-----Original Message-----
From: matt at mhoffman.org [mailto:matt at mhoffman.org] On Behalf Of matt hoffman
Sent: Thursday, March 12, 2009 14:09
To: Russo CTR Brian T
Subject: Re: [CAP] Then Again... (was Re: CAP
SecurityUsingDigitalSignatures)

Funny you say that, because the in last CAP system I worked on (a DHS WARN
prototype) we ended up doing exactly that -- stored the string version of
the message along with the serialized form.  It was for performance reasons
-- we had to act on the message and route it based on contents, but we knew
we were going to be sending it on to recipients unchanged. It was far faster
to stream the string out to recipients than it was to deserialize it. 
There are some other advantages to that model, but you're right, it looks
pretty goofy on paper. 

Of course, whether we end up canonicalizing it or not, you can still store
it like that if the need arises. 


matt




On Thu, Mar 12, 2009 at 7:16 PM, Russo CTR Brian T
<brian.russo.ctr at usmc.mil> wrote:


	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
<http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency%
0ACAP-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>
	
	_______________________________________________
	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
<http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency%
0ACAP-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/b6486769/attachment.bin>

More information about the CAP-list mailing list