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

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

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