RE: Does GEOPRIV specify crypto was RE: Notes from Non-meeting

> The APPS ADs expect the geopriv location object will have the
> form of an embedded protocol.
Why?

If the protocol the object is used in provides acceptable security,
why would it need to be anything other than a simple object?

I think this is an unecessary restriction
  
>
> Let's keep object security and transport security well separated -
> it's unclear from Brian's mail if the object security (SIP's use
> of S/MIME) is what is meant.
Yes, although it's not practical to use it in the emergency call
scenario
 
>
> I don't think we know now whether the geopriv object will be one
> that has a preexisting approach to its object security and if so
> what specification might be needed for the specific geopriv functions.
> Its coordination with its transporting protocol's (e.g. sip, mail,
> whatever) object security would then have to be considered.
Then let's open up the subject and decide now. It's a pretty
fundamental issue, and I don't think we need to wait.

I propose that the geopriv object allow the use of the transport's
crypto if appropriate. The appropriateness is a function of the use
case.

>
> And then there is the separate point of specifying a minimum
> mandatory to implement (not use) object security. The IESG will
> require us to have minimum mandatory to implement features of
> security for geopriv, including what the crypto would be.
If the object is defined such that the transport crypto is
acceptable, then the minimum to implement crypto for the
transport is what is required. If the transport does not
have an appropriate crypto minimum, then the object might
have one of its own.

>
> Finally, I underline Randy's point about the match of trust models
> with those enforced by the transporting protocol needing careful
> consideration.
Of course. I just think that in the SIP case, the models match.

Brian
Received on Wed Mar 20 12:38:59 2002