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

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.







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.



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




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"


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

The main point is that it has nothing to do with the content of the


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]