Fwd: [CAP] CAP Security Using Digital Signatures

Hi Everyone,

I'm sending along an ongoing thread from the 
 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: 
>X-YMail-OSG: 
>MPxIwecVM1mv5dEL4xsvYlef8fRzqSd9dfeBZmbH_utXRGrbiEkLHJpcGpKxpxYf0qzVCszntOC6vyL.bDUXyOMuHxl91ggNfn159kCMeXXoO2HGXyIHMwydSrbdeX4ePX1n.9vlrD2AvmKH57t7P3mM
>X-Yahoo-Newman-Property: ymail-3
>From: Art Botterell <>
>To: 
>Date: Wed, 11 Mar 2009 20:20:14 -0700
>Subject: [CAP] CAP Security Using Digital Signatures
>X-BeenThere: 
>List-Id: Common Alerting Protocol Public Discussion
>	<cap-list.lists.incident.com>
>List-Unsubscribe: <http://lists.incident.com/mailman/options/cap-list>,
>	<mailto:?subject=unsubscribe>
>List-Archive: <http://lists.incident.com/pipermail/cap-list>
>List-Post: <mailto:>
>List-Help: <mailto:?subject=help>
>List-Subscribe: <http://lists.incident.com/mailman/listinfo/cap-list>,
>	<mailto:?subject=subscribe>
>Sender: 
>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
>
>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