[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: Re: [CAP] CAP Security Using Digital Signatures
Nine. And this brings us up to the moment. Cheers, Rex >Date: Thu, 12 Mar 2009 14:35:57 -0400 >X-Google-Sender-Auth: 15a027f4ad6910ad >From: matt hoffman <matthoffman@acm.org> >To: Art Botterell <acb@incident.com> >Cc: cap-list@lists.incident.com >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 54% > >Some good news, where XML signatures are concerned: >1.) Support for XML Signatures is now built into Java 6: >http://java.sun.com/developer/technicalArticles/xml/dig_signature_api/ so >for Java users it should be a relatively simple exercise. I don't know the >progress for other languages >2.) I see that W3C finalized XML C14N version 1.1 last year, and has test >cases specifically for XMLDSig interoperability: >http://www.w3.org/TR/2008/NOTE-xmldsig2ed-tests-20080610/ > >So I don't want to sound too loud of an alarm on the method specified in the >spec -- there is apparently still progress being made in the XML DSig >world, so it might still be the best way to achieve message-level >signatures. > >In related news, Art -- are the CAP implementations you're aware of all >using XML, or are any using ASN.1? > > >- matt > > > >On Thu, Mar 12, 2009 at 11:32 AM, Art Botterell <acb@incident.com> 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. >> >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: ><http://lists.incident.com/pipermail/cap-list/attachments/20090312/2d445552/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]