>Date: Thu, 12 Mar 2009 15:55:22 -0400
>X-Google-Sender-Auth: f750688000ca908f
>From: matt hoffman <>
>To: "Hughes, William" <>
>Cc:
>Subject: Re: [CAP] Then Again... (was Re: CAP Security Using
> DigitalSignatures)
>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%
>
>To be clear, the alteration we're talking about here isn't any kind of
>content modification -- adding or altering fields, for example. It's simply
>formatting, primarily whitespace. For example, the two XML fragments:
><alert>
> <identifier>MyMessageIdentifier</identifier>
> <sender></sender>
>
>and:
>
><alert><identifier>MyMessageIdentifier</identifier><sender>
></sender>
>
>are functionally identical, but would result in different XML signatures as
>they are. Thus the question of either altering the whitespace of every XML
>message coming in to some standard, canonical form before verifying
>signatures, or agreeing by convention to never alter a single byte of the
>message whether it affects the content or not. Both methods are fragile in
>their own way.
>
>I assume that the modification that would concern you, as an originator of
>alerts, would be modifications of content, not necessarily modifications to
>XML formatting.
>
>
>
>
>On Thu, Mar 12, 2009 at 3:05 PM, Hughes, William <
>> wrote:
>
>> Hi time top weigh in on this on the non-technical side.
>>
>> Since I may be an originator of CAP alerts, I and I am sure the majority of
>> my colleagues would prefer that alerts / warnings be relayed with out
>> alteration in anyway.
>>
>> Subsequent enhancement / modification of the alert by other authorities,
>> should be a new separate message.
>>
>> That would help keep the audit trail clean.
>>
>> Thanks
>>
>> Bill Hughes, Mobile 651-325-5867
>>
>> ----- Original Message -----
>> From: <
>> >
>> To: Art Botterell <>
>> Cc: <>
>> Sent: Thu Mar 12 13:46:34 2009
>> Subject: Re: [CAP] Then Again... (was Re: CAP Security Using
>> DigitalSignatures)
>>
>> Sorry, didn't see this post before replying to the other.
>> Whether we specify it or not (and, it could be that canonicalization
>> standards have reached a point that we no longer need to -- I don't want to
>> be too hopeful, but it is certainly possible) there are certainly
>> performance benefits in forwarding the message as you received it, if there
>> were no local changes.
>> At least, in my implementation experiences. Saves one serialization step,
>> and one set of possible compatibility issues.
>>
>> Now, whether we want to mandate sign-the-blob... I agree that, from a
>> signature point of view, it simplifies things considerably (or seems to --
>> I
>> haven't tried it with the Java toolkits, but it makes sense that it would
>> work as you're suggesting). But other implementers might want to speak up
>> there about the feasibility of ALWAYS passing exactly what they received if
>> there is a digital signature included. That's mandating a particular
>> implementation step that might not be trivial for all users.
>>
>>
>>
>> On Thu, Mar 12, 2009 at 12:08 PM, Art Botterell <> wrote:
>>
>> > Thinking about it a bit more... am I mistaken, or wouldn't a simple way
> > to
>> > implement a "sign the blob" approach be just to use a "null"
>> > canonicalization in otherwise-normal XMLSIG?
>> >
>> > As I understand it, the reason for C14N is to deal with variations in
> > > whitespace, attribute order and such that can occur when XML is parsed
>> and
>> > then re-serialized. So we try to factor out every possible change that
>> > might occur in those processes... with, it appears, limited success.
>> >
>> > But to simply forward/publish someone else's CAP alert, seems like
>> passing
>> > it along precisely, byte-for-byte, would be relatively simple... and (as
>> the
>> > Gutmann paper points out) much more auditable. Of course that wouldn't
>> > prevent any node from parsing the alert and acting on the basis of the
>> > contents. It would only mean that if that node decides to pass the alert
>> to
>> > other nodes, it must give them the precise version it received.
>> >
>> > In other words, if C14N is murky bathwater, maybe we could dispense with
>> it
>> > without needing to toss the baby too. All we'd need would be a
>> > clarification in the OASIS spec (and an implementers' convention till
>> then)
>> > that canonicalization SHALL NOT be applied during signing. (And to fix
>> the
>> > schema, of course.)
>> >
>> > Or am I missing something here?
>> >
>> > - Art
>> >
>> >
>> > On Mar 12, 2009, at 3/12/09 8: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.
>> >>
>> >
>> > _______________________________________________
>> > 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/29909d94/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.
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>>
>>http://lists.incident.com/pipermail/cap-list/attachments/20090312/b5d00ccf/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.
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
><http://lists.incident.com/pipermail/cap-list/attachments/20090312/9b33f5a2/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
