[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] SBE Viewpoint
IN a nutshell, Rob, This is what the Reference Information Model SC is tasked with, and we're hip deep in the ValueListURN at the moment. However that is directly applicable to EDXL-DE 2.0 which we decided to pursue in the face-to-face Infrastructure SC meeting last Monday, so it is relevant. However, I think the EDXL-DE 2.0 work does, for most intents and purposes, encapsulate most of this issue. However, it will also be necessary, in my opinion, to accommodate a non-DE, standalone CAP in addition to a DE-distributed non-standalone CAP in CAP 2.0. How we do that is the question. Cheers, Rex Rob Torchon wrote: > > These have been the most interesting email threads we’ve seen in a > long time. Discussing security issues is almost as much fun as > religion or politics. > > From the top level this is as much an issue addressing all our > standards, and therefore cannot be limited to the current CAP > proposal. The solution, whatever it may be, needs to be applied > uniformly throughout our work. CAP 1.2 is not the place to make this > decision. > > As such I would propose we make this issue the subject of a separate > sub-committee  and have the results apply to the TC in general the > same way we approach GIS. > > I’m voting yes to approve. > > Rob > > 805-551-6232 > >  > > *From:* Ron Lake [mailto:rlake@galdosinc.com] > *Sent:* Monday, February 15, 2010 3:03 PM > *To:* David RR Webber (XML) > *Cc:* Gary Timm; emergency@lists.oasis-open.org; Oien,Chuck; > Sanzero,George; Ammerlahn,Heidi; Lee Tincher; rexb@starbourne.com; > David E. Ellis > *Subject:* RE: [emergency] SBE Viewpoint > > Hi David: > > I don’t disagree with what you are saying, but I think it is an > issue for message envelope and envelope handling (my main point) and > not message content. XML signatures I think would go a long way in > practical terms of providing identification of the source, > non-tampering with the contents, and non-repudiation. > > > R > > *From:* David RR Webber (XML) [mailto:david@drrw.info] > *Sent:* February 15, 2010 2:17 PM > *To:* Ron Lake > *Cc:* Gary Timm; emergency@lists.oasis-open.org; Oien,Chuck; > Sanzero,George; Ammerlahn,Heidi; Lee Tincher; rexb@starbourne.com; > David E. Ellis > *Subject:* RE: [emergency] SBE Viewpoint > > Ron, > > I wish that your example with digital signature was so! All this does > is increase confidence that the probability might be. Nothing digital > can be absolute. > > Dave gives some great scenario insights between single key nuclear > authorization systems and by comparison a distributed emergency > alerting system. > > How do the people driven systems work today? I think we can learn a > lot from studying how say an evacuation order from Wash DC gets actioned. > > What I'm seeing is that you have a system where multiple channels > contribute to your confidence that the information you are receiving > is authentic. People will "pick up the phone" and talk first hand > particularly. Now compare that to say a campus building alert system. > Perhaps you would allow that to be automatically triggered without > more verification. Or a home system that summons an ambulance or law > enforcement response. > > So - what I'm seeing is that you need a supporting system of level of > authority and increasing confidence compared to the seriousness of the > action requested. > > This should be something you can publish as implementation > non-normative notes that support the specification. > > In this regard again - notice that today on the ebCORE TC - Pim > published a standalone CPA ID specification garnered from the original > eXML CPPA - so that you can create these kinds of trust relationships > - beyond the mechanics of digital signatures and encryption alone. > Nice thing is this is then standalone - not dependent on transport > delivery system specifically - but supports the role and context > needed - that is otherwise missing from the simple message exchange data. > > Thanks, DW > > -------- Original Message -------- > Subject: RE: [emergency] SBE Viewpoint > From: "Ron Lake" <rlake@galdosinc.com> > Date: Mon, February 15, 2010 4:48 pm > To: "Lee Tincher" <ltincher@evotecinc.com>, <rexb@starbourne.com>, > "David E. Ellis" <dellis@sandia.gov> > Cc: "Gary Timm" <gtimm@journalbroadcastgroup.com>, > <emergency@lists.oasis-open.org>, "Oien, Chuck" <ctoien@sandia.gov>, > "Sanzero, George" <gsanzer@sandia.gov>, "Ammerlahn, Heidi" > <hrammer@sandia.gov> > > Hi, > > I would also expect that one can do this using existing specifications > for messaging such as XML Signatures (W3C) (as part of the solution). > In XML Signatures, one mulches the message being sent using an > appropriate mulching or digestion algorithm (analogous to computing a > CRC) and gets an encrypted string (containing also the sender's > credentials)) that is sent with the message. The receiver uses the > encrypted string to run the received message through the same mulching > algorithm and compares the result with the received string. If they > match, the content MUST have come from the indicated sender (they > cannot > deny it) and it must have not been tampered with. > > For a better description of this see > http://java.sun.com/developer/technicalArticles/xml/dig_signatures/ > > The main point is that it has nothing to do with the content of the > message. > > R > -- 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]