[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: RE: [CAP] Then Again... (was Re: CAP Security UsingDigitalSignatures)
Still relaying the conversation. Cheers, Rex >X-Provags-ID: V01U2FsdGVkX18VtChtbisVBLhq8dWNlZEwDm5ZqhPZ9B1P+w1ZgZ > IJvN3wI6nxFgMd >From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> >To: "'David Aylward \(Comcare\)'" <daylward@comcare.org>, > "'Rex Brooks'" <rexb@starbourne.com>, > "'matt hoffman'" <matthoffman@acm.org>, > "'Art Botterell'" <acb@incident.com> >Cc: <cap-list@lists.incident.com> >Subject: RE: [CAP] Then Again... (was Re: CAP Security Using >DigitalSignatures) >Date: Thu, 12 Mar 2009 22:17:55 +0200 >Thread-Index: AcmjROaeK0oGLM79R/GQQV3YJc84cgAAMJBAAAJK8SA= >X-Y-GMX-Trusted: 0 >X-FuHaFi: 0.52 >X-Nonspam: Statistical 62% > >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@lists.incident.com >>[mailto:cap-list-bounces@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@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@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_abbre >>v=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_abbre >>v=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_abbre > >v=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/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@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@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@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]