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


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.


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