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

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 3 Nov 2014 16:15:02 -0500

Pete,

Have you had  a chance to look at this?  I know you have been busy, so
hopefully the timing is better now.  Is there any way we can resolve
this before next week (or at least some of the outstanding issues if
not all)?

Thanks!

On Tue, Oct 7, 2014 at 2:11 AM, Mike Jones <[email-masked]> wrote:
>> -----Original Message-----
>> From: Jim Schaad [mailto:[email-masked]]
>> Sent: Monday, October 06, 2014 5:35 AM
>> To: Mike Jones; 'Pete Resnick'; 'The IESG'
>> Cc: [email-masked]; [email-masked]; draft-ietf-jose-json-web-
>> [email-masked]
>> Subject: RE: [jose] Pete Resnick's Discuss on draft-ietf-jose-json-web-signature-
>> 33: (with DISCUSS and COMMENT)
>>
>> > -----Original Message-----
>> > From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
>> > Sent: Saturday, October 04, 2014 6:58 PM
>> > To: Pete Resnick; The IESG
>> > Cc: [email-masked]; [email-masked];
>> > draft-ietf-jose-json-web- [email-masked]
>> > 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 [mailto:[email-masked]]
>> > > Sent: Wednesday, October 01, 2014 9:14 PM
>> > > To: The IESG
>> > > Cc: [email-masked]; draft-ietf-jose-json-web-
>> > > [email-masked]
>> > > 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
>> > > http://www.ietf.org/iesg/statement/discuss-criteria.html
>> > > for more information about IESG DISCUSS and COMMENT positions.
>> > >
>> > >
>> > > The document, along with other ballot positions, can be found here:
>> > > http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature/
>> > >
>> > >
>> > >
>> > > --------------------------------------------------------------------
>> > > --
>> > > DISCUSS:
>> > > --------------------------------------------------------------------
>> > > --
>> > >
>> > > 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.
>
> Agreed.  It's understood by at least some in the working group how we could do a compact serialization representation enabling multiple signatures, but this could easily be addressed in a subsequent specification, if an actual need for it arises.  (BTW, the design thinking didn't apply to just the JWT use case - it applied to any simple JWS use case.)
>
>> > > 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.
>
> It's not that I have a low opinion of implementers (quite the contrary!) or that I think they wouldn't understand the specification if it were revised in the way that Pete suggests.  The disservice would be to write the prescriptive steps to validate a JWS in a way that said that it was necessary to convert any JWSs using the compact serialization to the JSON serialization in order to validate them.  This demonstrably isn't a necessary step.
>
> Only semantically necessary steps should be in the list.  Since this step isn't necessary, I therefore request that you withdraw this DISCUSS on that basis, Pete.
>
>> > > 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.
>> >
>> > > --------------------------------------------------------------------
>> > > --
>> > > COMMENT:
>> > > --------------------------------------------------------------------
>> > > --
>> > >
>> > > 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
>> http://trac.tools.ietf.org/wg/jose/trac/ticket/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.
>
> Yes, that's an understatement.  This was vigorously discussed on the thread http://www.ietf.org/mail-archive/web/jose/current/msg02645.html "[jose] #26: Allow for signature payload to not be base64 encoded" (33 messages) in the context of http://trac.tools.ietf.org/wg/jose/trac/ticket/26, following a preceding discussion that also covered the much of the same ground of issue http://trac.tools.ietf.org/wg/jose/trac/ticket/23 on the thread http://www.ietf.org/mail-archive/web/jose/current/msg02493.html "[jose] #23: Make crypto independent of binary encoding (base64)" (39 messages).  Working group discussion of #23 and #26 is also recorded in the minutes of IETF 87 at http://www.ietf.org/proceedings/87/minutes/minutes-87-jose.
>
>> > > 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
>> > http://tools.ietf.org/html/draft-ietf-jose-cookbook-03.
>>
>> 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:
>> ...."
>
> I'm OK adding a forward reference to the JSON serialization example in A.6.
>
>> > > 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:1.2.3.4.5 to be the assigned name in the
>> IANA table does become an interesting question.
>
> Yes, the point of the collision-resistant name language is that Example org could use the algorithm name https://schemas.example.com/algorithms/2014/10/super-duper without having to register it, because no naming collisions would result.
>
>> >                             Thanks again,
>> >                             -- Mike
>> >
>> > _______________________________________________
>> > jose mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/jose
>

-- 

Best regards,
Kathleen

---

From: Pete Resnick <[email-masked]>
Date: Thu, 6 Nov 2014 05:44:35 -1000

> this before next week (or at least some of the outstanding issues if

I've gone through -36. I've copied in all of the context of the thread; 
hope that's not too confusing. Here's where I think we're at:

> On Tue, Oct 7, 2014 at 2:11 AM, Mike Jones<[email-masked]>  wrote:
>    
>>>>> ----------------------------------------------------------------------
>>>>> DISCUSS:
>>>>> ----------------------------------------------------------------------
>>>>>

On this one I'll simply pass. I think this is a failure in the protocol, 
and I think it's a sign that the WG has not lived up to their charter. 
But as Jim said, this was a conscious decision of the WG. I hope this 
means that in Jim and Karen's opinion, the WG properly considered it and 
came to consensus, not just that those in the non-JWT contigent got 
bullied and capitulated (and if that's not the case, I expect the chairs 
to speak up; that would be worthy of an IESG Note in the document, let 
alone an appeal). But all else being equal, in the rough I shall be.

>>>> see where it might be application specific and will suggest changes.
>>>> Thanks in advance, Pete.".
>>>>          

So I've gone through all of the "reject"s in the document, and I think I 
see a way to allay my concern without significantly changing the 
language: Instead of saying "reject the JWS" as it does in most places, 
I believe it would be much clearer if it simply said "reject the 
signature" as it does in 4.1.6. Then you're clearly not saying 
"rejecting the data", as I'm afraid certain sorts of applications 
developers will interpret it. In some instances, you'll need to say 
something like "reject the signature of a JWS with foobar", but I don't 
think that significantly changes the intended meaning.

>>> have ended up declaring myself in the weeds.

I presume you mean "in the rough". "In the weeds" is a much different 
state of affairs. :-)

>>> For better or worse, the main
>>> second class item in the document.

As I said above, this is yet another reason I am not convinced the WG 
lived up to its charter.

>>> I will admit that when I did a fast and dirty

Are you saying that the algorithm *is* normative? Because of the MUST? 
This is all the more reason to get rid of the MUST, as I suggested in my 
comments below. Any algorithm that produced an equivalent result *must* 
be acceptable.

>> Only semantically necessary steps should be in the list.  Since this step isn't necessary, I therefore request that you withdraw this DISCUSS on that basis, Pete.

I'm sorry, Mike, but that argument is nonsense. Using that arugment, for 
an implementation that is only doing the JSON serialization, none of the 
compact serialization stuff is semantically necessary. But the fact of 
the matter is that semantically you *are* treating the components 
identically between the two possible forms; you are decoding the 
serializations to produce the data structure that is the JWS. You've 
already heard Jim say that in his implementation, this is *exactly* what 
he did. The only thing you accomplish by repeatedly referring to the two 
different encodings is to make interpreting this section all the more 
prone to error. Does the rest of the WG really agree that this is the 
best way to write the algorithm? Again, if there is true consensus and 
I'm in rough, I'll step aside.

>>>>> during my review.

It's been greatly improved in -36. I'll have another pass to see if it 
can further simplified.

>>>> propose to clarify to which specific features ("jku" and "x5u") this section

Those are fine, but section 8 needs two fixes:

OLD
Implementations MUST support TLS.
NEW
Implementations that support the "jku" and "x5u" Header Parameters
defined by this specification MUST support TLS.

And then you can strike the last sentence.

>>>>> ----------------------------------------------------------------------
>>>>> COMMENT:
>>>>> ----------------------------------------------------------------------
>>>>>            
>>>>> 2. A "JSON Web Signature Signature" is an unfortunate terminology choice.
>>>>> [...] This whole "JW*" terminology thing is goofy.
>>>> See my response to your JWT review for the etymology of the "JSON 
>>>> Web ..." terminology. The "JWS" prefixes on some terms are there to 
>>>> indicate that the defined term is being used in specific way (such 
>>>> as "JWS Signature") versus a generic way (such as "signature").
>>>>> 3. "JWS object" is undefined. Do you just mean a JWS?
>>>>
>>>> Yes, the meaning is the same.  Sometimes the word "object" is included in locations that it seems to improve the readability of the text.

Then define it in section 2 please.

>>>>> Please reverse the order of section 3.1 and 3.2.
>>>>
>>>> The order is intentional.  The simple serialization is intentionally presented before the more general, more complicated serialization.

The compact serialization is much more complicated than the general JSON 
serialization.

>>>>> thing? Also, why doesit have to be base64ed?

I looked at those minutes and I do not see in there the reason why the 
WG rejected issues 23 & 26. Indeed, the discussion that appears in the 
minutes makes it sound like there were several good arguments to make it 
possible for the payload to be separate. I'll live with the result if 
the WG truly came to rough consensus on this, but the evidence provided 
does not show that.

>>>>> states, don't just give the compact.
>>>>>            

But you still need to change the title of the section and the text to 
indicate that this is not a general example of JWS, but of a compact 
serialization of a JWS.

>>>> safely used. IANA registration is definitely the right thing to do for open

But again, this has no effect on the interoperable use of the protocol. 
Again, I would get rid of this discussion.

>>>>> 4.1.9 (and elsewhere): "Sender" is the wrong term here. (Same with
>>>>> "recipient".) "Generators" and "interpreters" seems much better.
>>>>
>>>> Thanks.   What about using the terms "producers" and "consumers"?

I like it. Thanks.

>>>>> 5.1: s/MUST perform/performs
>>>> I don't think I understand the motivation for this suggested change.
>>>> All the steps must be performed...

This is going to depend a bit on the discussion above whether or not the 
algorithm is normative, but the following of the algorithm is completely 
a local implementation issue, not an interoperability point that needs 
to be identified with a MUST.

>>>>>    2. Why is BASE64URLing the payload required? If I want to use a binary
>>>>> payload, or something that I know is a string, why not just use it as-is?
>>>>> The encoding of the payload should be application dependent.
>>>> See my response to your comment on the same issue in Section 3.2.

Ack. Continued above.

>>>>>    3. There might not be a Protected Header. Better to say "the JWS Protected
>>>>> Header and/or the JWS Unprotected Header, as appropriate."
>>>> Thanks

Oh, for heaven's sake! I didn't mean to introduce more confusion by 
splitting compact and general in the discussion. Just make #3:

3. Create the JSON object(s) containing the desired set of Header
Parameters, which together comprise the JOSE Header: the JWS
Protected Header and/or the JWS Unprotected Header, as
appropriate.

>>>>>    4. Strike the parenthetical "(which can only happen...)". Sounds like you are
>>>>> discouraging use of the JSON Serialization and the Unprotected Header.
>>>> It's not pejorative - it's intended to be informative to implementers.

To what sort of implementer is this informative? Sounds pejorative to 
me. Please strike it.

>>>>>    5. Again, why BASE64URL the payload? Also, I don't understand the need for
>>>>> the second sentence. Please explain.
>>>> The same answer applies as to the previous times this question was asked.

But what is the reason for the second sentence?

>>>>>    7 is not a step that you MUST perform.
>>>> You're right.  I'll consider whether text of this form needs to remain, and if so, how to write it in an actionable fashion.

Thanks.

>>>>>    9. Replace with "Create the desired serialized output, as described in Section
>>>>> 7." Stop privileging Compact.
>>>> The fact is that the Compact Serialization is (intentionally!) simple enough it can be fully described in the single sentence.  Same cannot be said of JSON Serialization, hence the need for the section reference.

That still doesn't make it a necessary step in this section. Please 
remove it.

>>>>> 5.2: s/MUST be taken/are performed.
>>>> Same response as to your related comment on 5.1

See above.

>>>>> 5.3: I don't understand why this section is necessary.
>>>> String comparison rules are necessary both for interoperability and security.  If comparisons of security-sensitive elements were done differently by different implementations, that would result in an ample attack surface.

I simply don't understand how exactly an implementer could get this 
wrong, especially since the comparisons, as the document says, are all 
of equality and inequality.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 6 Nov 2014 07:29:55 -0800

Hi Pete,
 
See below:

> From: jose [mailto:[email-masked]] On Behalf Of Pete Resnick
> Sent: Thursday, November 06, 2014 7:45 AM
> To: Kathleen Moriarty
> Cc: [email-masked]; Jim Schaad; Mike Jones; The IESG;
> [email-masked]; [email-masked]
> Subject: Re: [jose] Pete Resnick's Discuss on draft-ietf-jose-json-web-
hope
> that's not too confusing. Here's where I think we're at:
> 
> > On Tue, Oct 7, 2014 at 2:11 AM, Mike
> Jones<[email-masked]>  wrote:
> >
> >>>>> Compact Serialization? This seems like a real problem, since I
> >>>>> can't convert (in a round- trippable way) between a JWS with an
> >>>> 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.
> >>>
> >> Agreed.  It's understood by at least some in the working group how we
> >> could do a compact serialization representation enabling multiple
> >> signatures, but this could easily be addressed in a subsequent
> >> specification, if an actual need for it arises.  (BTW, the design
> >> thinking didn't apply to just the JWT use case - it applied to any
> >> simple JWS use case.)
> >>
> 
and I think
> it's a sign that the WG has not lived up to their charter.
means that
> in Jim and Karen's opinion, the WG properly considered it and came to
> consensus, not just that those in the non-JWT contigent got bullied and
> capitulated (and if that's not the case, I expect the chairs to speak up;
that
> would be worthy of an IESG Note in the document, let alone an appeal). But
all
> else being equal, in the rough I shall be.
> 

On this issue I do not remember anybody in or out of the JWT group that was
pressing for this ability.

> >>>>> [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.
> So I've gone through all of the "reject"s in the document, and I think I
see a
> way to allay my concern without significantly changing the
> language: Instead of saying "reject the JWS" as it does in most places, I
believe
> it would be much clearer if it simply said "reject the signature" as it
does in
> 4.1.6. Then you're clearly not saying "rejecting the data", as I'm afraid
certain
> sorts of applications developers will interpret it. In some instances,
you'll need
> to say something like "reject the signature of a JWS with foobar", but I
don't
> >>> 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
state of
> affairs. :-)

Actually, I would was so far out that I was not even in the rough.  I made
this type of request and was soundly told off.

> >>> serialization.  This means that, IMHO, the JSON serialization was
> >>> always a second class item in the document.
> 
lived up
> to its charter.

Having gone back an re-read the charters, I can understand your point.  The
charter never talked about the different encoding methods, it only talk
about using JSON to be able to do this.  This is a case of dealing with the
working group we had rather than the one we could have wished for.  This
group was very focused on the compact encoding and not so much on the pure
JSON encodings.  This did affect a number of decisions.  However, short of
changing the authors and the participants I don't think a different outcome
would have ensued.  

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

It current says you must do the steps, even if you are permitted to
re-arrange  them.  I think the steps are general enough that you could not
devise an algorithm that was not equivalent to this.

> 
> >> It's not that I have a low opinion of implementers (quite the
contrary!) or
> that I think they wouldn't understand the specification if it were revised
in the
> way that Pete suggests.  The disservice would be to write the prescriptive
> steps to validate a JWS in a way that said that it was necessary to
convert any
> JWSs using the compact serialization to the JSON serialization in order to
> validate them.  This demonstrably isn't a necessary step.
> >>
> >> Only semantically necessary steps should be in the list.  Since this
step isn't
> necessary, I therefore request that you withdraw this DISCUSS on that
basis,
> Pete.
an
> implementation that is only doing the JSON serialization, none of the
compact
> serialization stuff is semantically necessary. But the fact of the matter
is that
> semantically you *are* treating the components identically between the two
> possible forms; you are decoding the serializations to produce the data
> structure that is the JWS. You've already heard Jim say that in his
> implementation, this is *exactly* what he did. The only thing you
accomplish
> by repeatedly referring to the two different encodings is to make
interpreting
> this section all the more prone to error. Does the rest of the WG really
agree
> that this is the best way to write the algorithm? Again, if there is true
> consensus and I'm in rough, I'll step aside.
> 
> >>>>> 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.
> >>>>>
> It's been greatly improved in -36. I'll have another pass to see if it can
further
> simplified.
> >>>> propose to clarify to which specific features ("jku" and "x5u")
> >>>> this section applies.
> >>>>
> 
> Implementations that support the "jku" and "x5u" Header Parameters defined
> by this specification MUST support TLS.
> 
> >>>> Yes, the meaning is the same.  Sometimes the word "object" is
included
> in locations that it seems to improve the readability of the text.
> 
> >>>> The order is intentional.  The simple serialization is intentionally
> presented before the more general, more complicated serialization.
> 
> >>>> 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 http://trac.tools.ietf.org/wg/jose/trac/ticket/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 strings that were parsed directly from the serialization could
> >>> be hashed and thus those strings are kept rather than the base64
> decoded strings.
> >>>
> >> Yes, that's an understatement.  This was vigorously discussed on the
thread
> http://www.ietf.org/mail-archive/web/jose/current/msg02645.html "[jose]
> #26: Allow for signature payload to not be base64 encoded" (33 messages)
in
> the context of http://trac.tools.ietf.org/wg/jose/trac/ticket/26,
following a
> preceding discussion that also covered the much of the same ground of
issue
> http://trac.tools.ietf.org/wg/jose/trac/ticket/23 on the thread
> http://www.ietf.org/mail-archive/web/jose/current/msg02493.html "[jose]
> #23: Make crypto independent of binary encoding (base64)" (39 messages).
> Working group discussion of #23 and #26 is also recorded in the minutes of
> IETF 87 at http://www.ietf.org/proceedings/87/minutes/minutes-87-jose.
> >>
> 
> I looked at those minutes and I do not see in there the reason why the WG
> rejected issues 23 & 26. Indeed, the discussion that appears in the
minutes
> makes it sound like there were several good arguments to make it possible
for
> the payload to be separate. I'll live with the result if the WG truly came
to
> rough consensus on this, but the evidence provided does not show that.
> 
> >>>>> 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
> >>>> 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
> >>> 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:
> >>> ...."
> >>>
indicate
> that this is not a general example of JWS, but of a compact serialization
of a
> JWS.
> >>>>> 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
> >>>> 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:1.2.3.4.5 to be the assigned
> >>> name in the IANA table does become an interesting question.
> >>>
> >> Yes, the point of the collision-resistant name language is that Example
org
> could use the algorithm name
> https://schemas.example.com/algorithms/2014/10/super-duper without
> having to register it, because no naming collisions would result.
> >>
> 
> algorithm is normative, but the following of the algorithm is completely a
local
> implementation issue, not an interoperability point that needs to be
identified
> with a MUST.
> 
> >>>>>    2. Why is BASE64URLing the payload required? If I want to use a
> >>>>> binary payload, or something that I know is a string, why not just
use it
> as-is?
> >>>>>    3. There might not be a Protected Header. Better to say "the
> >>>>> JWS Protected Header and/or the JWS Unprotected Header, as
> appropriate."
> >>>> Thanks
> 
splitting
> compact and general in the discussion. Just make #3:
> 
Parameters,
> which together comprise the JOSE Header: the JWS Protected Header and/or
> the JWS Unprotected Header, as appropriate.
> 
> >>>>>    4. Strike the parenthetical "(which can only happen...)".
> >>>>> Sounds like you are discouraging use of the JSON Serialization and
the
> Unprotected Header.
> To what sort of implementer is this informative? Sounds pejorative to me.
> Please strike it.
> 
> >>>>>    5. Again, why BASE64URL the payload? Also, I don't understand
> >>>>> the need for the second sentence. Please explain.
> >>>> You're right.  I'll consider whether text of this form needs to
remain, and
> if so, how to write it in an actionable fashion.
> 
> Thanks.
> 
> >>>>>    9. Replace with "Create the desired serialized output, as
> >>>>> described in Section 7." Stop privileging Compact.
> >>>> The fact is that the Compact Serialization is (intentionally!) simple
> enough it can be fully described in the single sentence.  Same cannot be
said
> of JSON Serialization, hence the need for the section reference.
> 
> That still doesn't make it a necessary step in this section. Please remove
it.
> >>>> String comparison rules are necessary both for interoperability and
> security.  If comparisons of security-sensitive elements were done
differently
> by different implementations, that would result in an ample attack
surface.
> 
> I simply don't understand how exactly an implementer could get this wrong,
> especially since the comparisons, as the document says, are all of
equality and
> inequality.

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 9 Nov 2014 20:26:44 -0500

Mike,

>> And then you can strike the last sentence.

This change Pete is suggesting was discussed and agreed upon during
the telechat.  Please make this update to change the first sentence so
that TLS is not required for everything.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Thu, 13 Nov 2014 05:27:40 +0000

Hi Pete,

The first sentence of the TLS Requirements section in my editor's draft has been changed as follows:

OLD:  
    Implementations MUST support TLS.
NEW:
    Implementations supporting the "jku" and/or "x5u" Header Parameters MUST support TLS.

Does this new language work for you?

				-- Mike

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Sunday, November 09, 2014 3:27 PM
To: Jim Schaad
Cc: Pete Resnick; [email-masked]; Mike Jones; The IESG; [email-masked]; [email-masked]
Subject: Re: [jose] Pete Resnick's Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)

Mike,

On Thu, Nov 6, 2014 at 10:29 AM, Jim Schaad <[email-masked]> wrote:
>> > Have you had  a chance to look at this?  I know you have been busy, 
>> > so hopefully the timing is better now.  Is there any way we can 
>> > resolve this before next week (or at least some of the outstanding 
>> > issues if not all)?
>> >
>>
>> >>>> Thanks for your review, Pete.  I've added the working group to 
>> >>>> the
>> thread.
>> >>>>> ---------------------------------------------------------------
>> >>>>> ---
>> >>>>> ----
>> >>>>> DISCUSS:
>> >>>>> ---------------------------------------------------------------
>> >>>>> ---
>> >>>>> ----
>> >>>>>
>> >>>> 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?
>> >>>>
>> >> Agreed.  It's understood by at least some in the working group how 
>> >> we could do a compact serialization representation enabling 
>> >> multiple signatures, but this could easily be addressed in a 
>> >> subsequent specification, if an actual need for it arises.  (BTW, 
>> >> the design thinking didn't apply to just the JWT use case - it 
>> >> applied to any simple JWS use case.)
>> >>
>>
>> consensus, not just that those in the non-JWT contigent got bullied 
>> and capitulated (and if that's not the case, I expect the chairs to 
>> speak up;
> that
> On this issue I do not remember anybody in or out of the JWT group 
> that was pressing for this ability.
>
>> >>>>> 5.2:
>> >>>>>
>> >>>>> 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".
>> >>>>>
>> >>>> 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.
>> >>>> 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.
>> >>>>
> Actually, I would was so far out that I was not even in the rough.  I 
> made this type of request and was soundly told off.
>
>>
>> >>> 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.
>>
> Having gone back an re-read the charters, I can understand your point.  
> The charter never talked about the different encoding methods, it only 
> talk about using JSON to be able to do this.  This is a case of 
> dealing with the working group we had rather than the one we could 
> have wished for.  This group was very focused on the compact encoding 
> and not so much on the pure JSON encodings.  This did affect a number 
> of decisions.  However, short of changing the authors and the 
> participants I don't think a different outcome would have ensued.
>
>>
>> >>> 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.
>> >>>
>>
>> This is all the more reason to get rid of the MUST, as I suggested in 
>> my comments below. Any algorithm that produced an equivalent result 
>> *must* be acceptable.
>
> re-arrange  them.  I think the steps are general enough that you could 
> not devise an algorithm that was not equivalent to this.
>
>
>>
>> way that Pete suggests.  The disservice would be to write the 
>> prescriptive steps to validate a JWS in a way that said that it was 
>> necessary to
> convert any
>> JWSs using the compact serialization to the JSON serialization in 
>> order to validate them.  This demonstrably isn't a necessary step.
>> >>
>> semantically you *are* treating the components identically between 
>> the two possible forms; you are decoding the serializations to 
>> produce the data structure that is the JWS. You've already heard Jim 
>> say that in his implementation, this is *exactly* what he did. The 
>> only thing you
> accomplish
>> that this is the best way to write the algorithm? Again, if there is 
>> true consensus and I'm in rough, I'll step aside.
>>
>> >>>> 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.
>> >>>>>

This change Pete is suggesting was discussed and agreed upon during the telechat.  Please make this update to change the first sentence so that TLS is not required for everything.

Thanks,
Kathleen

>>
>> >>>>> ---------------------------------------------------------------
>> >>>>> ---
>> >>>>> ----
>> >>>>> COMMENT:
>> >>>>> ---------------------------------------------------------------
>> >>>>> ---
>> >>>>> ----
>> >>>>>
>> >>>>> 2. A "JSON Web Signature Signature" is an unfortunate 
>> >>>>> terminology
>> choice.
>> >>>> See my response to your JWT review for the etymology of the 
>> >>>> "JSON Web ..." terminology. The "JWS" prefixes on some terms are 
>> >>>> there to indicate that the defined term is being used in 
>> >>>> specific way (such as "JWS Signature") versus a generic way (such as "signature").
>> The compact serialization is much more complicated than the general 
>> JSON serialization.
>>
>> >>>>> 3.2:
>> >>>>>
>> >>>>>     In the JWS JSON Serialization, a JWS object is represented 
>> >>>>> as
> the
>> >>>>> 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 doesit 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.
>> >>>> arbitrary octet sequences.  This enables the "binary object" 
>> >>>> case that you're describing to work.  Also note that this was 
>> >>> 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
>> >>> The strings that were parsed directly from the serialization 
>> >>> could be hashed and thus those strings are kept rather than the 
>> >>> base64
>> decoded strings.
>> >>>
>> Working group discussion of #23 and #26 is also recorded in the 
>> minutes of IETF 87 at http://www.ietf.org/proceedings/87/minutes/minutes-87-jose.
>> >>
>>
>> I looked at those minutes and I do not see in there the reason why 
>> the WG rejected issues 23 & 26. Indeed, the discussion that appears 
>> in the
> minutes
>> >>>>> 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
>> >>> 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
>> >> I'm OK adding a forward reference to the JSON serialization 
>> >> example in
>> A.6.
>> >>
>>
>> >>>>> 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.
>> >>>>>
>> >>>> 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
>> >>> What happens if they then ask for OID:1.2.3.4.5 to be the 
>> >>> assigned name in the IANA table does become an interesting question.
>> >>>
>> This is going to depend a bit on the discussion above whether or not 
>> the algorithm is normative, but the following of the algorithm is 
>> completely a
> local
>> >>>>>    2. Why is BASE64URLing the payload required? If I want to 
>> >>>>> use a binary payload, or something that I know is a string, why 
>> >>>>> not just
> use it
>> as-is?
>> which together comprise the JOSE Header: the JWS Protected Header 
>> and/or the JWS Unprotected Header, as appropriate.
>>
>> >>>>>    5. Again, why BASE64URL the payload? Also, I don't 
>> >>>>> understand the need for the second sentence. Please explain.
>> >>>> The same answer applies as to the previous times this question 
>> >>>> was
>> asked.
>>
>> remove
>> wrong, especially since the comparisons, as the document says, are 
>> all of
> equality and
>> inequality.
>>
>> pr
>>
>> --

-- 

Best regards,
Kathleen

---

From: Pete Resnick <[email-masked]>
Date: Thu, 13 Nov 2014 13:10:29 -1000

> Does this new language work for you?

Peachy. Thanks.

pr

---

From: Mike Jones <[email-masked]>
Date: Wed, 19 Nov 2014 21:49:04 +0000

Below I'm responding only to the remaining issue about "rejecting JWSs".   Pete, please let me know if the proposed language works for you.

> >>>> to see where it might be application specific and will suggest changes.
> So I've gone through all of the "reject"s in the document, and I think I see a
> believe it would be much clearer if it simply said "reject the signature" as it
> does in 4.1.6. Then you're clearly not saying "rejecting the data", as I'm afraid
> certain sorts of applications developers will interpret it. In some instances,
> you'll need to say something like "reject the signature of a JWS with foobar",
> but I don't think that significantly changes the intended meaning.

It turns out that way back in draft -15, in response to issue #35 (http://trac.tools.ietf.org/wg/jose/trac/ticket/35), we'd already changed statements about "rejecting the JWS" in contexts of signature failures to statements about  the JWS Signature being invalid.  So those uses of "reject the JWS" that remained were actually about rejecting the whole thing - not about rejecting the signature.  I'm revisiting that history because your suggested language about "reject the signature" doesn't actually convey the correct meaning in the remaining contexts.

But I understand and agree with your intent - which is to say that implementations will determine that some JWSs are invalid, rather than the "rejection" being some kind of cataclysmic failure.  To achieve this intent, I've instead changed the language "reject the JWS" to "consider the JWS to be invalid" in my current editor's draft.  Let me know if that works for you.

I've made the parallel changes in the JWE draft as well.

				Thanks again,
				-- Mike

---

From: John Bradley <[email-masked]>
Date: Wed, 19 Nov 2014 16:52:29 -0500

OK with me.

> On Nov 19, 2014, at 4:49 PM, Mike Jones <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 20 Nov 2014 01:25:27 +0000

This resolution is incorporated in the -37 drafts.

				-- Mike

-----Original Message-----
From: Pete Resnick [mailto:[email-masked]] 
Sent: Thursday, November 13, 2014 3:10 PM
To: Mike Jones
Cc: Kathleen Moriarty; Jim Schaad; [email-masked]; The IESG; [email-masked]; [email-masked]
Subject: Re: [jose] Pete Resnick's Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)

Peachy. Thanks.

pr

---

From: Mike Jones <[email-masked]>
Date: Thu, 20 Nov 2014 01:25:49 +0000

-- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, November 19, 2014 1:49 PM
To: Pete Resnick
Cc: [email-masked]; Jim Schaad; Kathleen Moriarty; The IESG; [email-masked]; [email-masked]
Subject: Re: [jose] Pete Resnick's Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)

> So I've gone through all of the "reject"s in the document, and I think 
> I see a way to allay my concern without significantly changing the
> language: Instead of saying "reject the JWS" as it does in most 
> places, I believe it would be much clearer if it simply said "reject 
> the signature" as it does in 4.1.6. Then you're clearly not saying 
> something like "reject the signature of a JWS with foobar", but I don't think that significantly changes the intended meaning.

				Thanks again,
				-- Mike