[CAP] Then Again... (was Re: CAP Security Using DigitalSignatures)
Hannes Tschofenig
Hannes.Tschofenig at gmx.net
Thu Mar 12 13:17:55 PDT 2009
Identity Management is the fuzzy term.
All you need is a Public Key Infrastructure. In the mentioned end-to-end use
case as a recipient of alerts you need to have a way to verify the digital
signature. Therefore, you need to have common trust anchor. Where do you get
that from? Use it from the trust anchors you have in your browser?
What does it mean if you have authenticated the message sender? Would this
tell the user a lot?
If you cannot verify the signature do dump the message?
>-----Original Message-----
>From: cap-list-bounces at lists.incident.com
>[mailto:cap-list-bounces at lists.incident.com] On Behalf Of
>David Aylward (Comcare)
>Sent: 12 March, 2009 21:17
>To: 'Rex Brooks'; matt hoffman; Art Botterell
>Cc: cap-list at lists.incident.com
>Subject: Re: [CAP] Then Again... (was Re: CAP Security Using
>DigitalSignatures)
>
>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_abbre
>v=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_abbre
>v=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_abbre
>v=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/2009
>0312/2990
>>9d94
>/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_abbr
>ev=emerge
>>ncy
>>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_abbre
>v=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_abbre
>v=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.
>
More information about the CAP-list
mailing list