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