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

[Rex Brooks <rexb@starbourne.com>]

I think that we can probably agree that one very significant part of 
our work going forward will be to decide on whether we think it is 
wise for us to take on the work of specifying mechanisms for use in 
particular transport protocols. To take Gary's preference a bit 
farther, we need to come up with specific wrappers, within the 
overall basic CAP 1.0 standard we have now. In a JSR168 context, that 
will need to be one thing, a container, while in WSRP that's the 
producer. In Kon's terms these are sources (senders-pitchers). 
Applications which aggregate portlets (specific little web services 
which a CAP application might be), are sinks, (receivers-catchers). 
How these are differentiated is something we might want to build a 
table of equivalencies for, or not, or just outright specify, which I 
hope we don't do because then we end up having to respond to each and 
every wrinkle all these myriad overlapping, and largely unnecessary 
web services organizations, consortia, application framework whosits, 
and whatnots, send out to see what sticks. Eventing certainly looks 
to be going the pub-sub route. I don't happen to favor that, but I 
have already resigned myself to it.

I don't love this thicket of competing standards, or standards 
efforts to be more accurate since few actual standards have 
emerged--a couple from WS-I*, some from W3C, and WSRP from OASIS and 
a whole raft of others-- but that's what is going on, so we are bound 
to have more not less choices to make, and we are going to have to 
make some of those choices, regardless.

Encryption, PKI, XML Signatures in SOAP and DIME and SOAP with 
Attachments, Access Control, SAML, Roles, Permissions, Rights--the 
whole kit and kaboodle. In WSRP we have so far just punted it over to 
those TCs and working groups, but the day is coming when some 
decisions are going to have to be made there, too.

Ciao,
Rex


At 6:07 PM -0500 3/26/04, R. Allen Wyke wrote:
>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
>
>
>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
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request