Subject: Re: [Geopriv] Gen-art last call review : draft-ietf-geopriv-deref-protocol-03

From: Robert Sparks <[email-masked]>
Date: Wed, 2 Nov 2011 16:15:01 -0500

(Including the geopriv list on this reply).

Martin - there's one change you made that I think you need to adjust.
In response to Elwyn's suggestion about Appendix A, Req 9 below, you've
added some 2119 text to that appendix which isn't right. Is there a place you
can say what you want to say in the body of the document?

RjS

On Oct 30, 2011, at 8:33 PM, Thomson, Martin wrote:

> Hi Elwyn,
> 
> Thanks for going through this in detail.
> 
> I see that you've found a few holes in the appendix.  I've attempted to correct those.  More detail on that below.
> 
> I've posted -04 with the changes.
> 	<http://tools.ietf.org/html/draft-ietf-geopriv-deref-protocol-04>
> 
> On 2011-10-24 at 01:11:50, Elwyn Davies wrote:
>> Appendix A: Compliance statement for Req 4:  The Compliance statement 
>> states that use of HTTPS from Location Recipient to LS is mandated.  I 
>> cannot find any MUST statement to this effect in the main body of the 
>> document.  
> [...]
>> Appendix A: Compliance statement for Req 4:  Use of the HTTP over TLS 
>> PKI infrastructure, would I suppose be implicit if the previous 
>> comment were fixed.  However, it might be good to make this explicit.
> 
> The MUST doesn't exist.  There was discussion about mandatory TLS that ended with the text in the body, but the appendix was missed in the edit.  The conclusion was that we wouldn't prevent use of http:, but the risks needed to made clear.  I hope that this was achieved.
> 
> I've added a little note that should make this clearer:
>   Though discouraged, using unsecured http: URIs is permitted.
>   Using unsecured HTTP is likely to result in non-compliance
>   with this requirement.
> 
>> Appendix A: Compliance statement for Req 9:  Again, the body of the 
>> specification is silent on what a Location Reciepient may or may not 
>> do with a Location URL.  Clearly any constraints are not enforceable 
>> within the context of the HELD protocol but it is probably desirable 
>> to note the policy of non-propagation implied by Req 9.
> 
> That's a good idea.
> 
>> Appendix B: Compliance statement for Req C3: Compliance for Auth by 
>> Possession seems somewhat dubious.  Derogation due to the requirement 
>> for expiry is discussed in the body of the document.
> 
> The idea that there are two distinct models for authorization is a little bit misleading.  A URI that is authorized by possession can still be cancelled using the mechanism described in the policy-uri draft.
> 
> An implementation that doesn't support cancellation is not going to be compliant, but that's not a fault in the specification.
> 
>> Appendix B: Compliance statement for Req C8: The explicit requirement 
>> for a minimum of 128 bits of randomness does not appear in the body of 
>> the document.  Since the requirements doc is informational, this needs 
>> to be made explicit in the main body of the doc.
> 
> ADDED:
> The amount of randomness is not specifically identified since it depends on a number of factors that change over time, such as the number of valid location URIs, the validity period of those URIs and the rate that guesses can be made.
> 
>> Appendix C: Compliance statement for Req D5:  See comments above on 
>> App A, Req 4.  May be a contradiction here: App A appears to require a 
>> MUST; this compliance implies a RECOMMENDS and possibility of http.
>> Needs sorting out.
> 
> Sorted out as described above.
> 
>> Abstract: Acronym HELD needs to be expanded here (currently expanded 
>> in s1).
> 
> Fixed.
> 
>> s1, Figure 1: (PIcky nit): The infomation carried by the two 
>> xxxRequest messages is technically a request for xxx rather than the 
>> actual object.
> 
> Good point; added "for " to each parenthetical.
> 
>> s3.2, para 2: s/before before/before/
>> 
>> s5, Figure 5: (Picky nit): The indentation is slightly inconsistent 
>> <geopriv> element  only indented one space.
> 
> You are too observant.  Unfortunately, indenting more causes the longer lines to be too wide.
> 
>> Appendix A, Req 12 bullet (b): s/about the identity about the 
>> Target/about the identity of the  Target/
> 
> Done.
> 
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 3 Nov 2011 06:18:10 +0800

On 2011-11-03 at 08:15:01, Robert Sparks wrote:
> In response to Elwyn's suggestion about Appendix A, Req 9 below, 
> you've added some 2119 text to that appendix which isn't right. Is 
> there a place you can say what you want to say in the body of the document?

Yeah, and that was stupid of me.

The security considerations already contains a statement to this effect:

   Location URIs MUST only be disclosed to authorized Location
   Recipients.  

As for the 2119 language, a reference to the above statement should do:

OLD:
   In order to comply with these rules, a Location Recipient	
   MUST NOT redistribute a location URI without express	
   permission. Depending on the access control model, the	
   location URI might be secret (see Section 3.3 of	
   [RFC5808]).
NEW:
   For location URIs that are use possession as a component of
   authorization, the protecting the secrecy of the URI is
   necessary in order to comply with this requirement (see
   Section 6).

--Martin

---

From: Robert Sparks <[email-masked]>
Date: Thu, 3 Nov 2011 15:54:28 -0500

I'll add that as an RFC editor note and more this into IESG evaluation.

Thanks!

RjS