Subject: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Mon, 06 Jul 2015 19:49:02 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-oauth-spop-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Version -14 resolves my DISCUSS (and also some of my non-blocking
comments).  Thanks very much for considering these and working with me on
them!

  =========================================
My comment about the IANA Considerations remains.  While it's
non-blocking, I still hope you will accept the change I suggest:

-- Section 6.2 --
I have the same comment here as in the other OAuth document: please shift
the focus away from telling IANA how to handle tracking of the expert
review, and make the mailing list something that the designated expert(s)
keep track of.  Also, please give more instructions to the DEs about what
they should consider when they're evaluating a request (for example,
should they approve all requests, or are there criteria they should
apply?).

For the first, here's a text change that I suggest we move toward for
this sort of thing:

OLD
<most of Section 6.2>

NEW
   Additional code_challenge_method types for use with the authorization
   endpoint are registered using the Specification Required policy
   [RFC5226], which includes review of the request by one or more
   Designated Experts.  The DEs will ensure there is at least a two-week
   review of the request on the [email-masked] mailing list,
   and that any discussion on that list converges before they respond to
   the request.  To allow for the allocation of values prior to
   publication, the Designated Expert(s) may approve registration once
   they are satisfied that an acceptable specification will be
published.

   Discussion on the [email-masked] mailing list should use
   an appropriate subject, such as "Request for PKCE
   code_challenge_method: example").

   The Designated Expert(s) should consider the discussion on the
   mailing list, as well as <<these other things>> when evaluating
   registration requests.  Denials should include an explanation
   and, if applicable, suggestions as to how to make the request
   successful.
END

  =========================================
-- Section 7.2 --
I find the first first paragraph confusingly worded, and after discussion
with the author I suggest this:

NEW
Clients MUST NOT downgrade to "plain" after trying the S256 method.
Because servers are required to support S256, an error when S256 is
presented can only mean that the server does not support PKCE at all.
Otherwise, such an error could be indicative of a MITM attacker trying
a downgrade attack.
END

  =========================================
Finally, there is this comment, which is not a big deal and you should
proceed as you think best:

-- Section 2 --
There is no real distinction between STRING and ASCII(STRING), because
STRING is already defined to be ASCII.  Using "ASCII(xxx)" only adds
clutter, and a suggest removing it.

So, for example, that would result in changes such as this:

OLD
BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) == code_challenge
NEW
BASE64URL-ENCODE(SHA256(code_verifier)) == code_challenge
END

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 8 Jul 2015 01:09:58 +0900

Thanks Barry,

These are the issues that I wanted to discuss with John before making
change.

-- Section 6.2 -- John has partly addressed your IANA comment already. I
needed
to check if there was any reason for just doing partly.

-- Section 7.2 -- is probably just my oversight. I will deal with it.

-- Section 2 -- : I agree with you and I wanted to confirm it with John and
other people to commit the change.

Cheers,

Nat

2015-07-07 11:49 GMT+09:00 Barry Leiba <[email-masked]>:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

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

---

From: Brian Campbell <[email-masked]>
Date: Tue, 7 Jul 2015 10:35:18 -0600

Regarding the comment on Section 2, I had originally argued for the
inclusion of ASCII(xxx) as I felt it was important to avoid potential
ambiguity that was in the draft at the time (it wasn't 100% clear to me at
the time if the code_verifier was to be base64url decoded as input into the
hash or if the ASCII bytes were to be used). However, other content
(particularly §4.1
<https://tools.ietf.org/html/draft-ietf-oauth-spop-14#section-4.1>) has
since changed and removed the potential for the ambiguity I thought might
be there.

Which is a long way of explaining that I'm okay with Barry's proposed
change to Section 2, and occurrences of ASCII(...) throughout, despite it
undoing something I'd previously requested.

On Tue, Jul 7, 2015 at 10:09 AM, Nat Sakimura <[email-masked]> wrote:

> -- Section 2 -- : I agree with you and I wanted to confirm it with John
> and other people to commit the change.
>
> Cheers,
>
> Nat
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 7 Jul 2015 16:40:50 -0400

Thanks for your responses on these comments.

I can approve an updated draft to make this change and the one for IANA if
that is the easiest path.  The other option is to write this all up in an
RFC editor note and I can send that with the approval.  Making the direct
updates may be simpler to avoid mistakes.

Can you submit a new version?

Thank you,
Kathleen

On Tue, Jul 7, 2015 at 12:35 PM, Brian Campbell <[email-masked]>
wrote:

>>> Please refer to
>>> https://www.ietf.org/iesg/statement/discuss-criteria.html

-- 

Best regards,
Kathleen

---

From: John Bradley <[email-masked]>
Date: Tue, 7 Jul 2015 19:53:00 -0300

I have a draft with Barry’s edits less the removal of ASCII(string) ready to go.

In JWS we used ASCII(string) to indicate that the output is a sequence of octets, strings are not necessarily 8 characters bits and may have null termination etc.

However as Brian states other changes may have removed the need for that.

I admit saying "where STRING is a sequence of zero or more ASCII characters.” looks a bit circular.   How about saying "where STRING is a sequence of zero or more characters”

The ABNF in Sec 4.1 should keep people from going too wrong on its own.

I think it is OK the way it is, but am willing to change it if people feel strongly.

Let me know if I should make that change or publish a draft without it, addressing the other comments.

John B.

> On Jul 7, 2015, at 5:40 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> I can approve an updated draft to make this change and the one for IANA if that is the easiest path.  The other option is to write this all up in an RFC editor note and I can send that with the approval.  Making the direct updates may be simpler to avoid mistakes.
> 
> On Tue, Jul 7, 2015 at 12:35 PM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
> Regarding the comment on Section 2, I had originally argued for the inclusion of ASCII(xxx) as I felt it was important to avoid potential ambiguity that was in the draft at the time (it wasn't 100% clear to me at the time if the code_verifier was to be base64url decoded as input into the hash or if the ASCII bytes were to be used). However, other content (particularly §4.1 <https://tools.ietf.org/html/draft-ietf-oauth-spop-14#section-4.1>) has since changed and removed the potential for the ambiguity I thought might be there. 
> 
> Which is a long way of explaining that I'm okay with Barry's proposed change to Section 2, and occurrences of ASCII(...) throughout, despite it undoing something I'd previously requested.  
> 
> On Tue, Jul 7, 2015 at 10:09 AM, Nat Sakimura <[email-masked] <mailto:[email-masked]>> wrote:
> Thanks Barry, 
> 
> 
> These are the issues that I wanted to discuss with John before making change. 
> 
> -- Section 6.2 -- John has partly addressed your IANA comment already. I needed 
> -- Section 2 -- : I agree with you and I wanted to confirm it with John and other people to commit the change. 
> 
> Cheers, 
> 
> Nat
> 
> 2015-07-07 11:49 GMT+09:00 Barry Leiba <[email-masked] <mailto:[email-masked]>>:
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/>
> 
> 
> 
>    review of the request on the [email-masked] <mailto:[email-masked]> mailing list,
>    Discussion on the [email-masked] <mailto:[email-masked]> mailing list should use
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> http://nat.sakimura.org/ <http://nat.sakimura.org/>
> @_nat_en
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen

---

From: Barry Leiba <[email-masked]>
Date: Tue, 7 Jul 2015 18:58:41 -0400

> In JWS we used ASCII(string) to indicate that the output is a sequence of
> octets, strings are not necessarily 8 characters bits and may have null
> termination etc.
>
> I admit saying "where STRING is a sequence of zero or more ASCII
> characters.” looks a bit circular.   How about saying "where STRING is a
> sequence of zero or more characters”
>

As I've said, that one is the least important of all my comments, and
you folks should do what you think best there.  If you prefer to leave
the "ASCII(x)" notation for consistency, clarity, or whatever else,
I'm not going to say any more about it.

And many thanks for dealing with the other changes I've suggested.

Barry