[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [emergency] Re: CAP 1.2, Encryption, and DM-OPEN
After consulting with Sandia Management, I have voted “No” for the CAP 1.2 committee specification. The reasons follow:
First, Sandia presented during the IPAWS program the reasons for creating a true publish/subscribe capability for public alert and warning. This meant both individuals (e.g. subscription services) and jurisdictions (city, county, tribal) could select the levels of information they wanted to receive via various communications media. This implied a decoupling of the Alert Publisher and the Alert Consumer (e.g. SOA loose coupling). It also implied a significant number of redistribution capabilities managed by both Federal and Commercial entities. During discussions with FCC, the issue of non-repudiation and liability for distribution of misleading or spoofed Alerts was emphasized.
These concerns implied a design which was well suited for using the OASIS EDXL-DE distribution capability. Yesterday, I arranged a technical discussion with Gary Ham and Rex Brooks to explain some of my concerns with the current schema for CAP 1.2. There has always been the capability to “wrap” CAP 1.0 or CAP 1.1 with any appropriate wrapping metadata (e.g. OASIS EDXL-DE, W3C XML signature or encryption techniques etc.). The real question was about the infrastructure to interpret the wrapping metadata (we have a subcommittee dedicated to this).
Here are some of the issues I presented to Gary and Rex. The Emergency Management Technical Committee years ago realized the need for a publish/subscribe capability for distribution. They also realized the need for confidentiality and non-repudiation of critical information exchanges. I reminded them of the reason we created the keyXMLContent element tag. If there was Law Enforcement (e.g. Radiation detections) or Health Sensitive (e.g. HAVE messages) content being distributed, the distribution/re-distribution infrastructure might need selected information from within the embeddedXMLContent elements about the “Intent” of the distribution in addition to information extracted from embedded content and included in other EDXL-DE tags. It states:
· Extracts must come from the XML document contained within the <embeddedXMLContent> element within the current <contentObject> block.
· All content within this element MUST be explicitly namespaced as defined in the enclosing <contentObject> tag.
· MUST be a properly formed -escaped if necessary- XML string.
Since disclosure control is about only exposing “readable” information to appropriately vetted consumers, there was a need to not only encrypt the data but ensure the recipient was “authorized” to receive the decryption capability to read the information. This could only be accomplished with PKI or symmetric key technologies and additional distribution infrastructure (e.g. TSG and SPORs). This has significant impacts on the distribution/redistribution capabilities. Gary and Rex cautioned me not to go into technical details but I would be glad to provide selected individuals the reasons why both symmetric and PKI encryption are bad ideas for distributing CAP messages without appropriate wrapping metadata and supporting infrastructure. CAP 1.2 encrypted content could also break OASIS EDXL-DE infrastructure designed to “automatically” wrap time sensitive distribution like the TSG/SPOR network used by DNDO. There are many other reasons.
There is also a misconception about digital signatures and non-repudiation. It is true that a digital signature can detect the tampering of a message after it has routed through various distribution technologies. However as we have be documenting in the OASIS SOA Reference Architecture Framework documentation, non-repudiation requires Authenticity of delivered message, Proof of intent of message, and Authority of sender to request this intent in a point-to-point transaction and if it uses in a loosely coupled SOA publish/subscribe distribution capability there must also be a “Trust” anchor and transmission of trust through the routing infrastructure. Digital Signature can only provide authenticity of delivered message. The CAP Alert structure provides some proof of intent which can be strengthen by usage profiles. But there is no mechanism for determining that the “Social Structure” has authorized the transmission of CAP alert. The OASIS EDXL-DE schema has and SenderRole element but even this must be used with other technologies to bind it with authenticity and proof of its authority from the Jurisdiction in the distributed EDXL-DE message. This is the reason I don’t even like the signing of CAP 1.2 Alert messages because people assert this provides non-repudiation of the transmitted message. I do not believe this could successfully proven in a court of law. This could also create potential liabilities for the distribution/redistribution capabilities if they had some implied non-repudiation responsibilities.
Please understand that Sandia is only trying to be an honest broker for development of “international” standards per the OASIS charter. We are not trying to block need Emergency Management capability.
A clarification on the below tool issues:
Neil and I have been dealing with issues related to the implementation of CAP 1.2 in DM-OPEN 2.0 using the <any> tag and Oracle 10g SOA Suite. They are workable and probably OBE with the next implementation of the Oracle 11g SOA Suite.
The point is that they are tool issues. We will work it out.
On Feb 11, 2010, at 9:09 AM, Gary Ham wrote: