OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [CAP] Then Again... (was Re: CAP Security Using DigitalSignatures)


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@lists.incident.com
>[mailto:cap-list-bounces@lists.incident.com] On Behalf Of Rex Brooks
>Sent: Thursday, March 12, 2009 3:01 PM
>To: matt hoffman; Art Botterell
>Cc: cap-list@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@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@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@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@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@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@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@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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]