JSON Web Key (JWK)
draft-ietf-jose-json-web-key-41
Yes
(Kathleen Moriarty)
No Objection
(Adrian Farrel)
(Alissa Cooper)
(Barry Leiba)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Spencer Dawkins)
Abstain
Note: This ballot was opened for revision 32 and is now closed.
Kathleen Moriarty Former IESG member
Yes
Yes
(for -32)
Unknown
Richard Barnes Former IESG member
(was Discuss)
Yes
Yes
(2014-10-01 for -36)
Unknown
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.
Adrian Farrel Former IESG member
No Objection
No Objection
(for -33)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -33)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -33)
Unknown
Brian Haberman Former IESG member
(was No Record, No Objection)
No Objection
No Objection
(for -33)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -33)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -33)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -33)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -33)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2014-10-21 for -35)
Unknown
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.
Ted Lemon Former IESG member
No Objection
No Objection
(2014-10-02 for -33)
Unknown
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?
Pete Resnick Former IESG member
Abstain
Abstain
(2014-12-02 for -37)
Unknown
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.