[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: Re: [CAP] Then Again... (was Re: CAP Security UsingDigitalSignatures)
... >Date: Thu, 12 Mar 2009 13:23:50 -0700 >From: Rex Buddenberg <budden@nps.navy.mil> >To: matt hoffman <matthoffman@acm.org> >Cc: "Hughes, William" <William.Hughes@co.ramsey.mn.us>, > cap-list@lists.incident.com >Subject: Re: [CAP] Then Again... (was Re: CAP Security > Using DigitalSignatures) >X-BeenThere: cap-list@lists.incident.com >List-Id: Common Alerting Protocol Public Discussion > <cap-list.lists.incident.com> >List-Unsubscribe: <http://lists.incident.com/mailman/options/cap-list>, > <mailto:cap-list-request@lists.incident.com?subject=unsubscribe> >List-Archive: <http://lists.incident.com/pipermail/cap-list> >List-Post: <mailto:cap-list@lists.incident.com> >List-Help: <mailto:cap-list-request@lists.incident.com?subject=help> >List-Subscribe: <http://lists.incident.com/mailman/listinfo/cap-list>, > <mailto:cap-list-request@lists.incident.com?subject=subscribe> >Sender: cap-list-bounces@lists.incident.com >X-Nonspam: Statistical 60% > >Matt, > >Note that XML sign can be applied to the whole message (making it >equivalent to a whole-message e-mail signature, MIME this time >instead of XML). What Art is calling the blob. > >But that does not prevent signing subsets of the message too. >Individual tagged fields or groups of them. >Order of business. I'd suggest that the greater granularity should >be pursued only after we get a workable blob authentication working. > > > >matt hoffman wrote: >>To be clear, the alteration we're talking about here isn't any kind of >>content modification -- adding or altering fields, for example. It's simply >>formatting, primarily whitespace. For example, the two XML fragments: >><alert> >> <identifier>MyMessageIdentifier</identifier> >> <sender>me@mycompany.com</sender> >> >>and: >> >><alert><identifier>MyMessageIdentifier</identifier><sender>me@mycompany.com >></sender> >> >>are functionally identical, but would result in different XML signatures as >>they are. Thus the question of either altering the whitespace of every XML >>message coming in to some standard, canonical form before verifying >>signatures, or agreeing by convention to never alter a single byte of the >>message whether it affects the content or not. Both methods are fragile in >>their own way. >> >>I assume that the modification that would concern you, as an originator of >>alerts, would be modifications of content, not necessarily modifications to >>XML formatting. >> >> >> >> >>On Thu, Mar 12, 2009 at 3:05 PM, Hughes, William < >>William.Hughes@co.ramsey.mn.us> wrote: >> >> >>>Hi time top weigh in on this on the non-technical side. >>> >>>Since I may be an originator of CAP alerts, I and I am sure the majority of >>>my colleagues would prefer that alerts / warnings be relayed with out >>>alteration in anyway. >>> >>>Subsequent enhancement / modification of the alert by other authorities, >>>should be a new separate message. >>> >>>That would help keep the audit trail clean. >>> >>>Thanks >>> >>>Bill Hughes, Mobile 651-325-5867 >>> >>>----- Original Message ----- >>>From: cap-list-bounces@lists.incident.com < >>>cap-list-bounces@lists.incident.com> >>>To: Art Botterell <acb@incident.com> >>>Cc: cap-list@lists.incident.com <cap-list@lists.incident.com> >>>Sent: Thu Mar 12 13:46:34 2009 >>>Subject: Re: [CAP] Then Again... (was Re: CAP Security Using >>>DigitalSignatures) >>> >>>Sorry, didn't see this post before replying to the other. >>>Whether we specify it or not (and, it could be that canonicalization >>>standards have reached a point that we no longer need to -- I don't want to >>>be too hopeful, but it is certainly possible) there are certainly >>>performance benefits in forwarding the message as you received it, if there >>>were no local changes. >>>At least, in my implementation experiences. Saves one serialization step, >>>and one set of possible compatibility issues. >>> >>>Now, whether we want to mandate sign-the-blob... I agree that, from a >>>signature point of view, it simplifies things considerably (or seems to -- >>>I >>>haven't tried it with the Java toolkits, but it makes sense that it would >>>work as you're suggesting). But other implementers might want to speak up >>>there about the feasibility of ALWAYS passing exactly what they received if >>>there is a digital signature included. That's mandating a particular >>>implementation step that might not be trivial for all users. >>> >>> >>> >>>On Thu, Mar 12, 2009 at 12:08 PM, Art Botterell <acb@incident.com> wrote: >>> >>> >>>>Thinking about it a bit more... am I mistaken, or wouldn't a simple way >>>> >>>to >>> >>>>implement a "sign the blob" approach be just to use a "null" >>>>canonicalization in otherwise-normal XMLSIG? >>>> >>>>As I understand it, the reason for C14N is to deal with variations in >>>>whitespace, attribute order and such that can occur when XML is parsed >>>> >>>and >>> >>>>then re-serialized. So we try to factor out every possible change that >>>>might occur in those processes... with, it appears, limited success. >>>> >>>>But to simply forward/publish someone else's CAP alert, seems like >>>> >>>passing >>> >>>>it along precisely, byte-for-byte, would be relatively simple... and (as >>>> >>>the >>> >>>>Gutmann paper points out) much more auditable. Of course that wouldn't >>>>prevent any node from parsing the alert and acting on the basis of the >>>>contents. It would only mean that if that node decides to pass the alert >>>> >>>to >>> >>>>other nodes, it must give them the precise version it received. >>>> >>>>In other words, if C14N is murky bathwater, maybe we could dispense with >>>> >>>it >>> >>>>without needing to toss the baby too. All we'd need would be a >>>>clarification in the OASIS spec (and an implementers' convention till >>>> >>>then) >>> >>>>that canonicalization SHALL NOT be applied during signing. (And to fix >>>> >>>the >>> >>>>schema, of course.) >>>> >>>>Or am I missing something here? >>>> >>>>- Art >>>> >>>> >>>>On Mar 12, 2009, at 3/12/09 8:32 AM, Art Botterell wrote: >>>> >>>> Interesting link, Matt. Sounds like an object lesson on why we should >>>> >>>>>resist the temptation to standardize what we don't yet understand. >>>>> >>>>>I was thinking we might wind up proposing an erratum to OASIS to fix the >>>>>schema issue, but hadn't appreciated that cannonicalization was still >>>>>proving so intractable. Although that article is from 2004, I take it >>>>> >>>the >>> >>>>>C14N situation hasn't improved. So maybe it would make more sense to >>>>>identify (and demonstrate!) alternate approaches that could be fed back >>>>> >>>into >>> >>>>>the standard. >>>>> >>>>>My concern is that if we don't address the end-to-end signature problem >>>>> >>>as >>> >>>>>a community there might not be a business incentive for any particular >>>>>implementer to design for that level of interoperability. And while the >>>>>OASIS process usually does a good job of refining and ratifying >>>>> >>>contributed >>> >>>>>designs, it seems not to be as effective as a framework for developing >>>>> >>>those >>> >>>>>designs in the first place. >>>>> >>>>>- Art >>>>> >>>>> >>>>> >>>>>On Mar 12, 2009, at 3/12/09 5:59 AM, matt hoffman wrote: >>>>> >>>>> I did a proof-of-concept implementation of this on a previous DHS >>>>> >>>system. >>> >>>>>>Although, as you say, there was no way of verifying it with other >>>>>> >>>providers >>> >>>>>>or consumers at the time. >>>>>>However, a couple of points that I recall: >>>>>> >>>>>>a.) The document mentions that the signature element can be a child of >>>>>>"alert", but unless I'm mistaken it is not specified in the schema. So >>>>>>messages containing signatures fail schema validation ... I had to >>>>>>explicitly add it to the schema. >>>>>> >>>>>>b.) The signatures are delicate, and tricky: >>>>>>http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt >>>>>> >>>>>>Unfortunately I no longer have access to that code, but I'd be happy to >>>>>>help others if they're looking into it. >>>>>> >>>>>> >>>>>>- matt >>>>>> >>>>>>On Wed, Mar 11, 2009 at 11:20 PM, Art Botterell <acb@incident.com> >>>>>>wrote: >>>>>>Friends - >>>>>> >>>>>>We're moving rapidly toward an important threshold in CAP >>>>>>implementations. So far, most CAP-based systems have been >>>>>> >>>self-contained, >>> >>>>>>single vendor/implementer arrangements. But soon we're going to need >>>>>> >>>to >>> >>>>>>"federate" CAP traffic among multiple interoperable systems. And that >>>>>> >>>has >>> >>>>>>important implications for security. >>>>>> >>>>>>Most current systems use a trusted-link/trusted-host mode based on >>>>>>encrypted network links and password access control at a central >>>>>> >>>server. >>> >>>>>> That's a familiar Web 1.0 approach and it works fine for "single-hop" >>>>>>implementations. But it has a major drawback: As soon as messages are >>>>>>forwarded from one server to another, a security compromise anywhere >>>>>> >>>can >>> >>>>>>compromise the authentication and integrity of all CAP messages >>>>>> >>>downstream. >>> >>>>>>The alternative, of course, is to apply digital signatures to CAP >>>>>>messages at their origin, and to verify them at receiving points. That >>>>>> >>>way, >>> >>>>>>it doesn't matter if the links or intervening nodes are secure or not; >>>>>> >>>any >>> >>>>>>recipient can verify independently that the message is a) from who it >>>>>> >>>says >>> >>>>>>it's from, and b) hasn't been modified in transit. >>>>>> >>>>>>There's a standard way of doing this for XML, as cited in the CAP >>>>>>Specification: >>>>>> >>>>>> >>>>>>>3.3.2.1 Digital Signatures >>>>>>>The alert element of a CAP Alert Message MAY have an Enveloped >>>>>>> >>>>>>Signature, as described by XML Signature and >>>>>> >>>>>>>Syntax Processing [XMLSIG]. Other XML signature mechanisms MUST NOT be >>>>>>> >>>>>>used in CAP Alert Messages. Processors >>>>>> >>>>>>>MUST NOT reject a CAP Alert Message containing such a signature simply >>>>>>> >>>>>>because they are not capable of verifying >>>>>> >>>>>>>it; they MUST continue processing and MAY inform the user of their >>>>>>> >>>>>>failure to validate the signature. >>>>>> >>>>>>But I'm not aware of anyone that's implemented it yet... partly because >>>>>>it hasn't been necessary in stand-alone systems, and partly because it >>>>>>involves a type of programming a lot of folks haven't had occasion to >>>>>>explore yet. >>>>>> >>>>>>But ultimately, it's going to be essential for interoperability. So >>>>>> >>>I'd >>> >>>>>>be interested in hearing, has anyone implemented XMLSIG on CAP yet? >>>>>> >>> And >>> >>>>>>would anyone be interested in doing some interoperability experiments? >>>>>> >>> The >>> >>>>>>standard is there, the technology is there (in Java and a number of >>>>>> >>>other >>> >>>>>>languages) and I see the requirement bearing down on us quickly. >>>>>> >>>>>>What say? >>>>>> >>>>>>- 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@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. >>>>>> >>>>>> >>>>>> >>>>>_______________________________________________ >>>>>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@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. >>>>> >>>>> >>>>_______________________________________________ >>>>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@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/29909d94/attachment.htm >>> >>>_______________________________________________ >>>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@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/b5d00ccf/attachment.htm >>> >>>_______________________________________________ >>>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@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/9b33f5a2/attachment.htm> >>_______________________________________________ >>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@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. >> >> > >-- >Rex Buddenberg >Senior Lecturer >Naval Postgraduate School >Monterey, Ca 93943 >831/656-3576 > >_______________________________________________ >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@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. -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-898-0670
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]