Number four.
>X-YMail-OSG:
>_GL8k3kVM1kUGJUualKQu23K1KaWJfuf712eozSWWm1EpgG._R_BlpgTjSdtta1bN69ID6PWRMY0e4pZge92V90eoSNb7.skXDjERehumUwjfyyyKc_02cpxVEMMb0WF7l7s9rahWrGrBWo7MKiB_LUCh6bJECLZF21lO5KZq2e0z353bAyVzvyHWq7zqw3H
>X-Yahoo-Newman-Property: ymail-3
>From: Art Botterell <>
>To:
>Date: Thu, 12 Mar 2009 08:32:12 -0700
>Subject: Re: [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 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 <> 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
>>
>>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
>
>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
