Skip to main content

Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
draft-ietf-oauth-proof-of-possession-11

Yes

(Kathleen Moriarty)

No Objection

(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Ben Campbell)
(Brian Haberman)
(Deborah Brungard)
(Joel Jaeggli)
(Martin Stiemerling)
(Spencer Dawkins)
(Terry Manderson)

Note: This ballot was opened for revision 08 and is now closed.

Kathleen Moriarty Former IESG member
Yes
Yes (for -08) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2015-12-15 for -09) Unknown
The Abstract and Introduction both say something like this:

   This specification defines how a JSON Web Token (JWT) [JWT] can
   declare that the presenter of the JWT possesses a key and that the
   recipient can cryptographically confirm that the presenter possesses
   that key.

The JWT doesn't declare that the presenter possesses the key; it declares that the presenter *must* possess the key... yes?  Shouldn't this say that?:

NEW
   This specification defines how a JSON Web Token (JWT) [JWT] can
   declare that the presenter of the JWT must possess a key and how
   the recipient can cryptographically confirm that the presenter
   possesses that key.
END

(Also notice change from "that" to "how".)

   This
   specification defines how to communicate key confirmation key
   information in JWTs.

"key confirmation key information" seems odd and hard to follow.  I think "key information used in key confirmation" is a better way to say it.  But perhaps the sentence as a whole could be better phrased.  Does something like this work?:

NEW
   This specification defines how to imbed into the JWT the key
   information that is used in key confirmation.
END

-- Section 2 --
Minor, very unimportant point: There's no reason to put, for example, "(JWT)", when the citation "[JWT]" immediately follows it.  I suggest just using the citation to provide the abbreviation, and eliminating "(JWT)", "(JWK)", and "(JWE)".  But very unimportant; do, or don't, and no need to respond to this item.

-- Section 3 --

   The issuer of a JWT declares that the presenter possesses a
   particular key and that the recipient can cryptographically confirm
   proof-of-possession of the key by the presenter by including a "cnf"
   (confirmation) claim in the JWT whose value is a JSON object.

I was convinced that this wasn't right until I read it for about the eighth time.  It sounds like the recipient includes the "cnf" claim in the JWT, when it's actually the issuer.  That happens when long sentences have too many qualifiers strung together.  How about this?:

NEW
   By including a "cnf" (confirmation) claim in a JWT, the issuer
   of the JWT declares that the presenter possesses a particular key,
   and that the recipient can cryptographically confirm that the
   presenter has proof-of-possession of that key.  The value in the
   cnf claim is a JSON object, and members in that object identify
   the proof-of-possession key.
END

-- Section 3.5 --

   The protocol used to acquire the resource MUST provide integrity
   protection; an HTTP GET request to retrieve the JWK Set MUST use
   Transport Layer Security (TLS) [RFC5246]; and the identity of the
   server MUST be validated, as per Section 6 of RFC 6125 [RFC6125].

Little editorial punctuational nonsense: I would make the first semicolon a colon instead (or perhaps a period), and I would then make the second semicolon a comma.

-- Section 4 --
In the last paragraph, can you provide a reference for "audience restriction"?

-- Section 6 --
Can we get this fixed in all the OAuth and JOSE documents?  It's getting old having to make the same comment for every document:  We should not be trying to set up IANA processes in our IANA Considerations.  The fourth and sixth paragraphs aren't appropriate here: IANA coordinates and tracks registration requests, and all requests should go to IANA.  IANA will contact the DEs, not the other way around.  The authors have seen this comment from me before....
Ben Campbell Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2015-12-17 for -10) Unknown
- Figure 1 and the discussion thereof: you talk all the time here
about "a symmetric key" so I think you ought add a footnote like
bit of text that says something like "note that there ought be
more than one key involved here, derived from the key exchanged
at (0) via a KDF." I kinda wish that all that had been covered in
one document but I guess that's part of the PoP arch doc, which
is for later.

- 3.1 says "outside the scope of this specification": just
wondering - does that phrase occur in all OAuth RFCs? (only
kidding, honest:-)

- section 4, para 2: replay can also be avoided if a sub-key is
derived from a shared secret that is specific to the instance of
the PoP demonstration.

- section 6: DE guidance - I think we ought tell the DEs that the
specification of a new thing needs to explicitly describe the
security properties of using the new thing.

- I didn't see a response to the secdir review [1] but that was
maybe sent to the wrong places. 

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06266.html
Terry Manderson Former IESG member
No Objection
No Objection (for -09) Unknown