[CAP] Then Again... (was Re: CAP Security Using Digital Signatures)
Rex Brooks
rexb at starbourne.com
Thu Mar 12 13:56:03 PDT 2009
Thanks David,
I've noted similar conversations and interests in a couple of venues,
so I'm relaying it.
Cheers,
Rex
At 3:17 PM -0400 3/12/09, David Aylward \(Comcare\) wrote:
>It is indeed a very significant issue. Thanks to Art for raising it, and to
>Rex for expanding the scope.
>
>I think what has been raised is end to end identity management, which is a
>central problem across the emergency/safety eco-system, for lots of use
>cases, and is closely related to access control (the right to send or
>receive certain messages, and assignment of identities).
>
>CAP is an important use case, but only one of those that need these related
>capabilities. And it is an important standard, but only one of those that
>need these.
>
>As Art correctly points out, the nature of emergency interoperability is a
>wide variety of emergency messages, going across multiple
>networks/applications which may or may not be secure. And it is "n"
>originators, sending messages to "n" recipients. Because of this we in
>COMCARE came to the conclusion reached by a lot of folks that we need
>federated, standardized solutions for these needs. Rather than the ad hoc,
>use-centric approach that has been used to date.
>
>I hope as you address the particular needs of CAP, you will do so with this
>broader set of needs in mind.
>
>
>
>-----Original Message-----
>From: cap-list-bounces at lists.incident.com
>[mailto:cap-list-bounces at lists.incident.com] On Behalf Of Rex Brooks
>Sent: Thursday, March 12, 2009 3:01 PM
>To: matt hoffman; Art Botterell
>Cc: cap-list at lists.incident.com
>Subject: Re: [CAP] Then Again... (was Re: CAP Security Using Digital
>Signatures)
>
>Just wanted to let you all know that I have forwarded this thread to
>the Messages and Notification Subcommittee of the OASIS EM TC because
>I think it is significant, and I wanted them to be aware of the
>conversation.
>
>Thanks,
>Rex
>
>At 2:46 PM -0400 3/12/09, matt hoffman wrote:
>>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 <acb at incident.com> 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 <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.
>>>>
>>>
>>> _______________________________________________
>>> 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/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
>>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.
>
>
>--
>Rex Brooks
>President, CEO
>Starbourne Communications Design
>GeoAddress: 1361-A Addison
>Berkeley, CA 94702
>Tel: 510-898-0670
>_______________________________________________
>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.
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670
More information about the CAP-list
mailing list