[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: Re: [CAP] CAP Security Using Digital Signatures
Number four. >X-YMail-OSG: >_GL8k3kVM1kUGJUualKQu23K1KaWJfuf712eozSWWm1EpgG._R_BlpgTjSdtta1bN69ID6PWRMY0e4pZge92V90eoSNb7.skXDjERehumUwjfyyyKc_02cpxVEMMb0WF7l7s9rahWrGrBWo7MKiB_LUCh6bJECLZF21lO5KZq2e0z353bAyVzvyHWq7zqw3H >X-Yahoo-Newman-Property: ymail-3 >From: Art Botterell <acb@incident.com> >To: cap-list@lists.incident.com >Date: Thu, 12 Mar 2009 08:32:12 -0700 >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% > >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. -- 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]