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


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]