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

Perhaps some enlightenment is in order.  It's not clear to me how you
dsig a Data uri in a Location header (or maybe you mean dsig the pidf-lo
and put both the pidf-lo and the signature in the Data URI) somehow?
Are there some examples of this kind of thing elsewhere?

If we are ignoring technical arguments (as opposed to use cases), it's
out of forgetfulness, and not willfulness.  What were you referring to?

Brian



-----Original Message-----
From: Henning Schulzrinne [mailto:[email protected]] 
Sent: Tuesday, July 18, 2006 8:59 AM
To: Rosen, Brian
Cc: [email protected]; [email protected]
Subject: Re: [Geopriv] Location-by-value in a SIP Location Header

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