Subject: Re: [jose] Comments on the JOSE drafts

From: Mike Jones <[email-masked]>
Date: Sat, 11 Feb 2012 00:05:44 +0000

Thanks for your detailed comments, Yaron.  Responses inline below.

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.

There was an explicit working group decision to include JSON representation of bare public keys in the working group charter.  That being said, if there are specific changes you'd like to see, by all means, let's discuss them.

* 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.

If you make a compelling case for a scenario that requires or would benefit from this functionality, I'm sure the working group would consider it.

* 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.

The goal was to be able to encode public keys for algorithms in common usage on the Internet.  The more minimal, the more likely the spec is to be actually implemented, provided it actually meets the needs of the implementer's scenarios.  Thus, keys for RSA and Elliptic Curve algorithms were explicitly selected.

If you want to make the case for including other algorithm families based on a real scenario, I suspect the working group would be open to that.

* "EC" is not an algorithm. You probably mean "ECDSA" (e.g. as opposed to ECDH).

This may be more than you want to know, but in the first version of the spec<http://self-issued.info/docs/draft-jones-json-web-key-00.html>, this identifier was, in fact, "ECDSA".  This was changed in the -01 version with the introduction of the JWE spec and the need to represent keys used with the ECDH algorithm as well as those used with ECDSA.  The "EC" identifier is explicitly there to represent a family of algorithms sharing the same key representation - not a specific algorithm.

* 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.

For a core security feature, the decision was to err on the side of security, rather than convenience of extensibility.  The problem is - how would an implementation know whether it's safe to ignore a parameter or not?  Unless there's a way to tell outside of understanding the parameter itself, the only safe thing to do is to require rejecting not-understood parameters.

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

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

I'm open to this change.  Comments from others in the WG?

* Can the payload be binary? The Terminology should clarify it.

Yes.  The introduction already says "... independent of the type of content being secured, allowing arbitrary content to be secured", but I suppose I could this clarification to the JWS Payload definition as well.  I'll add this to my to-do list.

* The definition of JWS Header is self-referential and confusing.

Agreed, I'll clarify this in the next version to be more along the lines of the (hopefully clearer) JWE Header definition in the JWE spec.

* "Computing the HMAC of the UTF-8 representation": this is a bit misleading - the representation is actually good old ASCII.

Yes it is ASCII.  Would the language "Computing the HMAC of the bytes of the ASCII representation" be better?  Comments from others?

* In the same paragraph, computing HMAC-256 also requires a key, which should have been mentioned.

Agreed.  I'll add this to my to-do list.  (The key is shown in the example in Appendix A, but it should be mentioned in 3.1 as well.)

* When defining the jku member: RFC 6125 is very new - do we really have to make it mandatory here?

Opinions from the working group?

* No way is defined to name symmetric keys used for HMAC signatures.

I suspect the right thing to do is to generalize the Key ID language to allow it to be used for symmetric keys as well as asymmetric.  Any disagreement?

* 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.

Also see Jim Schaad's proposal  on this x5t that I replied to earlier today.  Ideas welcome...

* 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.

See my comments on the typ header parameter in JWS in my note "Discussion of open issues in JOSE drafts" sent earlier today.  I believe my comments on must-understand above also apply here in the general case, however.

* 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.

I believe the sense among IETF participants at this point is that "x-" was a well-intentioned idea that failed in practice for a number of real-world reasons.  But I would certainly be open to the WG discussing this possibility.

* Also, it is very important to allow for IANA extensibility of the set of supported algorithms (probably in the forthcoming JWA document).

Yes - a registry for this purpose is already specified.

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.

I believe the working group largely feels the same as you do on this point.  A proposal for enabling encryption+integrity is in the works.

* 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.

You're right that this is unnecessarily confusing, as written.  In practice, separate registries for header parameters and algorithms are already specified.  All add clarifying this text to my to-do list.

* 5: in steps #5 and #6, this is not a bitstring, it's a byte string (or a "sequence of octets").

Agreed - I'll make this change.

* 6: the decryption step (#6) also includes validation of the AES-GCM authentication tag, and this may fail of course.

Agreed - I'll make this clarification.

* 7.2: OK, the algorithm can be specified, but how do we reference the key being used, and its version number?

Possibly with the Key ID, per my earlier comment?

* 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.

That's what I thought.  Do you have a reference handy that authoritatively makes this point?

====

Thanks again for the detailed read!

                                                                -- Mike

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 11 Feb 2012 16:12:35 +0200

Hi Mike,

please see my responses below. Apologies as this message is getting too 
long for humans to parse...

On 02/11/2012 02:05 AM, Mike Jones wrote:
> * 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.
>
> There was an explicit working group decision to include JSON
> representation of bare public keys in the working group charter. That
> being said, if there are specific changes you’d like to see, by all
> means, let’s discuss them.

I'm OK with the web-key spec being focused on bare public keys. What's 
important is what can be used in JWS, and that clearly allows 
certificates. However note that the "jku" parameter in JWS Sec. 4.1 
mentions that it's used for "web keys" only, but then goes on to mention 
certificates.
>
> * 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.
>
> If you make a compelling case for a scenario that requires or would
> benefit from this functionality, I’m sure the working group would
> consider it.

Recently I wrote some code that allows one server in a very dynamic 
cloud setup to issue time-limited authorization tickets to other 
servers, tickets that can only be validated by the issuing server. This 
is much easier to do with symmetric keys than with public keys.
>
> * 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.
>
> The goal was to be able to encode public keys for algorithms in common
> usage on the Internet. The more minimal, the more likely the spec is to
> be actually implemented, provided it actually meets the needs of the
> implementer’s scenarios. Thus, keys for RSA and Elliptic Curve
> algorithms were explicitly selected.
>
> If you want to make the case for including other algorithm families
> based on a real scenario, I suspect the working group would be open to that.

I don't...
> This may be more than you want to know, but in the first version of the
> spec <http://self-issued.info/docs/draft-jones-json-web-key-00.html>,
> this identifier was, in fact, “ECDSA”. This was changed in the -01
> version with the introduction of the JWE spec and the need to represent
> keys used with the ECDH algorithm as well as those used with ECDSA. The
> “EC” identifier is explicitly there to represent a family of algorithms
> sharing the same key representation – not a specific algorithm.

OK.
>
> * The way we propose to deal with additional, unknown members precludes
> extensibility. One can easily think of meaningful optional members (e.g.
>
> For a core security feature, the decision was to err on the side of
> security, rather than convenience of extensibility. The problem is – how
> would an implementation /know/ whether it’s safe to ignore a parameter
> or not? Unless there’s a way to tell outside of understanding the
> parameter itself, the only safe thing to do is to require rejecting
> not-understood parameters.

There are standard ways of dealing with this issue, the so-called 
"critical" flag. The semantics needs to be defined very well. But I 
think it's worth the effort if you expect this format to be widely 
deployed. See e.g. bottom of http://tools.ietf.org/html/rfc5996#section-2.5.
> I’m open to this change. Comments from others in the WG?
>
> Yes. The introduction already says “… independent of the type of content
> being secured, allowing arbitrary content to be secured”, but I supposebit
> I could this clarification to the JWS Payload definition as well. I’ll
> add this to my to-do list.
>
> Agreed, I’ll clarify this in the next version to be more along the lines
> of the (hopefully clearer) JWE Header definition in the JWE spec.
>
> * "Computing the HMAC of the UTF-8 representation": this is a bit
> misleading - the representation is actually good old ASCII.
>
> Yes it is ASCII. Would the language “Computing the HMAC of the bytes of
> the ASCII representation” be better? Comments from others?

Fine with me.
> Agreed. I’ll add this to my to-do list. (The key /is/ shown in the
> example in Appendix A, but it should be mentioned in 3.1 as well.)
>
> I suspect the right thing to do is to generalize the Key ID language to
> allow it to be used for symmetric keys as well as asymmetric. Any
> disagreement?

Not from me.
> "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.
>
> Also see Jim Schaad’s proposal on this x5t that I replied to earlier
> today. Ideas welcome…
>
> * 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.
>
> See my comments on the typ header parameter in JWS in my note
> “Discussion of open issues in JOSE drafts” sent earlier today. I believe
> my comments on must-understand above also apply here in the general
> case, however.
>
> * 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.
>
> I believe the sense among IETF participants at this point is that “x-”
> was a well-intentioned idea that failed in practice for a number of
> real-world reasons. But I would certainly be open to the WG discussing
> this possibility.

You're probably right (although I don't know why "x-" is considered to 
have failed). Anyway, you can always use a URI.
>
> * Also, it is very important to allow for IANA extensibility of the set
> of supported algorithms (probably in the forthcoming JWA document).
>
> Yes – a registry for this purpose is already specified.
>
> 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.
>
> I believe the working group largely feels the same as you do on this
> point. A proposal for enabling encryption+integrity is in the works.
>
> * 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.
>
> You’re right that this is unnecessarily confusing, as written. In
> practice, separate registries for header parameters and algorithms are
> already specified. All add clarifying this text to my to-do list.
>
> Agreed – I’ll make this change.
>
> * 6: the decryption step (#6) also includes validation of the AES-GCM
> authentication tag, and this may fail of course.
>
> Agreed – I’ll make this clarification.
>

OK.
>
> * 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.
>
> That’s what I thought. Do you have a reference handy that
> authoritatively makes this point?
>
Nothing better than "private communication"...

> Thanks again for the detailed read!

My pleasure.

     Yaron