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: CAP and Signatures/Encryption


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

 



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