OASIS Emergency Management TC

Re: [emergency] CAP and Signatures/Encryption

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

    Posted 01-25-2005 15:21
     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


    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]