[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: [CAP] CAP Security Using Digital Signatures
Hi Everyone, I'm sending along an ongoing thread from the cap-list@lists.incident.com to let you know that there are other conversations going on in the greater cap universe. This is just a coincidence, but it does put us on notice that our recommendation wrt cap isn't going to happen in a vacuum. XML Signatures is just one of numerous issues but this one looks like it would be immediately championed for inclusion in any prospective 1.2. I just didn't want it to come as any surprise. Cheers, Rex >X-Yahoo-Newman-Id: 751825.49348.bm@omp412.mail.mud.yahoo.com >X-YMail-OSG: >MPxIwecVM1mv5dEL4xsvYlef8fRzqSd9dfeBZmbH_utXRGrbiEkLHJpcGpKxpxYf0qzVCszntOC6vyL.bDUXyOMuHxl91ggNfn159kCMeXXoO2HGXyIHMwydSrbdeX4ePX1n.9vlrD2AvmKH57t7P3mM >X-Yahoo-Newman-Property: ymail-3 >From: Art Botterell <acb@incident.com> >To: cap-list@lists.incident.com >Date: Wed, 11 Mar 2009 20:20:14 -0700 >Subject: [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 56% > >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. -- 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]