[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] CAP and Signatures/Encryption
True, Kon, I believe that is why the word MAY is used, but we might want to just acknowledge those cases to avoid any confusion. Ciao, Rex At 08:10 PM 1/24/2005, Kon Wilms wrote: >Any encryption mechanisms requiring two-way authentication for the >purposes of key exchange where two-way communication is not available, >will obviously not work. > > > >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. > >For certain network delivery mechanisms, other XML encryption mechanisms >are the *only* way to secure the data. If the point above is followed, >then broadcast delivery mechanisms will be forced to deliver data in the >clear in order to be compliant with the spec. > >Perhaps it would be a good idea to change the last line to 'Other XML >encryption mechanisms may be used only if they use FIPS approved >processing rules and algorithms.' > >Broadcast delivery encryption is for the most part identical in process >to the references Bob has noted, minus some changes in keywrap, symmtric >block modes that can be used, and where the keys are processed on the >host. Plus ofcourse the TLAs. :) > >Cheers >Kon > >On Mon, 2005-01-24 at 16:46 -0800, 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]