Re: [emergency] CAP Visualization (was RE: CAP Developers' Forum...)

["Carl Reed" <creed@opengis.org>]

Art -

The RAINS organization (Oregon) is defining best practices for secure
infrastructures for emergency services. They have determined that CAP is a
protocol that will be part of their secure information infrastructure. It
might be interesting to contact them WRT how they are dealing with security
and authentication issues.

Cheers

Carl
OGC


----- Original Message ----- 
From: "Art Botterell" <acb@incident.com>
To: "Speede, Kwasi" <Kwasi.Speede@associates.dhs.gov>; "'Jeff Kyser'"
<ktrails@comcast.net>
Cc: <emergency@lists.oasis-open.org>
Sent: Wednesday, May 19, 2004 9:32 PM
Subject: RE: [emergency] CAP Visualization (was RE: CAP Developers'
Forum...)


> At 6:45 PM -0400 5/19/04, Speede, Kwasi wrote:
> >Yes, we "fell back" on processing against system-specific <eventCode>
values
> >in the broker. <Event> was not appropriate for our purposes because
multiple
> >instances cannot be defined for a single message scenario.
>
> Yes, I'm afraid it was a mistake to make <category> optional... as
> arbitrary as our interim taxonomy was, I haven't come across anything
> better.  And perhaps it should be made multiple, too, in CAP 1.1.
>
> >I am curious about the different approaches that are evolving or being
> >proposed for determining who are the authorized CAP message originators
> >across various implementation communities and how developers are
intending
> >to authenticate their messages when processing CAP.
>
> This is a huge issue that cuts across a wide range of applications.
> First off, you're right to distinguish between the policy question of
> authorization and the technical problem of authentication.
> Especially at the local level, policies about authorization are
> liable to vary, which could make inter-system policy complicated.
> But as with spam, rules don't really matter until we can authenticate
> individual messages.
>
> The simple approach to that, and the one most widely implemented so
> far, is to establish access control at the individual server level,
> using something like passwords secured by SSL.  The good thing about
> that is that it's easy to implement.  The bad thing is that it's a
> single-hop model, with no inherent way of ensuring the "end-to-end"
> integrity or authenticity of a message that traverses more than one
> system.
>
> An attractive alternative is to use digital signatures, which can
> verify both integrity and authenticity no matter how a message got
> routed... but that requires a public key infrastructure (certificate
> authorities, certificate revocation lists, etc.)  While the standards
> are there, nobody's stepped up to the task of coordinating it for the
> 80,000 or so local safety agencies in this country.  (The OASIS PKI
> TC has a project right now to try to identify and address the
> roadblocks to uptake of the existing standards and technologies.)
>
> And, of course, there are hybrid approaches possible.  For the
> California EDIS rebuild we're using server-based authorization for
> the individual agencies, but we may apply a global digital signature
> to the content at the state level so forwarded messages can be
> authenticated at least as far back as the state OES gateway.
>
> - Art
>
> 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.
>