[CAP] CAP Security Using Digital Signatures

Thu Mar 12 09:40:36 PDT 2009

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 at lists.incident.com 
>[mailto:cap-list-bounces at lists.incident.com] On Behalf Of Art Botterell
>Sent: 12 March, 2009 17:32
>To: cap-list at 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 at 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 at 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 at 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.
>