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