On 11/3/14 3:15 PM, Kathleen Moriarty wrote:
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)?
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 protected]> wrote:
-----Original Message-----
From: Jim Schaad [mailto:[email protected]]
Sent: Monday, October 06, 2014 5:35 AM
-----Original Message-----
From: jose [mailto:[email protected]] On Behalf Of Mike Jones
Sent: Saturday, October 04, 2014 6:58 PM
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
----------------------------------------------------------------------
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.)
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.
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.".
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.
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.
I presume you mean "in the rough". "In the weeds" is a much different
state of affairs. :-)
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.
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
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.
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.
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.
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.
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.
It's been greatly improved in -36. I'll have another pass to see if it
can further simplified.
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.
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.
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 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.
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 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.
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.
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.
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.
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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
