OASIS Emergency Management TC

RE: [emergency] CAP and Signatures/Encryption

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

    Posted 01-27-2005 21:02
     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


    Len Bullard wrote:

    > Someone will have to pare this down before it has to operate in real time.

                I whole heartedly agree! In general, for an effort such as this, options, flexibility, and variety are *bad* things. We should be doing what we can to define a strict protocol that provides very little opportunity for misunderstanding and maximizes interoperability – even if the cost is a potential loss of expressiveness. The more ways there are to do something, the more ways there are to misunderstand. Misunderstandings could cost lives or property.

                The “normal” rules and customs which encourage flexibility in other communications and applications protocols should not apply to this effort.

                            bob wyman


    From: Bullard, Claude L (Len) [mailto:len.bullard@intergraph.com]
    Sent: Tuesday, January 25, 2005 11:07 AM
    To: ''; 'bob@wyman.us'; 'Kon Wilms'; 'Art Botterell'
    Cc: 'emergency@lists.oasis-open.org'
    Subject: RE: [emergency] CAP and Signatures/Encryption

    I hope someone is simulating this system.    As I read through the byzantine numbers of

    organizations, protocols, structures and policies that make up the NRP document, and

    try to imagine assembling a just in time interoperating network of networks for C2 given

    an ongoing INS, it makes the problems of 9/11 pale in comparison.

     

    It is one thing to be transport-agnostic; it is quite another to have so many options at

    so many layers that the system simply cannot be operational quickly enough to meet

    the requirements.

     

    Someone will have to pare this down before it has to operate in real time.

     

    len


    From: [mailto:creed@opengeospatial.org]

    Interesting discussion. I would like to add that are also a number of Internet standards (IETF) that deal with encryption and are used for encrypting messages, such as e-mail. This includes the work of the IETF S/MIME working group, specifically the S/MIME electronic mail security protocol that is widely implemented in commercial mail agents. If you want something a bit more low-level, I would also check out the work of the IPSEC group, specifically RFC 3686 - Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP). This standard incorporates the NIST standard that defines five modes of operation for AES and other FIPS approved block ciphers [MODES].

    As Bob suggests, rather than the EM TC define a new method of encryption, I would opt for a statement of best practices for encrypting a CAP message using existing, well known industry standards.

     

    Regards

     

    Carl



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