[jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)

["Richard Barnes" <[e-mail]>]

Richard Barnes has entered the following ballot position for
draft-ietf-jose-json-web-key-33: Discuss

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 http://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:
http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 4.3.
"The "use" and "key_ops" JWK members SHOULD NOT be used together."
Did the WG discuss how these could combine?  What was the outcome of that
discussion?  This could be an important point for interoperability.  For
example, WebCrypto enforces them both, so it will break if it gets a key
with "use" and "key_ops" set to inconsistent values.
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#rsa-pss-operations

Section 8.
"[TBD]@ietf.org"
This needs to be populated before approval.  I don't know what's
customary here, but "[e-mail]" is an obvious candidate.


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

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.