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:]
> *Sent:* Monday, February 15, 2010 3:03 PM
> *To:* David RR Webber (XML)
> *Cc:* Gary Timm; ; Oien,Chuck;
> Sanzero,George; Ammerlahn,Heidi; Lee Tincher; ;
> 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:]
> *Sent:* February 15, 2010 2:17 PM
> *To:* Ron Lake
> *Cc:* Gary Timm; ; Oien,Chuck;
> Sanzero,George; Ammerlahn,Heidi; Lee Tincher; ;
> 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" <>
> Date: Mon, February 15, 2010 4:48 pm
> To: "Lee Tincher" <>, <>,
> "David E. Ellis" <>
> Cc: "Gary Timm" <>,
> <>, "Oien, Chuck" <>,
> "Sanzero, George" <>, "Ammerlahn, Heidi"
> <>
>
> 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
