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

[Nat Sakimura <[e-mail]>]

+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