Long time members of this working-group will remember my
frequent complaints concerning the statement in the CAP Protocol specification
that CAP provides a "Facility for digital encryption and signature
capability". I see that this text has been carried over into the CAP 1.1
draft and am compelled, once again, to object. Other then the statement that a
facility is provided, there is no mention in the CAP specification of either
encryption or signatures. Thus, I simply cannot understand how the claim can be
made that the “facility” exists. I strongly believe that the claim
should either be removed or it should be made accurate. The preferred
resolution, of course, would be to make it accurate -- at last...
In order to adhere to the CAP "Design Philosophy"
it is critical that the specific methods that can be used to create signatures
and perform encryption should be specified. Only in this way can we ensure that
CAP provides "provide a means for interoperable exchange of alerts and notifications
among all kinds of emergency information systems". For the
interoperability goal to be met, implementers must be able to anticipate the
mechanisms that will be used without having to engage in detailed format
negotiations or discovery outside the CAP specification itself. Additionally,
it makes sense to use mechanisms that are commonly known and implemented.
It is also important to specify the precise mechanisms that
are to be used in order to meet the goal of "Completeness" that
requires that CAP "provide for all the elements of an effective warning
message". Given that Signatures are reasonably expected to be part of an
"effective warning message" since they are critical to enabling
messages to be "trusted", the means for creating such signatures must
be specified in order to have a "complete" specification of the CAP
Alert Message.
I believe that it is commonly accepted in the XML
"community" that the W3C recommendations concerning signatures and
encryption for XML are the "correct" way to provide for signatures
and encryption in XML formatted texts. As a result, these W3C recommendations
are becoming widely used and widely implemented. Thus, it seems reasonable that
these mechanisms should be used by CAP in order to leverage existing knowledge,
code libraries, etc.
Given the observations above, I would like to propose that
the words below, or equivalents, be considered for inclusion in the CAP
specification. Note: I'm suggesting that signatures and encryption be applied
only to a CAP message as a whole. Clearly, this is more restrictive then is
possible; however, such a restrictive policy will work best in ensuring
interoperability since it reduces significantly the complexity of message
handling and assures meeting the CAP Design goal of “simple implementation”.
More complex schemes could, of course, be defined within closed networks by
local agreements and might be considered in future updates to CAP after actual
field experience reveals any significant issues that might exist with the
constrained specification proposed here. In any case, the proposed "whole
message only" support would be a subset of any proposal that allowed more
granular signing or encrypting. Thus, it is at least a step in the right
direction.
====================================
X.X Securing CAP Documents
Because CAP is an XML-based format, existing XML security
mechanisms can be used to secure its content. While these mechanisms are
available to secure CAP Alert Messages, they should not be used
indiscriminately.
X.1 Digital Signatures
The alert element of a CAP Alert Message MAY have an
Enveloped Signature, as described by XML-Signature and Syntax Processing
[W3C.REC-xmldsig-core-20020212]. Other XML signature mechanisms MUST NOT
be used in CAP Alert Messages.
Processors MUST NOT reject a CAP Alert Message containing
such a signature simply because they are not capable of verifying it; they MUST
continue processing and MAY inform the user of their failure to validate the
signature.
In other words, the presence of an element with the
namespace URI "http://www.w3.org/2000/09/xmldsig#" and a local name
of "Signature" as a child of the alert element must not cause a
processor to fail merely because of its presence.
X.2 Encryption
The alert element of a CAP Alert Message MAY be encrypted,
using the mechanisms described by XML Encryption Syntax and Processing
[W3C.REC-xmlenc-core-20021210]. Other XML encryption mechanisms MUST NOT
be used in CAP Alert Messages.
References:
W3C.REC-xmldsig-core-20020212:
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
W3C.REC-xmlenc-core-20021210:
http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/
====================================
Adopting this proposal would add two tags to CAP (by
reference). These are: "Signature" and "EncryptedData".
Both elements would be children of the <alert> element and would be
optional. If the "EncryptedData" element exists, no other elements
would be visible until after the message was decrypted. This would make the
minimal CAP message an alert element which encloses an EncryptedData element.
The maximal CAP message, if an EncryptedData element is present, would be an
<alert> element enclosing a single EncryptedData element and a single
Signature element.
bob wyman
CTO, PubSub.com