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