OASIS Emergency Management TC

RE: [emergency] RE: IETF work related to work of this TC

  • 1.  RE: [emergency] RE: IETF work related to work of this TC

    Posted 08-04-2004 21:13
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    emergency message

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


    Subject: RE: [emergency] RE: IETF work related to work of this TC


    Relating to IF –

     

    We had the same type of transport wrapper and descriptor issue for the ATSC data broadcast standard. In the end the solution was to build it on subset building blocks. It may be worth a look to read these documents in the context of what concepts they themselves are re-using (S/MIME, SAP, etc.). A solution for creating a wrapper came from taking the smaller building blocks and creating a spec for transport over that.

     

    Relating to geolocation and directing of EM messages to recipients –

     

    In the broadcast world settopboxes and devices are addressed as ‘targets’. Each has a unique identifier and is aware of its location (via zipcode typically). Secure addressing of these devices is usually done by a keystream comprising of wrapping a symmetric key (or set of) within a PK encrypted packet with the target ID affixed. The target ID is directly associated with the PK at the transmission end. The receiver filters on its target ID, decrypts the packets, and uses the symmetric key to decrypt a secondary stream which carries the ‘real’ information (i.e. the CAP messages). Although there is a standard spec for transport, everyone does encryption differently (albeit everyone may use the same encryption standards (AES192, etc.).

     

    I’m noting this because it should be kept in mind when looking at specifications for transmitting data over the internet, as some interface will be needed between the internet world and broadcast world, and when people start using specs that say ‘MUST use S/MIME’ which may not map to the broadcast realm, we start limiting the usability of the message because of restrictions brought about in the transport layer.

     

    The transport SC also needs to possibly add to the list of requirements that interfacing be defined or guidelines given as to the hand-off of secure and targeted data between different flavors of delivery networks, and what the minimum requirements are for maintaining security and integrity of the data at the handoff, on the platform performing the translation, and at the retransmission of the data from said platform onto the next network segment.

     

    Cheers

    Kon