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

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. :)


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]