> -----Original Message-----
> From: Jim Schaad [mailto:[email protected]]
> Sent: Monday, October 06, 2014 5:35 AM
> To: Mike Jones; 'Pete Resnick'; 'The IESG'
> Cc: [email protected]; [email protected]; draft-ietf-jose-json-web-
> [email protected]
> 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 protected]] On Behalf Of Mike Jones
> > Sent: Saturday, October 04, 2014 6:58 PM
> > To: Pete Resnick; The IESG
> > Cc: [email protected]; [email protected];
> > draft-ietf-jose-json-web- [email protected]
> > 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 protected]]
> > > Sent: Wednesday, October 01, 2014 9:14 PM
> > > To: The IESG
> > > Cc: [email protected]; draft-ietf-jose-json-web-
> > > [email protected]
> > > 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 protected]
> > https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
