Re: Re: [Geopriv] Location-by-value in a SIP Location Header

Hannes Tschofenig <[email protected]>
Newsgroups gmane.ietf.sip,gmane.ietf.geopriv
Message-ID <[email protected]>
I have to agree with Henning here.

You can sign the PIDF-LO, encode it and then put it into the data URI.

Even if you do not sign the PIDF-LO in the header it makes no difference 
since that's what you accomplish by sending a location reference (in the 
header) as well.

The argument that you can use authorization policies to decide who is 
allowed to resolve the reference to the location object is a bit 
misleading. Where do these policies come from?

Ciao
Hannes

Henning Schulzrinne wrote:
> Brian, James:
> 
> this is simply false. If desired, XML-DSIG is a well-known and  accepted 
> mechanism to achieve integrity. Such specification is no  longer than 
> the MUST NOT that you propose. You are also willfully  ignoring the 
> other technical arguments made as part of this discussion.
> 
> Henning
> 
> On Jul 18, 2006, at 8:48 AM, Rosen, Brian wrote:
> 
>> There was a desire expressed by Hannes to provide a way for a proxy to
>> insert location-by-value.  He had proposed a SIP Location header
>> specific way.  In IETF66, Henning suggested just using a data URI.
>>
>> Doing this may run afoul of the geopriv location privacy concerns,
>> because there is no way for the user to sign the header to provide
>> assurance that the PIDF, and specifically the retention and other  policy
>> bits are preserved.  Note that S/MIME provides sufficient integrity
>> protection for a body.  It's probably okay to use TLS per hop to  provide
>> privacy, but not integrity protection.  The authors believe that there
>> is no really compelling use case for this feature, and the effort to
>> define acceptable security mechanisms for location data in a header
>> would be a significant effort, further delaying the draft.
>>
>> We propose, therefore, to state in sip-location-conveyance, that a  Data
>> URI MUST NOT be used in the Location header until a standards track  RFC
>> defines a suitable security mechanism to protect the PIDF in the  header.
>>
>> Brian and James
>>
>> _______________________________________________
>> Geopriv mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/geopriv
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email protected] for questions on current sip
> Use [email protected] for new developments on the application of sip
> 
> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.