Hi Everyone
I concur.
Ciao,
Rex
At 04:46 PM 1/24/2005, Art Botterell wrote:
>Friends -
>
>I know we've tried to keep security distinct from the content standard,
>and that these issues could be addressed more comprehensively in the EDXL
>framework. And in fact there is a specific recommendation of the OASIS
>WS-Security framework for securing CAP messages in section 3.3.3 of the
>current and draft specs.
>
>However, since I suspect production requirements for signed and/or
>encrypted CAP messages are likely to arise prior to our having EDXL or CAP
>2.0 in-hand, I'm inclined to support Bob's specific proposal for CAP 1.1.
>
>- Art
>
>At 5:19 PM -0500 1/9/05, Bob Wyman wrote:
>>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
>
>
>To unsubscribe from this mailing list (and be removed from the roster of
>the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.
>
>
Rex Brooks
President, CEO, Starbourne Communications Design
Executive Director, Humanmarkup.org, Inc.
1361-A Addison
Berkeley, CA 94702
510-849-2309
