OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-msg message

[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.


>X-Yahoo-Newman-Id: 751825.49348.bm@omp412.mail.mud.yahoo.com
>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 
>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 
>> 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 
>CAP-list mailing 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]