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

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