[CAP] Decrease milling when increase trust RE: Vol7 #2

[Rudman, Richard A]

What might trust be based on when you may not know everything you need to
know about a warning originator to trust and/or you have not had experience
over time to build trust?

What if Congress would pass something called a "Warning Responsibility Act?"
While not a magic bullet panacea, might not the weight of law bring an added
measure of responsibility and authority to the process? As either part of
the enacted law, or as a separate endeavor, maybe warning originators should
have to go through some type of training leading to certification?

This training would be quite distinct from standard PIO training.
Prerequisites would be a heavy grounding in ICS, and a good working
knowledge of warning psychology. As a matter of fact, if a career PIO took
the training, I would personally submit that a certain amount of
"untraining" might have to take place.

All that having been said, including some of the above that some might see
as heresy, it would take some time for the populace to see if the process
really works. Just enacting law and training some people would not magically
grow trust. In our era, a virtual "Warning Priesthood" would have to prove
that it was above committing molestation.

Richard Rudman


on 1/10/06 10:25 AM, Art Botterell at acb at incident.com wrote:

> This is very interesting.  The challenge of building trust
> relationships on the fly arises in numerous aspects of disaster
> response.  Mutual endorsement / web-of-trust approaches sound
> attractive, although I'm not sure how we would reconcile them with
> public, bureaucratic and legal expectations about official-ness.
> 
> (One approach, of course, would be to start from the ground up to
> build "citizen alert systems" that don't base their credibility on
> official endorsements.  There'd be privacy and liability questions to
> be solved, but I don't see any of them as inherently insoluble.)
> 
> But to serve the needs of official warning systems as they currently
> exist, I think we'll be forced to accept the authority of the
> authorities, at least as regards access to systems like EAS that they
> "own."  Even there, though, there are problems of scale, there being
> something on the rough order of 80,000 different public safety
> agencies in various disciplines (law, fire, medical, etc.) and at
> various levels of government in the U.S. alone.
> 
> So maybe a hybrid approach would work... start with a cadre of
> trusted endorsers, and then apply a multiple endorsement mechanism to
> establish the authority of others.  I've heard that in Australia they
> have a system called "100 points of proof" where various kinds of
> endorsements have various point values and various thresholds (not
> always 100) are required for different activities.
> 
> My fear is that, like PKI, an approach like that would quickly be
> tossed on the too-hard stack in favor of strictly hierarchical
> systems that choke on surges but sound simple.  So maybe what's
> required here is an "existence proof"... a demonstration that these
> techniques are feasible.
> 
> - Art
> 
> 
> On Jan 9, 2006, at 8:52 AM, Mick Jagger wrote:
>> Hi,
>> To authenticate a CAP message, there are some basic methods.  The
>> first is through a trust relationship with a peer, like your
>> example here.
>> 
>>> For those ad hoc disaster responses where you need to exchange a
>>> handshake with whoever shows up (the j-random NGOs) and then do
>>> business
>>> with them fits this model.  There is, of course, no reason you can't
>>> exchange credentials, but you need to accompany them with some caveat
>>> emptors.
>> 
>> This works well in both the adhoc situation you describe, lets
>> quickly exchange keys and then we can interop, and on a more
>> permament basis with formal exchange and interop agreements in place.
>> 
>>> warning (which is where this thread started).  The agencies issuing
>>> warnings get their X.509 credentials and then make the public keys
>>> readily available in the application software that would use the
>>> warnings they'd put out.
>> 
>> The second is where a CAP specific Certificate Authority would
>> maintain a list of CAP issuer keys and if a client needed to
>> authenticate a message, they could access this CA for the
>> appropriate key.
>> 
>> Are there other appropriate methods?  Are the XML-signature/
>> encryption specs appropriate, or should upcoming CAP versions
>> include more security related elements?  Should future interop
>> demonstrations require message authentication as part of their tests?
>> 
>> -- 
>> lists at jpw.biz
>> --
>> _______________________________________________
>> This list is for public discussion of the Common Alerting
>> Protocol.  This list is NOT part of the formal record of the OASIS
>> Emergency Management TC.  Comments for the OASIS record should be
>> posted using the form at http://www.oasis-open.org/committees/
>> comments/form.php?wg_abbrev=emergency
>> CAP-list mailing list
>> CAP-list at lists.incident.com
>> http://eastpac.incident.com/mailman/listinfo/cap-list
>> 
>> This list is not for announcements, advertising or advocacy of any
>> particular program or product other than the CAP itself.
> _______________________________________________
> This list is for public discussion of the Common Alerting Protocol.  This list
> is NOT part of the formal record of the OASIS Emergency Management TC.
> Comments for the OASIS record should be posted using the form at
> http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency
> CAP-list mailing list
> CAP-list at lists.incident.com
> http://eastpac.incident.com/mailman/listinfo/cap-list
> 
> This list is not for announcements, advertising or advocacy of any particular
> program or product other than the CAP itself.