MHonArc v2.5.0b2 -->
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
>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]