OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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

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

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.



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

> At 6:45 PM -0400 5/19/04, Speede, Kwasi wrote:
> >Yes, we "fell back" on processing against system-specific <eventCode>
> >in the broker. <Event> was not appropriate for our purposes because
> >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
> >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

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