[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. Ciao, Rex 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 >>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]