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

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 <bcampbell@pingidentity.com>:

> 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 <sakimura@gmail.com> 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 <bcampbell@pingidentity.com>:
>>
>> 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 <
>>> bcampbell@pingidentity.com> 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 <ve7jtb@ve7jtb.com>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 <warlord@MIT.EDU> wrote:
>>>>>
>>>>> > Brian Campbell <bcampbell@pingidentity.com> 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
>>>>> >> OAuth@ietf.org
>>>>> >> 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
>>>>> >       warlord@MIT.EDU                        PGP key available
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>    [image: Ping Identity logo] <https://www.pingidentity.com/>
>>>> Brian Campbell
>>>> Portfolio Architect
>>>>   @ bcampbell@pingidentity.com  [image: phone] +1 720.317.2061  Connect
>>>> with us…  [image: twitter logo] <https://twitter.com/pingidentity> [image:
>>>> youtube logo] <https://www.youtube.com/user/PingIdentityTV> [image:
>>>> LinkedIn logo] <https://www.linkedin.com/company/21870> [image:
>>>> Facebook logo] <https://www.facebook.com/pingidentitypage> [image:
>>>> Google+ logo] <https://plus.google.com/u/0/114266977739397708540> [image:
>>>> slideshare logo] <http://www.slideshare.net/PingIdentity> [image:
>>>> flipboard logo] <http://flip.it/vjBF7> [image: rss feed icon]<https://www.pingidentity.com/blogs/>
>>>>    [image: Register for Cloud Identity Summit 2014 | Modern Identity
>>>> Revolution | 19–23 July, 2014 | Monterey, CA]<https://www.cloudidentitysummit.com/>
>>>>
>>>>
>>>
>>>
>>> --
>>>    [image: Ping Identity logo] <https://www.pingidentity.com/>
>>> Brian Campbell
>>> Portfolio Architect
>>>   @ bcampbell@pingidentity.com  [image: phone] +1 720.317.2061  Connect
>>> with us…  [image: twitter logo] <https://twitter.com/pingidentity> [image:
>>> youtube logo] <https://www.youtube.com/user/PingIdentityTV> [image:
>>> LinkedIn logo] <https://www.linkedin.com/company/21870> [image:
>>> Facebook logo] <https://www.facebook.com/pingidentitypage> [image:
>>> Google+ logo] <https://plus.google.com/u/0/114266977739397708540> [image:
>>> slideshare logo] <http://www.slideshare.net/PingIdentity> [image:
>>> flipboard logo] <http://flip.it/vjBF7> [image: rss feed icon]<https://www.pingidentity.com/blogs/>
>>>    [image: Register for Cloud Identity Summit 2014 | Modern Identity
>>> Revolution | 19–23 July, 2014 | Monterey, CA]<https://www.cloudidentitysummit.com/>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>
>
>
> --
>    [image: Ping Identity logo] <https://www.pingidentity.com/>
> Brian Campbell
> Portfolio Architect
>   @ bcampbell@pingidentity.com  [image: phone] +1 720.317.2061  Connect
> with us…  [image: twitter logo] <https://twitter.com/pingidentity> [image:
> youtube logo] <https://www.youtube.com/user/PingIdentityTV> [image:
> LinkedIn logo] <https://www.linkedin.com/company/21870> [image: Facebook
> logo] <https://www.facebook.com/pingidentitypage> [image: Google+ logo]<https://plus.google.com/u/0/114266977739397708540> [image:
> slideshare logo] <http://www.slideshare.net/PingIdentity> [image:
> flipboard logo] <http://flip.it/vjBF7> [image: rss feed icon]<https://www.pingidentity.com/blogs/>
>    [image: Register for Cloud Identity Summit 2014 | Modern Identity
> Revolution | 19–23 July, 2014 | Monterey, CA]<https://www.cloudidentitysummit.com/>
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en