Subject: [jose] Comments on the JOSE drafts

From: Yaron Sheffer <[email-masked]>
Date: Wed, 18 Jan 2012 09:26:42 +0200

Hi,

below is a set of comments on the new drafts. I am new to this list, and 
I apologize if these issues have already beaten to death.

draft-ietf-jose-json-web-key-00

* This is probably water under the bridge by now, but I think the 
applicability of bare public keys (as opposed to certificates and 
certificate chains) is very limited. And there is value in using the 
mechanisms defined here for certificate (and not just public key) roll-over.
* In addition, integrity protection and encryption with symmetric keys 
is also extremely useful. For example, this format could be used for 
Kerberos-like authorization tickets.
* Why mention specifically RSA and Elliptic Curve, instead of building 
on (a subset of) PKCS#8, which is more generic? For example, someone's 
bound to require modular DSA at some point.
* "EC" is not an algorithm. You probably mean "ECDSA" (e.g. as opposed 
to ECDH).
* The way we propose to deal with additional, unknown members precludes 
extensibility. One can easily think of meaningful optional members (e.g. 
key owner, key version) that do NOT need to be understood by most consumers.

draft-ietf-jose-json-web-signature-00

* Again, why mention HMAC already in the introduction, vs. the more 
generic "message authentication code".

* Can the payload be binary? The Terminology should clarify it.
* The definition of JWS Header is self-referential and confusing.
* "Computing the HMAC of the UTF-8 representation": this is a bit 
misleading - the representation is actually good old ASCII.
* In the same paragraph, computing HMAC-256 also requires a key, which 
should have been mentioned.
* When defining the jku member: RFC 6125 is very new - do we really have 
to make it mandatory here?
* No way is defined to name symmetric keys used for HMAC signatures.
* I suggest to rename x5t to something that includes the algorithm, e.g. 
"x5t_sha1". We have already migrated from MD5 to SHA-1, there will be 
more coming. But the idea of using key names instead of the full key is 
valuable.
* Again, step #3 of the JWS validation process precludes easy 
extensibility. In many cases you do NOT want the signature consumer to 
understand all the fields. In particular when some parameters ("typ") 
are underspecified.
* IANA considerations: why not define a way for implementations to have 
member names that are guaranteed *not* to become reserved? Something 
like "x-*"? URIs are simply too long.
* Also, it is very important to allow for IANA extensibility of the set 
of supported algorithms (probably in the forthcoming JWA document).

draft-ietf-jose-json-web-encryption-00

* Many people are still not using authenticated-encryption algorithms. 
Such people are very likely to abuse this specification, i.e. use just 
encryption with no integrity protection (yes, despite the SHOULD wording 
at the bottom of the document). IMHO this spec must also support the 
more traditional usage of encryption+MAC. Integrity protection should 
not be left as an implementer's option.

* 4.2: this paragraph talks about parameter names, but also sneaks in 
algorithm names, which probably require a separate IANA registry and 
possibly separate extensibility rules. I suggest to separate them out.
* 5: in steps #5 and #6, this is not a bitstring, it's a byte string (or 
a "sequence of octets").
* 6: the decryption step (#6) also includes validation of the AES-GCM 
authentication tag, and this may fail of course.
* 7.2: OK, the algorithm can be specified, but how do we reference the 
key being used, and its version number?
* As far as I know "randomness in browsers... is easy to screw up" is 
actually an understatement. It is still impossible to do, at least not 
in a portable way.