> I am easily confused by this stuff, so bear with me.
In this discussion, I think we all are
>
> > One of the things we also agreed on (almost too readily it seems)
> > is that the latter is NOT going to be specified by geopriv.
> > We probably will offer guidelines on appropriate choices, but
> > because we agreed that transport was not on the table, precise
> > crypto is not on the table. I think this is a very helpful thing
> > if the entire group agrees.
>
> i suspect that one cares about whether the box is locked or not,
> and whether the checks in it are signed, irrespective whether the
> box is carried by car or by plane.
If the protocol the object is used with provides "adequate"
crypto, then the object should not provide any additional crypto.
The most significant issue here I think is authentication --
if there is already an adequate authentication in place, then
requiring additional credentials is not acceptable. Similarly
if the protocol provides integrity and confidentiality for the
container the object is carried in, then we don't need any
more protection.
Of course, the difficulty could be to define "adequate".
> > may not include cryptographic authentication (and in fact
> > in some cases there would NOT be any form of cryptographic
> > authentication, for example, with emergency calls).
>
> i thought that the 911 call centers were quite interested in being
> able to know the phone number which called the service.
Yes, they are. However, one cannot define an authentication mechanism
that requires all emergency centers to implement any crypto
authentication which requires the center to have a trusted
relationship with an entity not controlled by the nation the
center is located in. For example, you can presuppose a global CA
that issues a cert to a center that allowed a phone to know
that it was talking to a bona fide center. It's probably
not possible to actually define any specific crypto at all -
nations tend to reserve that right to themselves.
>
> > There was great reluctance to get geopriv into the business of
> > devising new ways to express policy and in particular, we did
> > not see the WG designing a new policy expression language.
> > It was also observed that policy can be expressed by a user
> > interface as well as a formal policy language.
>
> i suspect that security folk may be of some help de-confusing
> policy mechanisms from policy description from policy decisions.
Maybe true, but only if they actually participate
>
> > It was observed that the output RFC of the work could have
> > a 1/2 page statement on policy that would be possible to
> > agree on, but it was REALLY hard to figure out how to
> > agree on a multipage document in less than infinite time.
>
> "i apologize for writing such a long letter, i did not have time to
> write a short one." i.e. a short description may require deeper
> understanding and more work on simplification than a long complex
> description. so i deeply admire this goal.
I'm not so sure. Sometimes the short version is not as defined
as some would like. We'll have to try it.
>
> > Henning observed that we should use "object oriented" language,
> > and thus talk about the person object inheriting location from
> > the cell phone object.
>
> from a decade of oo in my dark and dirty past: inheritance is data
> *and behavior*.
Yeah, but what does that have to do with the problem? If you define
a "target" as being the object that the location information
applies to, then a cell phone which has a GPS system is a target,
but we can also refer to the location of Randy Bush by defining
him as a target that inherits the location of his cell phone
in some circumstances, but inherits the location of some other
target in other circumstances.
>
> > The set of objects (cell/pager/PDA) problem was observed to be a
> > case of multiple inheritance but unlike in computer science, not
> > an inherently hard problem to solve :)
>
> in computer science, multiple inheritance is easy. there are fun
> problems in implementation.
Brian
Received on Wed Mar 20 10:05:12 2002
This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:22 EST