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 <[email protected]>
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 <[email protected]> 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 <[email protected]> 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 <[email protected]>:
>>
>>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 <[email protected]> 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 <[email protected]>:
>>>>
>>>>
>>>>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
>>>>><[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
>>>>>>>
>>>>>>>> Brian Campbell <[email protected]> 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
>>>>>>>>> [email protected]
>>>>>>>>> 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
>>>>>>>> [email protected] PGP key available
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>--
>>>>>>
>>>>>> Brian Campbell
>>>>>>Portfolio Architect
>>>>>>@ [email protected]
>>>>>> +1 720.317.2061
>>>>>>Connect with us…
>>>>>>
>>>>>
>>>>>
>>>>>--
>>>>>
>>>>> Brian Campbell
>>>>>Portfolio Architect
>>>>>@ [email protected]
>>>>> +1 720.317.2061
>>>>>Connect with us…
>>>>>
>>>>>_______________________________________________
>>>>>OAuth mailing list
>>>>>[email protected]
>>>>>https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>--
>>>>Nat Sakimura (=nat)
>>>>Chairman, OpenID Foundation
>>>>http://nat.sakimura.org/
>>>>@_nat_en
>>>
>>>
>>>--
>>>
>>> Brian Campbell
>>>Portfolio Architect
>>>@ [email protected]
>>> +1 720.317.2061
>>>Connect with us…
>>>
>>
>>
>>
>>--
>>Nat Sakimura (=nat)
>>Chairman, OpenID Foundation
>>http://nat.sakimura.org/
>>@_nat_en
>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
