Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Sat, 2 May 2009 15:38:30 -0400

Authority is government

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Sat May 02 11:51:10 2009
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

On May 2, 2009, at 5/2/09 3:26 AM, Janet P Gunn wrote:

> How many people here know PRECISELY what "exigent" means without  
> looking it up.
>
> You need a term that has wider comprehension.

Unfortunately, not many folks know precisely what "early warning"  
means either, although many assume they do until you press them for  
specifics.

It seems like the current terms of reference are heavily loaded with  
emotional and cultural baggage.  That's the problem with the word  
"authority"... it has several different senses and ultimately involves  
a subjective, or at least individual, interpretation of who and what  
constitutes authority (Government? Church? Academe? Culture?)

"Warning" is likewise a fairly subtle notion when you really start to  
unpack it.  In my particular public warning system we define it  
narrowly as "information about imminent threats to human life or  
health"... but other practitioners frame it differently.  The word  
also spans the distinct domains of attention-management and  
information-sharing (is it a warning if folks are already aware of the  
subject matter?)

So I'm wondering... might it be more productive to specify the  
particular observable characteristics we're concerned about (latency,  
reliability, verifiability, etc.) we're hoping to achieve rather than  
sloshing around in non-technical semantics?

I get the sense that at least some of us are primarily concerned with  
the use of SIP, and although I have no personal investment in that  
particular approach, at least it sounds like the frame for a tractable  
technical problem.

- Art
_______________________________________________
earlywarning mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/earlywarning

---

From: Art Botterell <[email-masked]>
Date: Sat, 2 May 2009 12:47:10 -0700

If so, why not say "government"?

---

From: ken carlberg <[email-masked]>
Date: Sun, 3 May 2009 09:13:34 -0400

a good point.  What the previous poster failed to elaborate on is that  
other SDO's like the ITU have made the association of authority ==  
government, and given us terms and classification of communication  
models comprising:

citizen-to-citizen, citizen-to-authority,
authority-to-authority, and authority-to-citizen

which is why we are seeing this terminology creep up on this list.   
one could take the approach that the IETF will go its own way, but I  
think it will be more constructive to acknowledge what's already  
gained traction and explore other terms.  and in this specific case,  
something other than "authority" if we want to expand the target model.

-ken

---

From: Art Botterell <[email-masked]>
Date: Sun, 3 May 2009 09:32:54 -0700

We can justify the term "authority" by appeal to authority (ITU, etc.)  
but I'm not sure that brings us any closer to an implementable spec.   
The problem arises when we try to build from inherently fuzzy terms  
like "authority" and "warning" to specific technical requirements.

It sounds like what we're really talking about is transport of  
infrequent one-to-many communications of particular importance and  
urgency.

- Art

On May 3, 2009, at 5/3/09 6:13 AM, ken carlberg wrote:

> a good point.  What the previous poster failed to elaborate on is  
> that other SDO's like the ITU have made the association of authority  
> == government, and given us terms and classification of  
> communication models comprising:
>

---

From: Tony Rutkowski <[email-masked]>
Date: Sun, 03 May 2009 13:05:14 -0400

Hi Art,
> like "authority" and "warning" to specific technical requirements.
The quick ITU-T answer is likely to be that this is a national matter. 

Rec. X.1303 encompasses a broad array of potential implementations. 
> constructive to acknowledge what's already gained traction and explore
> other terms.  and in this specific case, something other than
> "authority" if we want to expand the target model.
This is the way to go.

--tony

-- 
Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 703.999.8270

---

From: Art Botterell <[email-masked]>
Date: Sun, 3 May 2009 10:12:15 -0700

Tony -

Not sure I follow you... how would developing technical requirements  
be a national matter?  Or more to the point, if it is, then what are  
we doing here?

As for X.1303/CAP... that's a content standard.  Seems like the issue  
here is transport, about which the CAP spec is aggressively agnostic.

But again, seems like we're all over the map on our assumptions.  Are  
we, in fact, talking transport, or what?

- Art

---

From: Tony Rutkowski <[email-masked]>
Date: Sun, 03 May 2009 13:24:37 -0400

Hi Art,

My reference was with the idea that the ITU would somehow be
defining who "authorities" were for the purposes of specific national
implementations where "authority" needed to be designated.
Provisions such as the FCC's Part 10 rules specify specify this.

The better approach is the more generic one that you advocate.

--tony

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 3 May 2009 20:24:19 -0500

I worry that this discussion has lost focus.  Are we talking about terms for use in relation to a protocol, or terms in relation to problem statement and naming (marketing)?  They can be separated.

The terms that Hannes proposes (Author and Recipient) would be quite suitable for use in describing a protocol and architecture.

Is this really the venue for deciding who applies this protocol solution?  Not that I'm suggesting we design in a vacuum, but we each have a fair idea of what the goals are; and I truly don't think that there are major differences of opinion.  The subjective definition of "authority" need not be a barrier to progress.

I'm happy with marketing with vague terms like "authority-to-citizen" or "early warning" and having separate terms in protocol land.  That's been successful in the past; the abstraction allows for a little flexibility in interpretation.  That flexibility is sometimes useful.

I tend to agree with Art that we can spend a lot of time on the non-technical stuff.  Maybe abstraction offers us a way to make process on the technical side while we "slosh around" on the fuzzy issues.

--Martin

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Richard Barnes <[email-masked]>
Date: Mon, 04 May 2009 10:06:33 +0200

+1

Also, under the "marketing" header, it will probably be useful to put 
together some mapping between the more general terms we'll use for 
protocol development and the specific terms used, e.g., by ITU-T.

--Richard

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 4 May 2009 08:42:52 -0400

As with any IETF effort, limiting scope is useful to get progress in a
reasonable time.  With this effort, we have tried to limit the scope of
"authority".  It would be okay with me if we did limit it to government
initially, although eventually I suspect we will expand it.

I am very comfortable leaving the terminology as is: authority to citizen.
I think we can reasonably explain that authority is initially government
(national, state/province/region/, and local).  We can reasonably explain
that citizen includes residents and visitors.

I'd like to keep the discussion more on the scope than on the terminology.  

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of ken carlberg
Sent: Sunday, May 03, 2009 9:14 AM
To: Art Botterell
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global
CAPcommunity

-ken

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 4 May 2009 09:20:01 -0400

This distinction is unlikely to work in the US, at least, as there are  
many quasi-governmental entities. Classical example: some of the  
largest scale notification systems today are deployed by college  
campuses, particularly after the Virginia Tech shooting. There is no  
technical reason why such function should be available to state  
colleges and universities, but not to private institutions (which, in  
the US, are in no way governed by the Federal or state government).  
Same is true for large school districts, which can be either run by  
the city/county or, say, the Catholic Church.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 4 May 2009 09:35:33 -0400

It's probably not quite that simple, but generally, yes, I think we're
mostly concerned with how a message in a defined format (CAP) gets from the
authority to the citizen.  I don't think anyone is arguing we aren't
leveraging the CAP work.

There are undoubtedly issues with doing content the IETF way, as we usually
deal up front with issues like a wide range of devices with different
capabilities that need to render the alert, as well as language issues, etc.
So, it's not JUST transport.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Art Botterell
Sent: Sunday, May 03, 2009 12:33 PM
To: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global
CAPcommunity

- Art

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 4 May 2009 10:01:55 -0400

Finally, a meaty subject; terminology really doesn't get us very far.  This
is important; really narrowing scope.

Let's take a look at how far do we want to go:

National Government with major warning - impending attack
Regional Government with life threatening event - Tornado or flash flood
Local Government with life threatening event - hazmat spill
Local Government with important, but not threatening event - major traffic
tieup
Local Government with useful event - public school closing
State Government College with life threatening event - school shooting
Private College with life threatening event - school shooting
Private elementary school with useful event  - school closing
Enterprise with life threatening event - hazmat spill
Enterprise with useful event - building closing due to weather

It's clear to me that all of these are very useful alerts.  The question
becomes, which of these should be in scope for the first charter?

It seems to me that the issue of authorization is the biggie here, and if we
started out limiting to government, even local government, it gets a lot
easier. Once you allow a non-government entity to notify using the
mechanism, we make the authorization decision much more difficult.  I don't
see an in-between way to slice the above list other than government/non
government unless you say that the government can authorize other entities
and you are relying on that authorization.  

I think the wishes of the networks that are transporting the alerts come
into play; they would want a bright line on authorization.

I suspect that once you have an authorized entity that can create an alert,
what it gets to use that authorization for is a less interesting (to the
IETF) issue.  If you can issue alerts, you can issue any kind of alert.

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 9:20 AM
To: Brian Rosen
Cc: 'ken carlberg'; 'Art Botterell'; [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global
CAPcommunity

Henning

---

From: "Carl Reed" <[email-masked]>
Date: Mon, 4 May 2009 08:36:54 -0600

Martin -

Thanks for this perspective.

I also was beginning to worry about mixing "apples and oranges" in this 
discussion. The rules of use and distribution of an alert and the alert 
payload itself are two different (but related) animals. As an example, 
GeoRSS is used in numerous consumer, unrestricted alerting applications. No 
thought to security, authentication, quality, etc. At the other extreme, 
GeoRSS is now also used in a secure Intelnet application. Obviously very 
different use cases with very, very different requirements for 
authentication and security. And different vocabularies/semantics. But the 
identical payload info model, schemas and so forth.  Same with CAP. Whether 
a Presidential alert has priority or not is not relevant to the CAP info 
model and structure. What is important in terms of where the authentication 
is performed, the priority setting, and so forth is the actual alerting 
architecture and infrastructure.

Carl

----- Original Message ----- 
From: "Thomson, Martin" <[email-masked]>
To: <[email-masked]>; "Art Botterell" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, May 03, 2009 7:24 PM
Subject: Re: [earlywarning] Deprecate "Authority" - was : global 
CAPcommunity

>I worry that this discussion has lost focus.  Are we talking about terms 
>for use in relation to a protocol, or terms in relation to problem 
>statement and naming (marketing)?  They can be separated.
>
> The terms that Hannes proposes (Author and Recipient) would be quite 
> suitable for use in describing a protocol and architecture.
>
> Is this really the venue for deciding who applies this protocol solution? 
> Not that I'm suggesting we design in a vacuum, but we each have a fair 
> idea of what the goals are; and I truly don't think that there are major 
> differences of opinion.  The subjective definition of "authority" need not 
> be a barrier to progress.
>
> I'm happy with marketing with vague terms like "authority-to-citizen" or 
> "early warning" and having separate terms in protocol land.  That's been 
> successful in the past; the abstraction allows for a little flexibility in 
> interpretation.  That flexibility is sometimes useful.
>
> I tend to agree with Art that we can spend a lot of time on the 
> non-technical stuff.  Maybe abstraction offers us a way to make process on 
> the technical side while we "slosh around" on the fuzzy issues.
>
> --Martin
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 4 May 2009 10:42:55 -0400

Why is authorization easier for government? A school, university or  
company generally knows all of its students and employees, and can  
thus easily, relatively speaking, provide their public key to them  
ahead of time, so that an alert can be trivially verified as to its  
authenticity. For that, it doesn't matter whether the organization is  
run by a government (say, the Port Authority of NY&NJ) or a private  
entity (Columbia University). (I guess sending alerts to GM and  
Citibank would still be ok...). I'm ignoring the problem of university/ 
company visitors, as most existing alert systems don't deal with them,  
and reasonably rely on the "regulars" to tell them what's going on.

The case of alerting is much harder for entities who need to reach  
everyone who happens to be in their territory, such as a county. They  
have to distribute some cryptographic material to everybody, including  
visitors, without knowing who they are.

Thus, the operative difference seem much more of a "closed" vs. "open"  
membership, rather than whether the entity operating the alert has a  
seal and calls it itself county or state government.

Henning

On May 4, 2009, at 10:01 AM, Brian Rosen wrote:

>> that

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 4 May 2009 11:04:44 -0400

I think it's easier for the networks which have to allow these alerts (and
treat them in some way we need to define) to know who the government
entities are.

That does bring up the issue that multiple entities need to authenticate the
alert source.  You are focused on the recipients, I mentioned the networks.
We don't know yet who might be operating the message routing infrastructure,
but it certainly is likely the network operators and, as in ecrit, there is
the access network and the "calling" (VoIP/IM/...) network/service provider.

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 10:43 AM
To: Brian Rosen
Cc: 'ken carlberg'; 'Art Botterell'; [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global
CAPcommunity

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 4 May 2009 12:01:38 -0400

> treat them in some way we need to define) to know who the government

I'm not sure I understand what you mean by "networks". I can see that  
this might be possible for SMS, but how would a SIP MESSAGE-delivering  
server know that (or care)?

> We don't know yet who might be operating the message routing  

Are you talking SIP proxies (or XMPP servers, etc.) or some other  
entity?

>
> but it certainly is likely the network operators

Why? This seems much more like an application-layer function to me,  
and just like ECRIT made the wise decision to separate application and  
network layer operators, we should do the same.

> and, as in ecrit, there is

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 4 May 2009 12:30:34 -0400

Although I hope we end up with an opt-in subscription option, the minimum
required here is a broadcast.  That requires some entity to direct the
broadcast, based on location.  That in turn means that we have the network
operators, probably BOTH the access network (who knows the location) and the
alert application service provider.  The latter could be some public entity,
but I think it's unlikely.  More likely is that it's some SP that already
provides a service like texting.  It may be that the access network also
provides such a service, don't know, but I do hope we keep the access
network operator separate from that SP in our work.  Then, they could be
operated by the same entity or different entities.  The latter probably does
run some kind of SIP server/XMPP server or whatever we use for transport and
routing.

Whomever it is, it will need to authenticate and authorize alert senders
independent of end devices authentication and authorization.  I think
starting with governments makes authentication (and authorization) easier.

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 12:02 PM
To: Brian Rosen
Cc: 'ken carlberg'; 'Art Botterell'; [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global
CAPcommunity

---

From: ken carlberg <[email-masked]>
Date: Mon, 4 May 2009 12:58:05 -0400

On May 4, 2009, at 12:30 PM, Brian Rosen wrote:

> required here is a broadcast.

could you be a little more precise?  Does this means that if some  
transit network prefers an application layer solution (let's say in  
the form of application layer multicast -- ie, unicast-only  
dissemination via a collection of servers) and chooses not to support  
a network layer broadcast (or multicast) solution, they are out of the  
picture?

> That requires some entity to direct the

I'm with Henning in still wondering what is it technically (or even  
policy) that makes authentication/authorization "easier" for  
governments than some other non-government enitity/organization.

-ken

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 4 May 2009 13:16:06 -0400

My general concern is that we seem to be making general statements  
like "need government" that are driven by assumptions of the technical  
realization that we haven't really discussed. That seems like a  
somewhat unusual way to deal with engineering requirements and  
charters. The danger is that such statements then get applied to  
situations where they make little sense. If I subscribe, via sips, to  
a SIP event notification and have the notifiers public key, none of  
these considerations apply, for example.

Henning

On May 4, 2009, at 12:58 PM, ken carlberg wrote:

> dissemination via a collection of servers) and chooses not to  
> support a network layer broadcast (or multicast) solution, they are  
> out of the picture?
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 4 May 2009 13:48:26 -0400

It would help to go back to the charter language.

The current proposal is (in part):
The class of alerts that are of interest to this working group are those
sent by authorized agents, primarily government agents.  The mechanisms that
result from this work may be applicable to a wider group of authorized
agents, but our current work is focused on emergency alerts from
governments.  Nevertheless, we desire to design this mechanism so that it
can be used by national, regional or local authorities and cover alerts for
impending Tsunamis which might affect most of a county down to a road
closing due to an automobile accident.  A critical element of the work are
the mechanisms that assure that only authorized agents can send alerts.

The recipients of these alerts are the wide range of devices connected to
the Internet and private IP networks which humans may have "at hand" to get
such events, as well as automatons who may take action based on the alerts.
This implies that the content of the alert contains some information which
is intended to be consumed by humans, and some which is intended to be
consumed by automatons.  Ideally, the alerts would contain, or refer to
media other than text media (cf audio and/or video), but the present work is
restricted to human readable text, which may be mechanically rendered by the
device in other forms (text to speech for example).   

Which devices should get alerts is primarily driven by location.  The first
set of recipients that must be catered for are those within the area
affected by the alert.  In many jurisdictions, there are regulations the
define whether recipients within the affected area have opt-in or opt-out
capability, but the protocols we will define will include both opt in and
opt out mechanisms.  This work builds on existing IETF geopriv location
work.   

Another class of recipients that are in scope of the work are explicit
opt-in subscriptions which ask for alerts that are sent to an associated
party.  An example of such a subscription would be "send me alerts which are
sent too my daughter based on her location".  

Both of these classes of recipients must operate at Internet scale, which is
one of the major challenges to the work.  Many tools have been developed
within the IETF to scale messaging, which will be exploited by this effort.
Examples include multicast.  The work must function on the networks we have,
however, and as such must take into account what is actually deployed, or
could reasonably be deployed.

--- end of proposed charter language ---

The charter, like any charter, attempts to limit scope, without presenting
cast in concrete solutions.  I think if we tried to handle too wide a range
of alert generators, we would have problems, both in getting a charter
approved and in getting the work done.  I too would LIKE to handle a wider
range of alert generators.  However, I think limiting scope to primarily
government agents is a helpful thing for the first charter.

Similarly, we have to handle the "broadcast" situation, and I don't mean the
word to imply multicast, but rather the notion that everyone gets the alert
if they are in the affected area, with the possibility that opt-out is not
allowed.  The mechanism by which we get the alert to all devices in the
affected area is TBD.

While I think having every notifier's public key is a nice solution to an
authentication problem, it might be hard to arrange.  Among other things,
you have to be able to get off a plane and get alerts from local
authorities.  Right now, I don't want to discuss solutions, but charter
language, and I'd rather have narrow scope.

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 1:16 PM
To: ken carlberg
Cc: Brian Rosen; 'Art Botterell'; [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global
CAPcommunity

Henning

---

From: Ted Hardie <[email-masked]>
Date: Mon, 4 May 2009 10:59:25 -0700

>It would help to go back to the charter language.
<snip>

>sent too my daughter based on her location". 

This seems to imply that the system must track whether or not
an alert was sent to your daughter (and hence her opt-in state),
rather than simply saying "send me alerts for the follow area,
in which I am not currently present".  It is then up to you to designate
the area.  This is simple.  The "track your daughter" system is hard,
and it has serious privacy consequences.

If you simply want your daughter's user agent to echo alerts to you,
I think that is also possible--but it would be separate from this system
entirely and its opt-in characteristics are clearly different..

		regards,
			Ted

---

From: Ted Hardie <[email-masked]>
Date: Mon, 4 May 2009 12:20:38 -0700

At 11:56 AM -0700 5/4/09, Brian Rosen wrote:
>I don't care how we get there.
>
>The notion of the system "tracking" my daughter doesn't bother me as long as
>all we're getting out of that is the same alerts. 
>We're not really tracking, we're replicating an alert that went to her.

Let's say your daughter failed to opt-in to the Tsunami warning because
she was on the U.S. East Coast, and they are incredibly rare.  You, being the dad,
opt-in globally to all warnings.  You will get a warning of the Tsunami when
the Canary Island's volcano slides, even if your daughter did not opt-in. 
Why would you make a mandatory tie of your choices about what warnings to get
to the ones your daughter made?   [Why is this choice being put into the charter,
in other words?]

As for you not worrying about the system tracking your daughter, I'm
glad to hear it, but I don't think we can ignore the problem in the charter. 
If you tie the warnings to an individual, you have to transition
the warnings as the individual moves around, which gives you a way of
tracking the individual.  If you suddenly see Kansas Tornado watches,
when you are expecting your daughter to be Ohio, you are getting information
the daughter may not have wanted you to have.

>"Send me alerts from this place" isn't really right, but it might be another
>useful thing to have. 

I think it is the right choice, honestly.  If your daughter wants to share her
location with you, she can do that with standard presence mechanisms.  You
can subscribe and eliminate alert requests based on that without forcing the
back-end systems to track the individual and what alerts are being received.

			regards,
				Ted

>From: Ted Hardie [mailto:[email-masked]]
>Sent: Monday, May 04, 2009 1:59 PM
>To: Brian Rosen; 'Henning Schulzrinne'; 'ken carlberg'
>Subject: charter text

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 4 May 2009 14:50:55 -0500

If the following isn't helpful, please ignore, but ...

> language, and I'd rather have narrow scope.

I am sympathetic to the notion of solving a limited problem set, but I'm 
having a difficult time trying to understand the security model here - when 
you get off a plane, and you don't have the local notifier's public key, and 
you get an alert, how do you know you can believe it?

I may be misunderstanding, but part of this discussion sounds like we might 
rely on the fact that all notifiers are governments as a way of ensuring 
that you can trust the alerts you get, and I'm not sure what your mobile 
device is supposed to do when you turn it on - when you get an alert, how do 
you know it comes from a government?

You guys may have all this well in hand, and Spencer just needs to catch up, 
but I'm concerned that we're talking about deferring security considerations 
in order to have a smaller scope for the work, and that might not be the 
right tradeoff to make...

Thanks,

Spencer

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 04 May 2009 14:25:03 -0500

At 08:24 PM 5/3/2009, Thomson, Martin wrote:
>I worry that this discussion has lost focus.  Are we talking about 
>terms for use in relation to a protocol, or terms in relation to 
>problem statement and naming (marketing)?  They can be separated.
>

Martin (and Hannes) - my concern about these two terms is they 
normally do not appear together.

Say, down the road, when we have "author" realized, do we classify an 
"authorized author". Many will find that not rolling off the tongue well.

"Recipient" is fine with me, but it is more often partnered with 
"sender" or "originator".

Meaning, down the road, we can have "authorized senders" or 
"authorized originators".

these word pairs appear to me to be more clear.

At the end of the day, having a terminology section to the beginning 
requirements doc (or just a terminology doc) should suffice wrt any 
confusion, I should think.

James

>Is this really the venue for deciding who applies this protocol 
>solution?  Not that I'm suggesting we design in a vacuum, but we 
>each have a fair idea of what the goals are; and I truly don't think 
>that there are major differences of opinion.  The subjective 
>definition of "authority" need not be a barrier to progress.
>
>I'm happy with marketing with vague terms like 
>"authority-to-citizen" or "early warning" and having separate terms 
>in protocol land.  That's been successful in the past; the 
>abstraction allows for a little flexibility in interpretation.  That 
>flexibility is sometimes useful.
>
>non-technical stuff.  Maybe abstraction offers us a way to make 
>process on the technical side while we "slosh around" on the fuzzy issues.
>
>--Martin
>
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 4 May 2009 16:00:15 -0400

We haven't figured any of this out.  Henning proposed something that sounded
like preloaded keys.  I don't think that works.  I think you need some kind
of discovery process.  Just saying "government" doesn't really solve any of
this, buy it MIGHT simplify things.

Brian

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 3:51 PM
To: Brian Rosen; 'Henning Schulzrinne'; 'ken carlberg'
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global
CAPcommunity

Thanks,

Spencer

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 4 May 2009 14:56:26 -0400

Brian

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 1:59 PM
To: Brian Rosen; 'Henning Schulzrinne'; 'ken carlberg'
Cc: [email-masked]
Subject: charter text

<snip>

		regards,
			Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 4 May 2009 17:35:55 -0400

On May 4, 2009, at 4:00 PM, Brian Rosen wrote:

> like preloaded keys.  I don't think that works.

I was talking about a specific scenario, namely where the notifier  
knows the destination. Students in a university and employees in a  
company are examples - they already routinely download keying material  
for various other reasons, such as browsing internal web pages. You  
don't even need to preload keying material. This isn't that much  
harder than signing S/MIME email, after all, as long as I have a pre- 
configured entry that says "messages signed by [email-masked] are  
genuine". It's not that hard for the signer to get a personal public/ 
private key pair from an existing CA.

This would not work for the "stepping off a plane" case, although a  
very similar mechanism might: get the legitimate alerter(s) via LoST.  
As long as the CA is known, i.e., is one of the ones built into the  
device, this is then again like S/MIME, except easier, since the  
number of parties that need to get public/private keypairs is probably  
a few thousand, not hundreds of millions. No new infrastructure is  
needed, either.

We shouldn't make this harder than it is.

Henning

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 4 May 2009 17:51:11 -0500

I don't care if we call them "cathode" and "anode" as long as we don't spend time on names when we could be designing solutions.

> From: James M. Polk [mailto:[email-masked]]
> Sent: Tuesday, 5 May 2009 5:25 AM
> To: Thomson, Martin; [email-masked]; Art Botterell

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 9 May 2009 12:25:48 +0300

Hi James, 

I took the terminology from the email architecture. 
I don't think we need to always add authorized in front of it as this would
hopefully be the secure communication is the normal case.

Ciao
Hannes

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of James M. Polk
>Sent: 04 May, 2009 22:25
>Subject: Re: [earlywarning] Deprecate "Authority" - was : 
>global CAPcommunity
>
>Say, down the road, when we have "author" realized, do we 
>classify an "authorized author". Many will find that not 
>rolling off the tongue well.
>
>"Recipient" is fine with me, but it is more often partnered 
>with "sender" or "originator".
>
>At the end of the day, having a terminology section to the 
>beginning requirements doc (or just a terminology doc) should 
>suffice wrt any confusion, I should think.
>
>James
>
>
>>solution?  Not that I'm suggesting we design in a vacuum, but we each 
>>have a fair idea of what the goals are; and I truly don't think that 
>>there are major differences of opinion.  The subjective definition of 
>>"authority" need not be a barrier to progress.
>>
>>I'm happy with marketing with vague terms like "authority-to-citizen" 
>>or "early warning" and having separate terms in protocol 
>land.  That's 
>>been successful in the past; the abstraction allows for a little 
>>flexibility in interpretation.  That flexibility is sometimes useful.
>>
>>non-technical stuff.  Maybe abstraction offers us a way to 
>make process 
>>on the technical side while we "slosh around" on the fuzzy issues.
>>
>>--Martin
>>
>>
>>--------------------------------------------------------------
>---------
>>------------------------- This message is for the designated 
>recipient 
>>only and may contain privileged, proprietary, or otherwise private 
>>information.
>immediately 
>>and delete the original.  Any unauthorized use of this email is 
>>prohibited.
>>--------------------------------------------------------------
>---------
>>-------------------------
>>[mf2]

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 14 May 2009 19:06:41 +0200

Maybe we could address this a different way round.

In draft-norreys-ecrit-authority2individuals-requirements-02.txt we have various figures showing the entities involved. Between which entities do we see various security activities (authorisation, integrity protection, encryption) occurring. 

I rather get the impression that Brian is arguing for the closed federation figure and therefore no authorisation between "Warning Notification Provider" and "Warning Notification Aggregator".

regards

Keith

> [mailto:[email-masked]] On Behalf Of Henning 
> Schulzrinne
> Sent: Monday, May 04, 2009 3:43 PM
> To: Brian Rosen
> Why is authorization easier for government? A school, 
> university or company generally knows all of its students and 
> employees, and can thus easily, relatively speaking, provide 
> their public key to them ahead of time, so that an alert can 
> be trivially verified as to its authenticity. For that, it 
> doesn't matter whether the organization is run by a 
> government (say, the Port Authority of NY&NJ) or a private 
> entity (Columbia University). (I guess sending alerts to GM 
> and Citibank would still be ok...). I'm ignoring the problem 
> of university/ company visitors, as most existing alert 
> systems don't deal with them, and reasonably rely on the 
> "regulars" to tell them what's going on.
> 
> The case of alerting is much harder for entities who need to 
> reach everyone who happens to be in their territory, such as 
> a county. They have to distribute some cryptographic material 
> to everybody, including visitors, without knowing who they are.
> 
> membership, rather than whether the entity operating the 
> alert has a seal and calls it itself county or state government.
> 
> Henning
> 
> > Finally, a meaty subject; terminology really doesn't get us 
> very far.  
> > This is important; really narrowing scope.
> >
> > National Government with major warning - impending attack Regional 
> > Government with life threatening event - Tornado or flash 
> flood Local 
> > Government with life threatening event - hazmat spill Local 
> Government 
> > with important, but not threatening event - major traffic 
> tieup Local 
> > Government with useful event - public school closing State 
> Government 
> > College with life threatening event - school shooting 
> Private College 
> > with life threatening event - school shooting Private elementary 
> > school with useful event  - school closing Enterprise with life 
> > threatening event - hazmat spill Enterprise with useful event - 
> > building closing due to weather
> >
> > It's clear to me that all of these are very useful alerts.  The 
> > question becomes, which of these should be in scope for the first 
> > charter?
> >
> > It seems to me that the issue of authorization is the 
> biggie here, and 
> > if we started out limiting to government, even local government, it 
> > gets a lot easier. Once you allow a non-government entity to notify 
> > using the
> > mechanism, we make the authorization decision much more 
> difficult.   
> > I don't
> > see an in-between way to slice the above list other than 
> government/ 
> > non government unless you say that the government can 
> authorize other 
> > entities and you are relying on that authorization.
> >
> > I think the wishes of the networks that are transporting the alerts 
> > come into play; they would want a bright line on authorization.
> >
> > I suspect that once you have an authorized entity that can 
> create an 
> > alert, what it gets to use that authorization for is a less 
> > interesting (to the
> >> As with any IETF effort, limiting scope is useful to get 
> progress in 
> >> a reasonable time.  With this effort, we have tried to limit the 
> >> scope of "authority".  It would be okay with me if we did 
> limit it to 
> >> government initially, although eventually I suspect we will expand 
> >> it.
> >>
> >> I think we can reasonably explain that authority is initially 
> >> government (national, state/province/region/, and local).  We can 
> >> reasonably explain that citizen includes residents and visitors.
> >>
> >> [mailto:[email-masked]
> >> ]
> <[email-masked]>
> >>>> It seems like the current terms of reference are heavily loaded 
> >>>> with emotional and cultural baggage.  That's the problem 
> with the 
> >>>> word "authority"... it has several different senses and 
> ultimately 
> >>>> involves a subjective, or at least individual, interpretation of 
> >>>> who and what constitutes authority (Government? Church? Academe? 
> >>>> Culture?)
> >>>>
> >>>> "Warning" is likewise a fairly subtle notion when you 
> really start 
> >>>> to unpack it.  In my particular public warning system we 
> define it 
> >>>> information-sharing (is it a warning if folks are 
> already aware of 
> >>>> the subject matter?)
> >>>>
> >>>> particular observable characteristics we're concerned about 
> >>>> (latency, reliability, verifiability, etc.) we're hoping 
> to achieve 
> >>>> rather than sloshing around in non-technical semantics?
> >>>>
> >>>> I get the sense that at least some of us are primarily concerned 
> >>>> with the use of SIP, and although I have no personal 
> investment in 
> >>>> that particular approach, at least it sounds like the 
> frame for a 
> >>>> tractable technical problem.
> >>>>
> >>>> - Art