Hi Nat,
as far as I understand, the length of at least 32 octets is justified for S256 only. So limiting the MUST to S256 would be ok (from my perspective). I consider a general MUST (which also applies to plain) a to strong requirement. kind regards, Torsten. Am 18.02.2015 10:50, schrieb Nat Sakimura: > Is there anyone who has problems changing it to a MUST? > On 2015年2月18日(水) at 18:48 Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote: > >> I think that the "controlled environment" is a risky idea. I believe we >> should definitely go for a MUST. >> >> On 02/18/2015 10:26 AM, Nat Sakimura wrote: >>> Hi Hannes, >>> >>> The reason I have put SHOULD there instead of MUST is >>> that there may be a valid reason not to in a controlled >>> environment, and it does not interfere the interoperability. >>> The deployment may opt to use other control than entropy, >>> and SHOULD allows it while MUST does not. >>> >>> Having said that, if the WG is OK with a MUST there, >>> I am fine with incorporating the proposed change. >>> >>> Cheers, >>> >>> Nat >>> >>> >>> On Wed, 18 Feb 2015 09:43:30 +0100 >>> Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote: >>> >>>> Hi Nat, >>>> >>>> thanks for the quick response. >>>> >>>> I was hoping to see a statement like "The code verifier MUST have >>>> enough entropy to make it impractical to guess the value." in the >>>> text rather than the SHOULD. Given all the other statements in the >>>> draft I am not sure what the should actually means. Under what >>>> conditions would an implementer not provide enough entropy to make >>>> guessing impractical? >>>> >>>> Ciao >>>> Hannes >>>> >>>> On 02/18/2015 05:13 AM, Nat Sakimura wrote: >>>>> Hi Hannes, >>>>> >>>>> I hereby confirm that I have submit the draft in full conformance >>>>> with the provisions of BCP 78 and BCP 79. >>>>> >>>>> Re: Security Consideration (7.1) and section 4.1 >>>>> >>>>> The first part of the 7.1 is a non-normative prose explaining that >>>>> the implementers got to make sure that the code verifier is hard to >>>>> guessed or modeled. In a way, this is laying out the basic security >>>>> property requirment on the code verifier. >>>>> >>>>> Then, it goes onto the implementation guideance that one need to >>>>> use a cryptographic random number generator instead of relying on a >>>>> rand() in some language that are not cryptographically random to >>>>> generate 32-octet sequence. The same text is in 4.1 as well. >>>>> >>>>> We did not copy "code verifier SHOULD have enough entropy to make >>>>> it impractical to guess the value" here because that looked >>>>> needlessly repeating, but if you want, I have no objection in >>>>> adding it to 7.1. >>>>> >>>>> Alternatively, in 7.1, after explaining the rationale, we can just >>>>> point to 4.1 for the control and implementation guidance. >>>>> >>>>> Re: 32-octet >>>>> >>>>> We chose it because we are using SHA256 in generating the code >>>>> challange. Having more entropy does not help us here, while having >>>>> less octets increases the risk. >>>>> >>>>> Best, >>>>> >>>>> Nat >>>>> >>>>> >>>>> >>>>> On Tue, 17 Feb 2015 17:56:33 +0100 >>>>> Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote: >>>>> >>>>>> Hi Nat, John, Naveen, >>>>>> >>>>>> thanks a lot for your work on the document. >>>>>> >>>>>> I still need responses to this mail to complete the shepherd >>>>>> writeup: >>>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html [1] >>>>>> >>>>>> I definitely need the IPR confirmation. >>>>>> >>>>>> It would also be helpful to have someone who implemented the >>>>>> specification as it currently is. I asked Brian and Thorsten for >>>>>> clarification regarding their statements that they implemented >>>>>> earlier versions of the spec. >>>>>> >>>>>> As a final remark I still believe that the text regarding the >>>>>> randomness is still a bit inconsistent. Here are two examples: >>>>>> >>>>>> 1) In the Security Consideration you write that "The security model >>>>>> relies on the fact that the code verifier is not learned or >>>>>> guessed by the attacker. It is vitally important to adhere to >>>>>> this principle. " >>>>>> >>>>>> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD >>>>>> have enough entropy to make it impractical to guess the value. It >>>>>> is RECOMMENDED that the output of a suitable random number >>>>>> generator be used to create a 32-octet sequence." >>>>>> >>>>>> There is clearly a long way from a SHOULD have enough entropy to >>>>>> the text in the security consideration section where you ask for >>>>>> 32 bytes entropy. >>>>>> >>>>>> It is also not clear why you ask for 32 bytes of entropy in >>>>>> particular. >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth [2] > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth [2] Links: ------ [1] http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html [2] https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
