OASIS Emergency Management TC

Re: [emergency] CAP and Signatures/Encryption

  • 1.  Re: [emergency] CAP and Signatures/Encryption

    Posted 01-25-2005 00:47
     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]