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

[Nat Sakimura <[e-mail]>]

Some more questions.

Q1. Length limitation on

   1. code_challenge only
   2. code_verifier only
   3. both

Q2. Length in

   1. Octents
   2. Number of characters

My preference for Q2 is 1. as number of characters would not dictate the
actual length. A character is variable in length.


2014-05-22 10:25 GMT+09:00 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
>>>
>>>
>>>
>>>
>>>  --
>>>    [image: Ping Identity logo] <https://www.pingidentity.com/>
>>> Brian Campbell
>>> Portfolio Architect
>>>   @ [e-mail]  [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
>>>   @ [e-mail]  [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
>>> [e-mail]
>>> 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
>>>   @ [e-mail]  [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
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> OAuth mailing [e-mail]://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
>
>


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