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

-----Original Message-----
From: Carl Reed [mailto:creed@opengis.org]
Sent: Wednesday, August 04, 2004 9:16 AM
To: emergency TC lists Oasis
Subject: [emergency] RE: IETF work related to work of this TC

Yesterday during the GIS SC teleconference I mentioned that there are a number of IETF RFCs that could have an impact/synergy with the work of this TC. The majority of the work by the IETF membership WRT location has to do with either delivery of services in an EM siutation or 2.) protection of privacy and privacy encoding rules for location payloads on the internet.

I am enclosing information on a number of recent RFC submissions/updates.

Carl

emergency message