All:
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.
Dave
From: Gary Ham
[mailto:]
Sent: Thursday, February 11, 2010 7:22 AM
To: Gary Ham
Cc: ; Bryan Field; Mark Lucero; Dean
Rychlik; ARTHUR C III CTR DISA JITC BOTTERELL; Roderick [USA] [USA] Cash; Neil
C Bourgeois
Subject: [emergency] Re: CAP 1.2, Encryption, and DM-OPEN
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:
Folks,
As you may or may not know we had some discussions concerning implementation
difficulties with CAP 1.2. For the most part those issues are
tool-related and can be dealt with (although the work level is still TBD).
Encryption is, however, a different matter and would be very hard to do
in a CAP 1.2 environment. Bottom line is this, we support CAP 1.2, but we
will not be handling encrypted traffic on the CAP interfaces. The
essential story follow:
Here is a message I drafted for all of you to review, but sent to for vetting
to Art Botterell and Mark Lucero (IPAWS):
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. They are workable and
probably OBE with the next implementation of the Oracle SOA Suite. So, the
initial DM-OPEN 2.0 will be CAP 1.1 with CAP 1.2 to be part of the first fully
IPAWS capable follow-on release. In looking at the
<any> issue I came across what might be a bigger worry down the line.
If you choose to encrypt the content of the CAP message in a CAP only network,
every node on the network that the CAP message can be sent to (or through as in
network to network traffic) must be able to decrypt the message in order to
read it or to get the needed information to pass it on. At the number of
network nodes grow in a network of networks, key management will become an NP
hard problem, growing at an exponential rate. This my be the reason so little
encryption of CAP 1.1 messages has occurred. My point is that encryption
of CAP 1.2 in a CAP only network will be extremely hard to manage. Signatures
can be handled. Encryption; not so well. Your thoughts are welcome.
Art's response:
But what's the requirement for encryption in a public warning system?
Encryption tends to get confused with authentication because of the Web 1.0
practice of using passwords (or certificates) to authenticate sessions or
connections, and then assuming that anything arriving over the trusted link
must itself be authentic.
In that case encryption is required to protect the integrity of that individual
link, whether or not there's any requirement for privacy of the actual
communication. (And of course any compromise at either end of the link
means the whole game's over.)
By applying authentication to the individual messages, rather than to the
links, the question of encryption becomes orthagonal to that of authentication.
Each message is provably authentic or not, regardless of how it arrived
or where it's been. And encryption can be evaluated separately and on its
own merits.
Bottom line, I think the reason there's been so little encryption of CAP alerts
is that there's been no particular requirement to keep the contents of public
warnings secret.
Mark Lucero's response:
You're correct, Art. IPAWS requirements are: Low Confidentiality, High
Integrity, High Availability. We don't want to encrypt anything, we
only want to ensure the message has not been altered (high integrity).
This infers the need for digital signatures, but there's no need to
encrypt anything.
My Bottom line:
Since we will not be encrypting or accepting encrypted CAP on the DM-OPEN CAP
Interfaces, we can make CAP1.2 work in its other capacities for public
warning. If you do need to transport an encrypted CAP message, you can
use the DM-OPEN DE interface with an encrypted CAP payload, but the recipient
systems will have to know how to know how to retrieve DE messages from DM-OPEN
and decrypt them on their end.
Respectfully,
Gary Ham
Systems Architect
FEMA Disaster Management Program
703-899-6241
Gary Ham
http://grandpaham.com
703-899-6241
