[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: Re: [CAP] CAP Security Using Digital Signatures
Six. >X-Provags-ID: V01U2FsdGVkX1/bxhN9CSvbfvwT+2SJHfzgtNL46srulTM5XjHbwL > RwJlaEDuLt+pMq >From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> >To: "'Art Botterell'" <acb@incident.com>, > <cap-list@lists.incident.com> >Date: Thu, 12 Mar 2009 18:40:36 +0200 >Thread-Index: AcmjKlI2s6FqI4ksTLWuyIHs/8oH3wAAWbJA >X-Y-GMX-Trusted: 0 >X-FuHaFi: 0.5 >Subject: Re: [CAP] CAP Security Using Digital Signatures >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 61% > >Hi Art, > >I believe a more urgent item for work on CAP is to come up with better >semantic of the elements in the CAP XML spec itself. >The lack of precise semantic will IMHO make end-to-end usage challenging. > >On the digital signature aspects I wonder whether there are (not just >theoretical) threats that demand it's usage in the envisioned usage >scenarios. > >Ciao >Hannes > >>-----Original Message----- >>From: cap-list-bounces@lists.incident.com >>[mailto:cap-list-bounces@lists.incident.com] On Behalf Of Art Botterell >>Sent: 12 March, 2009 17:32 >>To: cap-list@lists.incident.com >>Subject: Re: [CAP] CAP Security Using Digital Signatures >> >>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_abbre >>v=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_abbre >>v=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. -- 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]