Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03

[John Bradley <[e-mail]>]

I think the current one is probably a OK compromise. 

Sent from my iPhone

> On May 21, 2014, at 9:11 PM, Nat Sakimura <[e-mail]> wrote:
> 
> Good! I achieve the purpose :-)
> 
> So what would be the appropriate length? 
> The current one would do? 
> 
> 
> 2014-05-20 22:56 GMT+09:00 Anil Saldhana <[e-mail]>:
>> Brian - I agree with you.  It should be MUST as long as the hard limit is generous for usage.
>> 
>> 
>> 
>> 
>>> On 05/20/2014 07:09 AM, Brian Campbell wrote:
>>> I'd say it should be a MUST so that implementations are consistent about it.
>>> 
>>> 
>>>> On Fri, May 16, 2014 at 3:27 PM, Bill Mills <[e-mail]> wrote:
>>>> The HTTP specs don't limit these things, but implementations do, and the problems when you run into them are a rea pain.
>>>> 
>>>> DO we want to make this a hard limit, or should it be guidance in the form of RECOMMENDED or SHOULD?
>>>> 
>>>> On Friday, May 16, 2014 9:35 AM, Brian Campbell <[e-mail]> wrote:
>>>> Yeah, I agree with John here. There are a few good reasons to restrict the length of the code_challenge. One is trying to keep the authorization request URI to                                   reasonable size as it will eventually run into various limits on clients and/or servers. The other is constraining the amount of data that an AS needs to store per code.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Fri, May 16, 2014 at 7:41 AM, John Bradley <[e-mail]> wrote:
>>>> From the AS side you probably want to know what the max size you need to store per code.
>>>> 
>>>> On the call to the token endpoint it is a POST so size should not be an issue.  
>>>> 
>>>> 
>>>>> On May 16, 2014, at 3:10 PM, Nat Sakimura <[e-mail]> wrote:
>>>>> 
>>>>> Now that I cannot remember what limit we were hitting, it might be a good idea to remove the constraint and see if anyone protests. 
>>>>> 
>>>>> What do you think? 
>>>>> 
>>>>> Nat
>>>>> 
>>>>> 
>>>>> 2014-05-14 20:46 GMT+09:00 Brian Campbell <[e-mail]>:
>>>>> That too would suggest that the length limit be on code_challenge because that's the parameter that will be on URIs getting passed around. The code_verifier is sent directly in the POST body from client to AS. 
>>>>> 
>>>>> 
>>>>> On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura <[e-mail]> wrote:
>>>>> +1 for octet. We used to have "bytes" in JW* so I used "bytes" here, while at the same time complaining in Jose that it should be "octet". JW* changed to "octet" but I failed to sync with it in the last few edits. 
>>>>> 
>>>>> I do not quite remember which platform, but the reason for the limit was that some platform had some limitations as to the length of the sting to be passed to it through URI and we did not want the challenges to be truncated by that limit. 
>>>>> 
>>>>> Best, 
>>>>> 
>>>>> Nat
>>>>> 
>>>>> 
>>>>> 2014-05-13 6:56 GMT+09:00 Brian Campbell <[e-mail]>:
>>>>> 
>>>>> And it'd give the AS some direct guidance on                                                           protecting itself from crazy long code_challenge values rather than relying on the client not to do something creative. 
>>>>> 
>>>>> 
>>>>> On Mon, May 12, 2014 at 3:54 PM, Brian Campbell <[e-mail]> wrote:
>>>>> Right but that's why I'm asking why not just put the limit on code_challange rather than inferring it from code_verifyer + challenge algorithm, which probably bounds it but doesn't necessarily do so? It's not a big deal but would read more clearly, I think.
>>>>> 
>>>>> 
>>>>> On Mon, May 12, 2014 at 3:48 PM, John Bradley <[e-mail]> wrote:
>>>>> I think octets is more consistent with other JW* and OAuth specs.
>>>>> 
>>>>> The code_challange is the same length as the code_verifyer or is a hash of the code_verifyer so likely smaller than 128octets (43 ish for base64 256 bit)
>>>>> 
>>>>> Limiting the code_verifyer size sets the upper bound for code_challange, unless someone comes up with a really creative code challenge algorithm.
>>>>> 
>>>>> I will talk to nat about changing it to octets when I see him tomorrow.
>>>>> 
>>>>> John B.
>>>>> 
>>>>> On May 12, 2014, at 11:15 PM, Derek Atkins <[e-mail]> wrote:
>>>>> 
>>>>> > Brian Campbell <[e-mail]> writes:
>>>>> >
>>>>> >> I notice that code_verifier is defined as "high entropy cryptographic random
>>>>> >> string of length less than 128 bytes"  [1], which brought a few questions and
>>>>> >> comments to mind. So here goes:
>>>>> >>
>>>>> >> Talking about the length of a string in terms of bytes is always potentially
>>>>> >> confusing. Maybe characters would be an easier unit for people like me to wrap
>>>>> >> their little brains around?
>>>>> >
>>>>> > It depends if it really is characters or bytes.  For example there are
>>>>> > many multi-byte UTF-8 characters, so if it really is bytes then saying
>>>>> > characters is wrong because it could overflow.  So let's make sure we
>>>>> > know what we're talking about.  Historically, if we're talking bytes the
>>>>> > IETF often uses the phrase "octets".  Would that be less confusing?
>>>>> >
>>>>> >> Why are we putting a length restriction on the code_verifier anyway? It seems
>>>>> >> like it'd be more appropriate to restrict the length of the code_challenge
>>>>> >> because that's the thing the AS will have to maintain somehow (store in a DB
>>>>> >> or memory or encrypt into the code). Am I missing something here?
>>>>> >>
>>>>> >> Let me also say that I hadn't looked at this document since its early days in
>>>>> >> draft -00 or -01 last summer but I like the changes and how it's been kept
>>>>> >> pretty simple for the common use-case while still allowing for crypto agility/
>>>>> >> extension. Nice work!
>>>>> >>
>>>>> >> [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3
>>>>> >
>>>>> > -derek
>>>>> >
>>>>> >> _______________________________________________
>>>>> >> OAuth mailing list
>>>>> >> [e-mail]
>>>>> >> https://www.ietf.org/mailman/listinfo/oauth
>>>>> >
>>>>> > --
>>>>> >       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>>>>> >       Member, MIT Student Information Processing Board  (SIPB)
>>>>> >       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>>>>> >       [e-mail]                        PGP key available
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> 	
>>>>> Brian Campbell
>>>>> Portfolio Architect
>>>>> @	[e-mail]
>>>>> 	+1 720.317.2061
>>>>> Connect with us…
>>>>>        
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> 	
>>>>> Brian Campbell
>>>>> Portfolio Architect
>>>>> @	[e-mail]
>>>>> 	+1 720.317.2061
>>>>> Connect with us…
>>>>>        
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Nat Sakimura (=nat)
>>>>> Chairman, OpenID Foundation
>>>>> http://nat.sakimura.org/
>>>>> @_nat_en
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> 	
>>>>> Brian Campbell
>>>>> Portfolio Architect
>>>>> @	[e-mail]
>>>>> 	+1 720.317.2061
>>>>> Connect with us…
>>>>>        
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Nat Sakimura (=nat)
>>>>> Chairman, OpenID Foundation
>>>>> http://nat.sakimura.org/
>>>>> @_nat_en
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth