OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [emergency] CAP and Signatures/Encryption

Hi Everyone

I concur.


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 
>>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.
>>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 

Rex Brooks
President, CEO, Starbourne Communications Design
Executive Director, Humanmarkup.org, Inc.
1361-A Addison
Berkeley, CA 94702

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]