JSON Web Key (JWK)
RFC 7517

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

(Richard Barnes) (was Discuss) Yes

Comment (2014-10-01 for -36)
No email
send info
Section 1.1.
The pointer for BASE64URL should be to JWS.  One level of indirection, please :)

Section 4.
It might be worth being explicit (here or elsewhere):
"A JWK MUST NOT contain algorithm-specific members for key type other the one specified in its "kty" attribute."

Section 4.1.
"cryptographic algorithm family used with the key"
"... such as "RSA" or "EC"."

Section 4.7.
"base64 encoded ([RFC4648] Section 4 -- not base64url encoded) DER"
It seems unpleasant for implementations to have to support two flavors of base64, especially since this doesn't use PEM directly.  Did the WG discuss just using BASE64URL?

Section 9.1.
It might help here to note that technologies like PKIX and JWT can allow relying parties to verify the provenance of a key and binding of attributes to it.

(Kathleen Moriarty) Yes

(Jari Arkko) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2014-10-21 for -35)
No email
send info
Cleared kid case-sensitivity point about inclusion of DNS names
based on text added to signature doc. Thanks for that.

As a comment I do think a reference from here to there or 
re-stating the point here would be good. But its ok if you prefer
not.

I didn't check the comments below.

--- 

4.8: I'd prefer if sha-256 had been the default/shorter of
these. But whatever.

4.8/4.9: the disconnect with DANE and other specs that use
HASH(SPKI) as a thumbprint is a pity (but can be fixed
later). How'd that happen? 

8: "make sense" still isn't useful;-) I've noted that on the
algs draft though so won't repeat more.

C.9: Huh? Needs a ref to compact rep which isn't defined
here.

As with other JOSE drafts, there was a substantial thread on
the secdir review that I didn't have time to follow but I'm
ok that Kathleen's been on top of that.

(Brian Haberman) (was No Record, No Objection) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

Comment (2014-10-02 for -33)
No email
send info
I'm not sure whether I need to complain about this, but the following seems underspecified:

   UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation
   of STRING.

   ASCII(STRING) denotes the octets of the ASCII [USASCII]
   representation of STRING.

The issue is that we don't know what STRING is.   Is it 32-bit unicode?   Is it ASCII?   What does it mean to have ASCII(unicode string)?   Is ASCII(STRING) an assertion that STRING is representable as ASCII?

(Martin Stiemerling) No Objection

(Pete Resnick) Abstain

Comment (2014-12-02 for -37)
No email
send info
I've got some suggestions for improvements below, but overall I cannot support this document, so I'm entering an ABSTAIN. I don't think this WG has actually fulfilled its charter with regard to this document set. The WG was supposed to produce a "JSON syntax that can be used by applications to describe secure data objects". I don't believe it did that. Instead, it produced a compact serialization for a particular purpose and then backed into a JSON syntax. The compact serialization drove the effort and produced IMO a substandard JSON serialization. I don't believe that (reliable) interoperable implementations of the JSON serialization will be possible using this document set. However, there is at least rough consensus that these documents are usable as-is, and I don't think there's anything to be gained by holding them up any further.

I hope the WG will adopt some of the remaining comments, but my intention is not to discuss this any further. If you wish to address any of the comments and need clarification, I'm glad to help with that.

------

4/5:

There was a discussion about the "The member names within a JWK MUST be unique" paragraphs, and a proposal to fix them. No fixing was done.

4.1: The second paragraph is unnecessary and should be removed. Also, "use" is unnecessary given "key_ops" and should be removed.

4.6 (and 4.7-4.9):

   If other members
   are present, the contents of those members MUST be semantically
   consistent with the related fields in the first certificate.

This is a pretty silly use of MUST. If the answer to the question, "Why might
someone do otherwise?" is "Because they're an idiot", you probably don't need
the MUST.

5:

   Implementations SHOULD ignore JWKs within a JWK Set that use "kty"
   (key type) values that are not understood by them, are missing
   required members, or for which values are out of the supported
   ranges.

I don't understand that SHOULD. This is completely dependent on what the
implementation is doing. Unknown key types might be ignorable, but they might
be vitally important. Why is this not a MAY?

5.1: Strike the last sentence. It's silly.

7: The first two sentences of the first paragraph and the first sentence of the
second paragraph should be moved under Security Considerations; that's what
this is. I'd delete the rest, as the encryption of any JSON object is handled
by JWE.

You might mention the content type somewhere, but the way it is in the document
now is way overdone, with the whole "MUST...unless construction. Simply make it:

   The content type of "jwk+json" can be used for "cty" header of the JWE.

if you must have something.