JSON Web Signature (JWS) Unencoded Payload Option
draft-ietf-jose-jws-signing-input-options-09

[Ballot comment]

Thanks for the discussion of "crit" which I think has resolved
so I'm clearing now.

I didn't check the comments below. No need to respond about
them unless you really want to.


- abstract: the description of the update to 7519 is odd. It
seems to be saying "Here we define a thing. This specification
updates 7519 to say you must not use this thing." but prohibiting
is an odd verb to use there. (Since it wasn't previously there to
be allowed or not.)

- section 6: "It is intended that application profiles specify up
front whether" "intended" is very wishy washy and "up front"
makes no sense at all.

[Ballot discuss]

The "crit" point raised in the gen-art review and maybe elsewhere
is I think correct but I don't think section 6 of -08 is a good
resolution of this topic. However, I'll clear if this is the WG
consensus but it's hard to know that's the case for text just
added yesterday. To resolve this discuss we just need to see what
the WG list says about the new text.

[Ballot comment]

- abstract: the description of the update to 7519 is odd. It
seems to be saying "Here we define a thing. This specification
updates 7519 to say you must not use this thing." but prohibiting
is an odd verb to use there. (Since it wasn't previously there to
be allowed or not.)

- section 6: "It is intended that application profiles specify up
front whether" "intended" is very wishy washy and "up front"
makes no sense at all.

[Ballot comment]
-7, last paragraph:

" Thus, method 1 -
  requiring support for this extension - is the preferred approach and
  the only means for this extension to be practically useful to
  applications."

One might wonder why method 2 and 3 are included. I assume it is to allow existing apps to migrate to method 1 over time? If so, some guidance on app migration might be useful.

Editorial:

-6, last paragraph:
It’s confusing to see "(JWT) [JWT]" . I suggest either removing (JWT), or changing the anchor for the citation to use [RFC7519]

[Ballot comment]
As mentioned by Stefan in his OPS DIR review:
There are coexistence issues between implementations which understand
the notion of the "b64" parameter (i.e. implementing this RFC) and those
who do not (i.e. all existing JWS implementations).
The issues are discussed in Security Considerations (second para up
until the end). The issues with it are:

* the conclusions are not as satisfactory as they could be.
Interoperability is either

- left as an out-of-band and undescribed mechanism ("make sure that
only supporting implementations talk to each other")
- by explicitly marking support for b64 as critical (IMO the only good
solution)
- modifying the payload so that it contains unparseable characters
(which may or may not be possible for the sender depending on the
payload characteristics)

* this is placed in Security Considerations while it has actual
operational impact on every transmitted message: in essence it states:
"Sometimes, sender and recipient may misunderstand each other without
noticing". Example given in the draft where the actual message is "NDA1"
while the recipient thinks it was told "405", without a way to notice.
Even if the misunderstanding is not related to security, it can/will
have significant implications for the application.

I believe this can not be left as-is. Luckily, there seems to be an easy
way out:

"Whenever the 'b64' header exists and is set to false, the 'crit' header
MUST also be present and contain 'b64'."

This, maybe in conjunction with

"When the content is intended to be base64 encoded, the 'b64' header
SHOULD NOT be present."

This would make sure that implementations who know nothing of b64 are
left alone (there is no unknown extension, there is no criticality in
any such extension, and the sender did not intend to make use of the
feature => all good). While at the same time for unencoded payloads
making deterministically clear that unencoded transmission is happening,
and is required to be understood.

This would at the same time make a complex piece of Sec Con go away.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-jose-jws-signing-input-options-06.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the JSON Web Signature and Encryption Header Parameters subregistry of the JSON Object Signing and Encryption (JOSE) registry located at:

http://www.iana.org/assignments/jose/

a new parameter is to be registered as follows:

Header Parameter Name: "b64"
Header Parameter Description: Base64url-Encode Payload
Header Parameter Usage Location(s): JWS
Change Controller: IESG
Specification Document(s): [ RFC-to-be ], Section 3

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: jose-chairs@ietf.org, "Jim Schaad" , ietf@augustcellars.com, mbj@microsoft.com, Kathleen.Moriarty.ietf@gmail.com, draft-ietf-jose-jws-signing-input-options@ietf.org, jose@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (JWS Unencoded Payload Option) to Proposed Standard


The IESG has received a request from the Javascript Object Signing and
Encryption WG (jose) to consider the following document:
- 'JWS Unencoded Payload Option'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-12-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  JSON Web Signature (JWS) represents the payload of a JWS as a
  base64url encoded value and uses this value in the JWS Signature
  computation.  While this enables arbitrary payloads to be integrity
  protected, some have described use cases in which the base64url
  encoding is unnecessary and/or an impediment to adoption, especially
  when the payload is large and/or detached.  This specification
  defines a means of accommodating these use cases by defining an
  option to change the JWS Signing Input computation to not base64url-
  encode the payload.  This option is intended to broaden the set of
  use cases for which the use of JWS is a good fit.

  This specification updates RFC 7519 by prohibiting the use of the
  unencoded payload option in JSON Web Tokens (JWTs).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-jose-jws-signing-input-options/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-jose-jws-signing-input-options/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) This is to be a Standards Track ocument.  This is correctly reflected on the document.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  JSON Web Signature (JWS) [RFC 7515] represents the payload as a  base64url encoded value and uses this value in the Signature  computation.  While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached.  This specification defines an alternate signature computation method that avoids the
  requirement to base64url-encode the payload.

Working Group Summary

  This document defines an alternate method to form the octet string that signatures are computed over for a JWS object.  This was the main focus of the discussions as it means that there are now potentially two different messages, one with and one without base64 encoding, that will have the same signature value.  The group believes that this has been adequately addressed in the current document.

Document Quality

  The document comes with examples of the new signatures, these examples have been validated by a non-author implementation.  A number of people have indicated that they are either planning to implement or are considering implementing the change in the signature scheme here.  Note that the document explicitly states that the JOSN Web Token community is not going to take this change. 

Personnel

  Jim Schaad acted as the Document Shepherd and Kathleen Moriarty is the Responsible Area Director.

(3)  The document was read in it's entirety for the last two versions to check for completeness and correctness.  This included going over the nits and looking at the mailing list to check that all consensus of the list was reflected in the document.  It was verified that the examples had been checked for correctness by at least one other person than the author.

(4)  The document has been throughly reviewed by the working group and by the document shepherd.  Additionally, since there is an update of an OAuth documnent, a request for OAuth review was requested as well.  No comments on the draft from the OAuth WG were noted.

(5) It would be nice to get additional confirmation of the examples, however they have been checked.  I believe that the security questions of the document have been sufficiently reviewed.

(6)  The fact that there are two different versions of encoding that produce the same text string for signing is worrisome to me.  The WG had the ability to address this when producing the JWS specification and decided not to do so that time.  In this document, the desire to allow for things to be smaller has lead to the fact that the b64 and crit headers can be omitted as being implicit.  This was the desire of the WG, but I personally feel that it is the wrong decision.

(7)  Mike Jones has confirmed that he knows of no IPR for this document.

(8)  No IPR disclourses exist for this document.

(9)  This is a solid WG consensus.  The individuals who might have objected to this document have long since left the WG.

(10)  Nobody has expressed any significant issues with either the approach or content of the document.

(11)  There is one non-RFC reference, but this document is reasonable for a normative reference.

(12) The document does not require any formal review.

(13) All references are appropriately marked as normative or informative.

(14) All normative references are in a good state.

(15) All normative references are considered to be stable.  There is one external reference to the Unicode Standard.

(16) Karen and I have had a discussion on this.  It is not clear that any documents need to be tagged as being updated.  The document is marked as updating RFC 7519 (JSON Web Token) and is not marked as updating RFC 7515 (JSON Web Signature).  The update to RFC 7519 consists of saying - do not use this document.  RFC 7515 was not updated because the IANA registry was used instead.  This should allow us to not update the JWS document.

(17) The consistency of the body and the IANA consideration has been checked as as the registration template against the registry.

(18)  The document does not define any new IANA registries.

(19)  There are no formal language sections for this document.