Nine. And this brings us up to the moment.
Cheers,
Rex
>Date: Thu, 12 Mar 2009 14:35:57 -0400
>X-Google-Sender-Auth: 15a027f4ad6910ad
>From: matt hoffman <>
>To: Art Botterell <>
>Cc:
>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%
>
>Some good news, where XML signatures are concerned:
>1.) Support for XML Signatures is now built into Java 6:
>http://java.sun.com/developer/technicalArticles/xml/dig_signature_api/ so
>for Java users it should be a relatively simple exercise. I don't know the
>progress for other languages
>2.) I see that W3C finalized XML C14N version 1.1 last year, and has test
>cases specifically for XMLDSig interoperability:
>http://www.w3.org/TR/2008/NOTE-xmldsig2ed-tests-20080610/
>
>So I don't want to sound too loud of an alarm on the method specified in the
>spec -- there is apparently still progress being made in the XML DSig
>world, so it might still be the best way to achieve message-level
>signatures.
>
>In related news, Art -- are the CAP implementations you're aware of all
>using XML, or are any using ASN.1?
>
>
>- matt
>
>
>
>On Thu, Mar 12, 2009 at 11:32 AM, Art Botterell <> wrote:
>
>> 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.
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
><http://lists.incident.com/pipermail/cap-list/attachments/20090312/2d445552/attachment.htm>
>_______________________________________________
>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
