[CAP] Then Again... (was Re: CAP SecurityUsingDigitalSignatures)
Bob Bunge
Robert.Bunge at noaa.gov
Thu Mar 12 19:53:29 PDT 2009
Hardly keeping up on this, but I would assume the serial approach would
be the faster of the two in most instances. That's something close our
heart here at NWS.
Bob Bunge
NWS OCIO
Russo CTR Brian T wrote:
> 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>
> _______________________________________________
> 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.
More information about the CAP-list
mailing list