Subject: [jose] Discussion of open issues in JOSE drafts

From: Mike Jones <[email-masked]>
Date: Fri, 10 Feb 2012 21:31:11 +0000

Dear JOSE members,

As most of you have probably already seen, I put a section calling out open issues in each of the JOSE documents.  I'd like explicitly bring them to your attention to ensure they get discussed on by the working group before our upcoming meeting in Paris.  For those issues that we can close before then, I'd also like to include the resolutions to any resolved issues in updated drafts to be published before the March 3rd Internet Draft submission cut-off date.

I'll list the open issues in the drafts below and in some cases, propose resolutions to get the discussions going.  When proposing resolutions, to be clear, I'm writing as an individual working group participant - not as the editor.  Hopefully we can close many of these open issues in the next few weeks.  If you want to start discussion on a particular issue, it would probably be good to create an e-mail thread with a descriptive subject line for that issue to help people manage their participation in the discussion.

Hopefully we can reach consensus on many/most of these in the next few weeks.

                                                                Best wishes,
                                                                -- Mike

>From http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-00#section-9:

*         Clarify the optional ability to provide type information in the JWS header. Specifically, clarify the intended use of the typ Header Parameter, whether it conveys syntax or semantics, and indeed, whether this is the right approach. Also clarify the relationship between these type values and MIME [RFC2045] types.
I believe that the meaning of the typ parameter is going to be context-dependent in the general case, similarly to how the meanings of the issuer, audience, and principal claims are in in the JWT spec<http://tools.ietf.org/html/draft-jones-json-web-token-07>.  Given that the typ parameter is the only context-dependent parameter in the spec at present, one possible resolution is to remove it from the signature spec entirely and leave the definition of it up to usage profiles for particular contexts.  In particular, there's no reason that it couldn't be defined in the JWT spec, rather than JWS.  Would people be happier with that resolution or would they prefer that typ remain as-is?

*         Clarify the semantics of the kid (key ID) header parameter. Open issues include: What happens if a kid header is received with an unrecognized value? Is that an error? Should it be treated as if it's empty? What happens if the header has a recognized value but the value doesn't match the key associated with that value, but it does match another key that is associated with the issuer? Is that an error?
I believe that the key ID should definitely not be ignored or treated as empty in this case, as that may introduce security issues.  If provided, I believe that a key matching the key ID MUST be used, and if not found, this is an error, just like any other reason for being unable to locate the correct key would be.

*         Consider whether a key type parameter should also be introduced.
I'm open to this possibility, but would like to understand a compelling scenario that requires this functionality first.  If someone wants this, I'd ask that they point the WG to an existing crypto spec with this functionality and let the WG know how the functionality you're requesting should be like and/or different than that.  If this isn't requested by participants with a compelling motivating scenario, I propose to delete this open issue from the next version of the spec.

*         Add Security Considerations text on timing attacks.
Write text saying how the time taken for crypto operations should be invariant to whether they succeed or fail, to thwart timing attacks to guess keys.  If someone can provide with me a reference we should use about timing attacks in the spec, that would be great.

*         It would be good to have a confirmation method element so it could be used with holder-of-key.
I'd welcome a specific proposal for this functionality.  Again, if it can be based on an existing successful method of achieving this, that would be best, as it would be good to invent as little as possible.

*         Consider whether to add parameters for directly including keys in the header, either as JWK Key Objects, or X.509 cert values, or both.
I suspect this will be required by some use cases.  Any disagreement or discussion?

*         Consider whether to add version numbers.
I believe these should be added by a later version of the spec, if ever needed.  Hopefully any revisions will not change the meaning of existing parameters but will only add new ones, effectively "versioning" the usage dynamically.  If you understand all the parameters in the new version, you're good.  If you don't, a version number wouldn't have helped you anyway.  Unless the discussion goes differently, I propose to delete this open issue.

*         Think about how to best describe the concept currently described as "the bytes of the UTF-8 representation of". Possible terms to use instead of "bytes of" include "byte sequence", "octet series", and "octet sequence". Also consider whether we want to add an overall clarifying statement somewhere in each spec something like "every place we say 'the UTF-8 representation of X', we mean 'the bytes of the UTF-8 representation of X'". That would potentially allow us to omit the "the bytes of" part everywhere else.
This one is purely editorial.  Any preferences from the WG?

*         Finish the Security Considerations section.
Volunteers welcome! :)  Proposed text for specific issues would be appreciated.

*         Add an example in which the payload is not a base64url encoded JSON object.
Editorial.  I plan to do this.

>From http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-00#section-12:

*         Describe the relationship between the JWE, JWS, and JWT header parameters. In particular, point out that the set of "alg" values defined by each must be compatible and non-overlapping.
Editorial.  I plan to do this.  This probably needs to be mentioned in both the JWE and JWS specs, and certainly in the JWA spec.

*         Consider whether we want to define composite integrity/encryption operations (as was the consensus to do at IIW, as documented at http://self-issued.info/?p=378). This would provide both confidentiality and integrity.
I believe there's consensus to add this capability to the JWE spec.

*         Consider whether reusing the JWS jku, kid, x5u, and x5t parameters is the right thing to do, particularly as it effectively precludes specifying composite operations.
This question will need to be addressed when specifying the composite operations.  The choices seem to be to use different parameter names or to use the same parameter names but put them inside a separate JSON object within the header.  Opinions?

*         Consider whether to add parameters for directly including keys in the header, either as JWK Key Objects, or X.509 cert values, or both.
As for JWS, I suspect this will be required by some use cases.  Any disagreement or discussion?

*         Consider whether to add version numbers.
As with JWS, I believe that this would not aid interoperability in practice.  Unless the WG disagrees, I propose to delete this open issue.

*         Consider which of the open issues from the JWS and JWT specs also apply here.
Having just reviewed them, the only one that seems that it may apply is a decision on whether to create a JSON serialization whose final representation is JSON (probably in separate specifications) in addition to the current compact serializations, whose representation is base64url encoded data structures.  One problem with the JSON serialization is the possible need for canonicalization algorithms.  (Bear in mind that not needing canonicalization is one of the major advantages of the present specs over the corresponding XML ones.)  I don't think, however that the outcome of this decision will affect the current specs either way.

*         Think about how to best describe the concept currently described as "the bytes of the UTF-8 representation of". Possible terms to use instead of "bytes of" include "byte sequence", "octet series", and "octet sequence". Also consider whether we want to add an overall clarifying statement somewhere in each spec something like "every place we say 'the UTF-8 representation of X', we mean 'the bytes of the UTF-8 representation of X'". That would potentially allow us to omit the "the bytes of" part everywhere else.
Same editorial question as for JWS.  Suggestions?

*         Finish the Security Considerations section.
Volunteers?  Proposed text for specific issues would be appreciated.

*         Write a note in the Security Considerations section about how x5t (x.509 certificate thumbprint) should be deprecated because of known problems with SHA-1.
This should be done, along with text describing that SHA-1 cert thumbprints are existing practice.  A related open issue is whether (and if so, how) to enable thumbprints using other algorithms.

*         Should StringOrURI use IRIs rather than RFC 3986 URIs?
Opinions?  Is this a standing IETF requirement now, or is this being handled on case-by-case basis as makes sense in context?

*         Provide a more robust description of the use of the IV. The current statement "For GCM, the random 64-bit IV is prepended to the ciphertext" in the Symmetric Encryption section is almost certainly out of place.
I'd welcome any of the experts who are WG members weighing in with proposed text here.

>From http://tools.ietf.org/html/draft-ietf-jose-json-web-key-00#section-8:

  *   Write the Security Considerations section.
Volunteers?  Proposed text for specific issues would be appreciated.

>From http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-00#section-7:

  *   Since RFC 3447 Section 8 explicitly calls for people NOT to adopt RSASSA-PKCS1 for new applications and instead requests that people transition to RSASSA-PSS, we probably need some Security Considerations text explaining why RSASSA-PKCS1 is being used (it's what's commonly implemented) and what the potential consequences are.
Volunteers?  Specific proposed text would be appreciated.

  *   Consider having an algorithm that is a MAC using SHA-256 that provides content integrity but for which there is no associated secret. This would be like the JWT "alg":"none", in that no validation of the authenticity content is performed but a checksum is provided.
I propose to delete this open issue unless a compelling scenario motivating this functionality is described and endorsed by the working group.

  *   Consider whether to define "alg":"none" here, rather than in the JWT spec.
This would seem to make sense, as other application contexts may also want this capability.  Any disagreement?

  *   Should we define the use of RFC 5649 key wrapping functions, which allow arbitrary key sizes, in addition to the current use of RFC 3394 key wrapping functions, which require that keys be multiples of 64 bits? Is this needed in practice?
In the interest of simplify, I propose that we only do this if specific motivating scenarios are described and endorsed by the WG.

  *   Decide whether to move the JWK algorithm family definitions "EC" and "RSA" here. This would likely result in all the family-specific parameter definitions also moving here ("crv", "x", "y", "mod", "exp"), leaving very little normative text in the JWK spec itself. This seems like it would reduce spec readability and so was not done.
After discussion, unless the WG disagrees, I propose to delete this open issue.

  *   It would be good to say somewhere, in normative language, that eventually the algorithms and/or key sizes currently specified will no longer be considered sufficiently secure and will be removed. Therefore, implementers MUST be prepared for this eventuality.
Agreed.  I'll plan on doing this.

  *   Write the Security Considerations section.
Volunteers?  Proposed text for specific issues would be appreciated.

---

From: Matt Miller <[email-masked]>
Date: Mon, 13 Feb 2012 11:33:57 -0700

Trimming non-considered concerns...

Also, another JWE concern that was stated in Taipei and on list:

* Accommodating multiple recipients

> As for JWS, I suspect this will be required by some use cases.  Any disagreement or discussion?

I need this for my use-cases.

> Having just reviewed them, the only one that seems that it may apply is a decision on whether to create a JSON serialization whose final representation is JSON (probably in separate specifications)…

I would concur on efforts to avoid canonicalization.  I can see the appeal to having a "JSON-Stringified" representation (e.g. value = JSON.parse(JSON.parse(input).field) ), but I personally have no problem sticking with base64 or base64url.

> Opinions?  Is this a standing IETF requirement now, or is this being handled on case-by-case basis as makes sense in context?

If humans are involved, then i18n is a concern.  I suspect, at the least, "jku" and "x5u" will require support for internationalized values.

> This would seem to make sense, as other application contexts may also want this capability.  Any disagreement?

I would find this very useful for some of my use-cases.

> After discussion, unless the WG disagrees, I propose to delete this open issue.

I personally don't see a problem with moving them, as long as there's plenty of (expanded) examples in the affected specs.

- m&m

Matt Miller - <[email-masked]>
Cisco Systems, Inc.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 13 Feb 2012 20:22:04 -0700

On 2/13/12 11:33 AM, Matt Miller wrote:

>> Opinions?  Is this a standing IETF requirement now, or is this
>> being handled on case-by-case basis as makes sense in context?
>> 
> 
> If humans are involved, then i18n is a concern.  I suspect, at the
> least, "jku" and "x5u" will require support for internationalized
> values.

UTF-8-encoded Unicode codepoints can be represented in URIs using
pct-encoding, so I don't necessarily see a need to directly support IRIs.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/