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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[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]