[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: Re: [CAP] Then Again... (was Re: CAP Security Using DigitalSignatures)
>Date: Thu, 12 Mar 2009 15:55:22 -0400 >X-Google-Sender-Auth: f750688000ca908f >From: matt hoffman <matthoffman@acm.org> >To: "Hughes, William" <William.Hughes@co.ramsey.mn.us> >Cc: 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 54% > >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 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]