[CAP] CAP Security Using Digital Signatures

Thu Mar 12 11:35:57 PDT 2009

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 <acb at incident.com> 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 <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_abbrev=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_abbrev=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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.incident.com/pipermail/cap-list/attachments/20090312/2d445552/attachment.htm>