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: Re: [CAP] CAP Security Using Digital Signatures


Six.

>X-Provags-ID: V01U2FsdGVkX1/bxhN9CSvbfvwT+2SJHfzgtNL46srulTM5XjHbwL
>	RwJlaEDuLt+pMq
>From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
>To: "'Art Botterell'" <acb@incident.com>,
>	<cap-list@lists.incident.com>
>Date: Thu, 12 Mar 2009 18:40:36 +0200
>Thread-Index: AcmjKlI2s6FqI4ksTLWuyIHs/8oH3wAAWbJA
>X-Y-GMX-Trusted: 0
>X-FuHaFi: 0.5
>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 61%
>
>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@lists.incident.com
>>[mailto:cap-list-bounces@lists.incident.com] On Behalf Of Art Botterell
>>Sent: 12 March, 2009 17:32
>>To: cap-list@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@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@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@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]