Re: [emergency] Message encryption -- was RE: [emergency-comment] RE: [CAP] RE: CAP-list digest...)

[R. Allen Wyke <emergency-tc@earthlink.net>]

You nailed it! Exactly what I am [trying] to say.

On Mar 26, 2004, at 5:21 PM, Kon Wilms wrote:

>> I completely agree - not part of CAP. That being said, just as using
> SSL to define/profile "how" pages should be sent securely across HTTP,
> we do need to address transporting the data to ensure we done a bunch
> of servers (aka implementations) doing their own thing. Otherwise
> nothing will work. We need to provide at least some level of guidance.
>
> True. There needs to be a list of what protocols can be used, in what
> combination they should be implemented, which is preferable, and what 
> the
> encryption guidelines are (minimum key length, cipher mechanism (AES 
> FIPS,
> etc.), etc.). Tracked through the OSI layers and application layers, 
> this
> would be fairly compelling as a guideline for anyone, no matter how
> notty-gritty they want to get.
>
> This is more important for people who are developing solutions that 
> will tie
> in to third party solutions -- i.e. they are either a source or sink.
>
> For those that control the source and sink (such as a broadcaster), the
> solution can be any that they choose (cherry picking of encryption 
> transport
> solutions and packetizers is commonplace, and wach vendor may use the 
> same
> standard algorithms in a different/proprietary way), as long as it 
> meets the
> same basic encryption baseline requirements when transporting the 
> message.
> However, where the receiver acts as a source or the headend acts as a 
> sink
> for CAP messages, these need to obey the two-way network guidelines.
>
> Anyway I'm all for spelling things out, vs. some sort of nebulous
> pie-in-the-sky generalizations about what to use for transport
> implementation.
>
> Cheers
> Kon

--
R. Allen Wyke
Chair, OASIS Emergency Management TC
emergency-tc@earthlink.net