[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [CAP] Then Again... (was Re: CAP Security Using DigitalSignatures)
Thanks David, I've noted similar conversations and interests in a couple of venues, so I'm relaying it. Cheers, Rex At 3:17 PM -0400 3/12/09, David Aylward \(Comcare\) wrote: >It is indeed a very significant issue. Thanks to Art for raising it, and to >Rex for expanding the scope. > >I think what has been raised is end to end identity management, which is a >central problem across the emergency/safety eco-system, for lots of use >cases, and is closely related to access control (the right to send or >receive certain messages, and assignment of identities). > >CAP is an important use case, but only one of those that need these related >capabilities. And it is an important standard, but only one of those that >need these. > >As Art correctly points out, the nature of emergency interoperability is a >wide variety of emergency messages, going across multiple >networks/applications which may or may not be secure. And it is "n" >originators, sending messages to "n" recipients. Because of this we in >COMCARE came to the conclusion reached by a lot of folks that we need >federated, standardized solutions for these needs. Rather than the ad hoc, >use-centric approach that has been used to date. > >I hope as you address the particular needs of CAP, you will do so with this >broader set of needs in mind. > > > >-----Original Message----- >From: cap-list-bounces@lists.incident.com >[mailto:cap-list-bounces@lists.incident.com] On Behalf Of Rex Brooks >Sent: Thursday, March 12, 2009 3:01 PM >To: matt hoffman; Art Botterell >Cc: cap-list@lists.incident.com >Subject: Re: [CAP] Then Again... (was Re: CAP Security Using Digital >Signatures) > >Just wanted to let you all know that I have forwarded this thread to >the Messages and Notification Subcommittee of the OASIS EM TC because >I think it is significant, and I wanted them to be aware of the >conversation. > >Thanks, >Rex > >At 2:46 PM -0400 3/12/09, matt hoffman wrote: >>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. > > >-- >Rex Brooks >President, CEO >Starbourne Communications Design >GeoAddress: 1361-A Addison >Berkeley, CA 94702 >Tel: 510-898-0670 >_______________________________________________ >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]