Re: [jose] Pete Resnick's Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)

"Jim Schaad" <> Mon, 06 October 2014 12:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 853CA1A6EF4; Mon, 6 Oct 2014 05:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zerNd-RJ0638; Mon, 6 Oct 2014 05:37:30 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9D7D61A6EED; Mon, 6 Oct 2014 05:37:30 -0700 (PDT)
Received: from Philemon ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 00D122CA2D; Mon, 6 Oct 2014 05:37:28 -0700 (PDT)
From: Jim Schaad <>
To: 'Mike Jones' <>, 'Pete Resnick' <>, 'The IESG' <>
References: <> <>
In-Reply-To: <>
Date: Mon, 06 Oct 2014 05:34:46 -0700
Message-ID: <008a01cfe161$f0ec5090$d2c4f1b0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQMEsh24jei1OKH93nz8P0Tvh4YIqQGUmB0ymawRMAA=
Content-Language: en-us
Subject: Re: [jose] Pete Resnick's Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Oct 2014 12:37:33 -0000

> -----Original Message-----
> From: jose [] On Behalf Of Mike Jones
> Sent: Saturday, October 04, 2014 6:58 PM
> To: Pete Resnick; The IESG
> Cc:;; draft-ietf-jose-json-web-
> Subject: Re: [jose] Pete Resnick's Discuss on draft-ietf-jose-json-web-
> signature-33: (with DISCUSS and COMMENT)
> Thanks for your review, Pete.  I've added the working group to the thread.
> Replies are inline below...
> > -----Original Message-----
> > From: Pete Resnick []
> > Sent: Wednesday, October 01, 2014 9:14 PM
> > To: The IESG
> > Cc:; draft-ietf-jose-json-web-
> >
> > Subject: Pete Resnick's Discuss on
> > draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)
> >
> > Pete Resnick has entered the following ballot position for
> > draft-ietf-jose-json-web-signature-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
> >
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> >
> >
> >
> >
> > ----------------------------------------------------------------------
> > ----------------------------------------------------------------------
> >
> > 3.1: Why can't I use an unprotected header when I'm using the Compact
> > Serialization? This seems like a real problem, since I can't convert
> > (in a round- trippable way) between a JWS with an unprotected header
> > in the JSON Serialization to a Compact Serialization. Why the limitation?
> As Richard explained during the telechat, this was a deliberate choice on the
> part of the working group to keep the compact form as simple as possible by
> removing some options.  Do I remember correctly that you said on the
> telechat that you would be willing to withdraw this DISCUSS on that basis?

There was an explicit decision by the group that the JWT case did not require a multiple signature capability.  Thus when the JSON form was developed it was determined that this would not be back ported into that format.  I think that until we have a case that wants the compact format and needs multiple signers this is a reasonable decision.

> > 5.2:
> >
> > Strike the last sentence of the second paragraph. There's no
> > requirement here. If none of them validate, I can do what I want with
> > the JWS. I needn't "reject" it. I might just mark it as "invalid".
> >
> > [Get rid of all talk of "rejecting" throughout this document. Again, I
> > will note that the signatures are not valid, but rejecting is a local
> > implementation detail.]
> As discussed during the telechat and on subsequent threads, the terms
> "accept" and "reject" are commonly used in this way, for instance, in RFC
> 5820.  As Kathleen wrote after the call, "For the "reject" language, Pete said
> on the call that he would go through each one to see where it might be
> application specific and will suggest changes.  Thanks in advance, Pete.".
> > This section would be greatly simplified if step 1 was: "If the
> > Compact Serialization is being used, convert it to the JSON Serialization."
> This would be doing a disservice to some implementers, since some
> implementations (for instance those designed to support JWTs) will only
> implement the Compact Serialization.  I therefore request that you withdraw
> this DISCUSS on that basis.

Mike, I have a higher opinion of most implementers than you apparently do.  I don't think this would really be an issue to change from that perspective.

Pete,  If I had proposed this to the group while things were in progress.   I would have ended up declaring myself in the weeds.  For better or worse, the main focus of the WG was on the compact serialization and not on the JSON serialization.  This means that, IMHO, the JSON serialization was always a second class item in the document.   I will admit that when I did a fast and dirty implementation I did exactly what you suggested in terms of doing the conversion before (and then after) everything else was done.

If this change was done, then it would also require that the first paragraph be re-written so that the algorithm becomes something other than normative.  That is it would need to say that any algorithm that produced an equivalent result would be acceptable.

> > Some of these steps are not steps. I could not follow this to figure
> > out what to do. This section could use a serious rewrite. I'm glad to
> > work with you on that, but did not have time to provide a rewrite during
> my review.
> This section has been heavily wordsmithed already by numerous reviewers.
> That said, I'd be glad to receive suggestion for specific proposed changes.
> > 8: This section needs to be removed. There is no need for TLS in a
> > whole host of applications that could implement this protocol.
> As discussed in threads that immediately followed your review, I propose to
> clarify to which specific features ("jku" and "x5u") this section applies.
> > ----------------------------------------------------------------------
> > ----------------------------------------------------------------------
> >
> > 3.2:
> >
> >    In the JWS JSON Serialization, a JWS object is represented as the
> >    combination of these four values,
> >       BASE64URL(UTF8(JWS Protected Header)),
> >       JWS Unprotected Header,
> >       BASE64URL(JWS Payload), and
> >       BASE64URL(JWS Signature)
> >
> > Why is the Payload (a) part of the serialization and (b) base64ed? Are
> > you saying that the only way I can use JWS is to include the payload
> > as part of the JOSE object? Why can't it be a separate thing? Also, why does
> it have to be base64ed?
> > It could be a UTF-8 string, or it could be a large binary object that
> > I'm using in a non-JSON context, neither of which I want to bloat by
> > base64ing it. This seems bogus.
> It is base64url encoded because JSON has no way of representing arbitrary
> octet sequences.  This enables the "binary object" case that you're describing
> to work.  Also note that this was extensively discussed by the working group
> in the context of issue #26

Pete,  I tried to strongly argue that this change should be made and in the end had to declare myself in the weeds as far as the working group was considered.  The reasons that were given by people in the group did not have to do with security, i.e. that one or the other was more or less secure, and had more to do with "We have already deployed code that uses the base64 as the input rather than the raw data and don't feel it would be reasonable to change at this time."  The initial impetus for doing and use the base64 was the compact serialization.  The strings that were parsed directly from the serialization could be hashed and thus those strings are kept rather than the base64 decoded strings.

The working group would not be happy with this change.

> > I'll get back to in Section 5. Finally:
> >
> >    Concatenating these values...
> >
> > This section is not about the compact serialization. If you want to
> > give both example serializations in this section, fine, but if you are
> > giving a general "Example JWS" as the title of the section states, don't just
> give the compact.
> The point is to give a simple example to familiarize readers with the idea of a
> JWS - not for the example section to be a complete tutorial on the
> possibilities.  Note, however than an example using the JSON Serialization
> *is* present in Appendix A.6 and many are present in

At a minimum I think that there should be a sentence that points to the appendix for an example of a compact serialization.  I would be good if the example was the same as this one, but that may be stretching the issue too far.   I don’t think that Pete is to far out of line in requesting that there be a paragraph at the end that says "The equivalent to this example using the JSON serialization would be: ...."

> > 4.1.1/4.2: Why even bother mentioning that the alg could be a
> > "Collision- Resistant Name" (what a term!)? The alg should be registered.
> > If it's not, you're in private agreement space anyway, so it needn't
> > be specified in the spec. Same thing for Public Header Parameter
> > Names: If you're going to do this interoperably, you're going to have
> > to know what the thing means; otherwise, it's out of band anyway. I
> > say get rid of the whole concept of using non-registered names.
> Per the response to a similar comment in Stephen Kent's secdir review:
> This specification will be used both in open environments, in which multiple
> organizations will need to have a common understanding of any extensions
> used, and closed environments, which the producing and consuming
> organization will always be the same and private values could be safely used.
> IANA registration is definitely the right thing to do for open environments.  It
> s probably unnecessary for deployments in closed environments.

I have a small agreement here with Pete.  If this is really a closed environment then the uses would not care if they violated this type of statement.  There is no 2119 language regarding this feature.  I am a bit more sympathetic to keep the collision resistant naming as this means that we won't get people saying we are going to use FOOBAR for algorithm foo and never get it registered so we end up with FOOBAR and foo as two different names for the same algorithm.  It would be clear that one was assigned by a specific entity and did not go through IANA.  What happens if they then ask for OID: to be the assigned name in the IANA table does become an interesting question.

> 				Thanks again,
> 				-- Mike
> _______________________________________________
> jose mailing list