[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] SBE Viewpoint
I agree David, It's a matter of balance. Cheers, Rex David RR Webber (XML) wrote: > Rex, > Understood. > I too was trying to show that OASIS offers ways to systematically > resolve the issues - without throwing a hatchet at what has been built > so far. > I think this is the piece that people miss about OASIS standards work. > It's OK to place work out there and qualify it with clarifications of > the intent, purpose and scope. > Likewise its really important to have those limitations spelled out > and what the future work needs to address before people get too far > off base. We all know the challenge of balancing what sales and > marketing want to sell compared to what is really there! > Then we cannot expect build an ISS at the first go around - you need > engineering steps to get there - and learning better ways is part of > that journey - but plan that successive peices will continue to fit > neatly into what you've already managed to put in place. > > Thanks, DW > > -------- Original Message -------- > Subject: Re: [emergency] SBE Viewpoint > From: Rex Brooks <rexb@starbourne.com> > Date: Mon, February 15, 2010 7:15 pm > To: "David RR Webber (XML)" <david@drrw.info> > Cc: Ron Lake <rlake@galdosinc.com>, 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>, Lee > Tincher <ltincher@evotecinc.com>, "David E. Ellis" <dellis@sandia.gov> > > David, > > No offense, please. > > I know you mean well and that there are solid reasons why this > information is valuable, but we really must focus on CAP v1.2. This > discussion is more relevant to the upcoming CAP 2.0 work and > EDXL-DE 2.0 > work. However, we are not there yet. We have to get the current > situation resolved before we can change focus because the time > will have > arrived when we can actually move on and dig into all this very > interesting stuff. > > For now we have to avoid issue creep. > > Cheers, > Rex > > David RR Webber (XML) wrote: > > Ron, > > Strongly agree. > > I also was pointing to the ebXML CPA as an example of mechanisms > that > > link between the exchange message envelope and the ability to > > determine what the relationship is between the bits and bytes and > the > > real world. > > BTW - I've just recalled another nifty feature of CPA - the CPA ID - > > which can be private. So even if I managed somehow to get hold of > > someones digital certificate for signing messages - I may not know > > what the CPA ID is that defines the relationship between X and Y - > > because as partner W with Y - I have never seen the CPA ID they are > > using. And the CPA ID can be specific to message exchanges - so I > may > > have different values depending on the types of messages in an > exchange. > > Conversely - where is proves problematic to have digital > certificates > > - they are not the easiest thing to say shoehorn into a device - > > whereas a CPA ID code can be used in a configuration to authenticate > > the relationship and exchange. > > To the general discussion though - seems to me - need is to add > > supporting documents and profiles of use to the base schema in > the CAP > > spec's - rather than retooling the schema persay. > > These profiles are things you can vote on separately - and > > implementers will want to use then to supplement the schema. > > Mentioning which - as Chair of CAM TC - I need to mention that CAM > > templates provide a great way to specify profiles of use - that > > overlay on top of a generic schema - and provide the actual > "rules of > > engagement" and content for specific application use. > > > > Thanks, DW > > > > -------- Original Message -------- > > Subject: RE: [emergency] SBE Viewpoint > > From: "Ron Lake" <rlake@galdosinc.com> > > Date: Mon, February 15, 2010 6:02 pm > > To: "David RR Webber (XML)" <david@drrw.info> > > 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>, "Lee Tincher" <ltincher@evotecinc.com>, > > <rexb@starbourne.com>, "David E. Ellis" <dellis@sandia.gov> > > > > 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 > <http://email.secureserver.net/#Compose>] > > *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 > -- 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]