Re: [jose] Comments on the web signature draft version 11

[Mike Jones <[e-mail]>]

These changes have been applied to the -12 drafts.  Comments inline...

                                                            -- Mike

From: Jim Schaad [mailto:[e-mail]]
Sent: Friday, June 28, 2013 8:46 PM
To: Mike Jones; [e-mail]
Cc: [e-mail]
Subject: RE: [jose] Comments on the web signature draft version 11



From: Mike Jones [mailto:[e-mail]]
Sent: Thursday, June 27, 2013 3:48 PM
To: Jim Schaad; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [jose] Comments on the web signature draft version 11


Thanks for the useful review comments, Jim.  Replies inline prefixed by "Mike>"...



-----Original Message-----
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Jim Schaad
Sent: Saturday, June 15, 2013 1:14 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [jose] Comments on the web signature draft version 11



1.   Going from the string to the UTF8 encoding followed by the base64

encoding in section 3.1 is difficult given that it is not really possible to

figure out where the spaces, returns and new-lines are.   It would be easier

if you included the half-way step or better yet make the header be a single line.



Mike> OK - I'll copy this intermediate step forward from the appendix where it's already present.



[JLS}  I would strongly prefer the better yet approach.  In fact having started to try and do am implementation I am going to suggest something that is even a stricter suggestion.  It is difficult for me to match the same protected header fields if I don't have a set of rules to follow that are simple to program into my system.  As an example the mail on the list earlier about the difference between line endings in your example and those on other systems.



For the purpose of the examples I suggest the following rules be applied to the protected content:

a)      There is no whitespace permitted outside of strings (which I think means none)

b)      That all members of an object are emitted in alphabetical order according to standard ASCII



This convention should be documented at the start of the example appendix and then strictly followed.  This means that for checking the test vectors I can have a specialized generator and use my normal generator in production code but still be able to produce the examples from my library without having to hand code exceptions into it.



Mike> This seems like an unnecessary set of restrictions on the permitted JSON syntax.



2.  In section 3.1 rather than saying you are using ASCII, it might be better to omit the character set entirely.  IMHO, having ASCII in there confuses the issue rather than clarifies it.



Mike> Disagree.  EBCDIC still exists, could represent this string, and uses a different encoding.  The computation is dependent up the encoding, so it needs to be specified.



[JLS] I will worry about that issue when and if somebody does a base64url that produces EBCIDIC.



Mike> I don't see a reason to make the draft ambiguous in this regard.



4.  In section 4 para #1 - I am having an issue with the first sentence.

               a) Using "object(s)" to describe the possible hierarchy is messy as it might be possible to interpret this as interdependent rather than nested.



Mike> "JSON object" is a term from RFC 4627 - not a statement about possible hierarchy.  I could change the words "represented by" to "representing", as I think that would be clearer.  Would that address the issue for you?



[JLS] Not really - you could remove the "(s)"



Mike> The reason the (s) is necessary is that the JSON Serialization uses multiple JSON objects to represent the JWS Header.   I could change this to "JSON object or JSON objects" if you editorially prefer that, but the meaning is the same.



5.  In section 4 para #2 - Two items, this does not talk about header parameter not defined in this document and I think it might be more understandable if this was done as a series of bullet points rather than just text.



Mike> Actually, the paragraph does talk about header parameters not defined in this document: "Unless listed as a critical header parameter, per Section 4.1.10, all other header parameters MUST be ignored when not understood."  Editorially, I don't think that bullets would be the best choice, because the points being made in the different sentences are not grammatically parallel.



[JLS] That is not the way  that I interpreted the phrase so I would disagree.  TO me this is unclear text.  A change in the text should make it clearer and doing bullet points would be one way to change the text.



Mike> OK - it now explicitly uses the language "all header parameters not defined by this specification".



6.  In section 4.1.1 - I think the current text for rejection on alg is written on the assumption that there is only one signature/MAC on the object.  If there are two and there is both an implementation and a key for one signature but the second either does not have an implementation or a key

- is this still a MUST reject situation?



Mike> About the multi-signature case, we could say something like: "If there are multiple signatures and/or MACs over the payload, then at least one "alg" value must be supported and have an associated key as described above, or the JWS must be rejected".  Does that describe the semantics you had in mind?  What does CMS do in this case?



[JLS] CMS is silent on the topic.  There are applications that say that all signatures must validate and some that say that any signature can validate.  It depends on the application.  If it said anything it would say that the current signature would fail to validate and would say nothing about the state of the JWS object.



Mike> I changed the text from "the algorithm" to "an algorithm".  I'll wait for working group discussion on the text about rejecting objects when all the signature don't validate before making any changes in that regard.



7.  In section 4.1.2 - Are you going to impose a minimum version TLS - specifically are SSL and TLS v1.0 allowed?



Mike> I propose that we add this security considerations subsection, which is derived from that used in OAuth.  (This language resulted from the resolution of a DISCUSS, if I recall correctly.)



TLS Requirements



Implementations MUST support TLS. Which version(s) ought to be implemented will vary over time, and depend on the widespread deployment and known security vulnerabilities at the time of implementation. At the time of this writing, TLS version 1.2 [RFC5246] is the most recent version, but has very limited actual deployment, and might not be readily available in implementation toolkits. TLS version 1.0 [RFC2246] is the most widely deployed version, and will give the broadest interoperability.



To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a ciphersuite that provides confidentiality and integrity protection.



Whenever TLS is used, a TLS server certificate check MUST be performed, per RFC 6125 [RFC6125].



[JLS] while the text makes sense, it does not address the question I asked.



Mike> The text above is the best that the OAuth working group came up with.  I realize that it doesn't directly answer your question.  What do others think?



8.  In section 4.1.2 - Is implementation of this parameter required?



Mike> Only in the sense described in the second paragraph of section 4:  "All other header parameters defined by this specification that are not so designated MUST be ignored when not understood."  This was part of the "MUST understand" resolution proposed by Eric Rescorla, Nat Sakimura, and others and confirmed by the working group.  Incomplete implementations are OK - just not fully functional.



[JLS] In that case is there any reason why I should not be able to put these items into a crit?  That is to say if you don't support this then you fail validation on this signature.



Mike> Doing so wouldn't actually add any value.  The JWS validation will fail anyway if you don't support the necessary parameters.  Having it fail for "crit" reasons would just be redundant, and would complicate "crit" implementations.



9.  In section 4.1.3 - see comment 8



Mike> Same answer as 8



11.  In section 4.1.4 - Other than consistency - what is the requirement here for doing HTTPS - are you expecting self-signed certificates to be common and trying to get around trust anchor issues?



Mike> Yes



[JLS] Then you need to say so.



Mike> I'm not sure what to say in this regard that would actually add value.  For instance, we could say that "The nature of the trust decision for the certificate is beyond the scope of this specification", but I'm not sure how useful that would be.



12. In section 4.1.4 - see comment 8  -- ok - and lots of other sections



Mike> Same answer as 8



14. In section 4.1.9 - This section gives why I thought that JWT was a cty value.  It explicitly says so.  Mike has said this is not true.



Mike> I can see why the example is misleading.  "cty": "JWT" is only used when the JWT representation signs or encrypts another JWT in a nested fashion - not when a set of claims are directly signed or encrypted.  I'll remove it (and clarify the intent of "cty" and "typ" using language supplied by Richard).



15.  In section 4.1.9 - The last paragraph states that ctyp and typ values come from the same values space.  Mike has said this is not true.



Mike> It is true.  If it appeared that I contradicted this, I misspoke or was misunderstood.



[JLS] Ok - so now I have a question about what happens if the same value is used in both a typ and a ctyp field.  They may have different meanings in this case.  How is this clarified - please find the message that I mailed to the list earlier on this issue and respond to it.  Also please look at your prior responses to see if they need to be clarified.



16. In section 4.1.10 - I think there is an interesting discussion point on the use of 'crit' in the following case.  I want to ensure that you implement a feature in the base specification that the base specification has said you do not need to implement.  I am not sure based on the current document language if this is an empty set or not.



Mike> There's a distinction that Eric Rescorla made when designing the "MUST understand" solution between fields that would result in security bugs if not fully supported versus fields that would result in the inability to process the content if not supported.  For instance, the key selection fields are in the latter category.  If someone doesn't support "x5t" you might not know what certificate to use and so you couldn't process the JWS, but that would just be functionality deficiency - not a security bug.  "crit" is there to be able to dynamically designate new fields as being in the former category.



[JLS] You might not support x5t and still be able to guess what the certificate is based on it happened to work.  But it might be the wrong certificate.  That would be a security bug.



Mike> The chance of the wrong certificate working is, by definition, so small as to be negligible.  That's the whole premise of why we're able to use crypto to do the things we do with it.



17.  In section 5.1 step 3 - I don't know if there is a reason to make a statement about suggesting that whitespace be removed when you are planning on doing a compact representation.  This is one of those things that would lead to a smaller encoding.



Mike> The statement is that whitespace is permitted and no canonicalization need be performed.  It doesn't say that you can't remove whitespace or perform canonicalization if you choose.



[JLS] there is a big difference between suggesting something be done in practice and requiring it.  If you want to say that size matters then you should be consistent about it.  I think that as a good practice the suggestion makes sense.



Mike> I'm confused by your statement.  We're not requiring that any whitespace be present in the input.



18.  In section 5.1, step 4 - the phrase "If the JWS protected header is not present..." leaves me lost.  I don't understand what this term is coming from as you have not yet introduced it in terms of how to build a signed message.  Specifically, there has been nothing at this point which tells me how to decide what goes where.  I strongly feel that section 8 needs to move before this section.



Mike> The JWS Protected Header was already defined in the Terminology section.  We could make this more explicit by saying that the base64url encoding of the JWS Protected Header is the value of the "protected" member in the JSON Serialization, if present.



Mike>  This is now clarified inline by saying "which can only happen when using the JWS JSON Serialization and no "protected" member is present".



19.  In section 5.1, Step 11 - I think this should be moved forward to say - repeat the steps X to Y for each signature to be processed.  I also don't think this needs to say anything about the serialization method being used.

It is not relevant.



Mike> I will add the language about "steps X to Y" as you suggest.  Saying that this only applies for the JSON Serialization is important, since this step is inapplicable to the Compact Serialization.



[JLS] No,, the important thing to say for compact serialization is that in that section it needs to say that you can only have one signer - that is not the same as saying it is needed here.



Mike> Rereading the text, it's not clear that adding the "steps X to Y" language would actually clarify things, so I've left it out for now.  We can continue to iterate on better language for this.



21. In section 5.1, step 9 - I believe that the compact serialization should be moved to its own section.  There should not be any apparent preference in the document for one of the serialization methods.



Mike> I will create a Compact Serialization section paralleling the JSON Serialization section, but I disagree about removing the concatenation language here.  One of the beautiful things about the Compact Serialization is that it *can* be described in a single sentence, as is step 9.  It will be easier for most developers to continue having this single sentence in-line, rather than making them jump to another section when a single sentence in place already does the job nicely.



[JLS] again - that is a good optimization to put into the section on compact serialization.  Otherwise it is getting in the way of reading and understanding this section.



Mike> I've created a parallel Compact Serialization section.



22. In Section 5 - I am going to make a suggestion that I would like you to consider, although I think that it might not be to your liking.  My personal view of the world has been one of: There is a JSON serialization that is the object.  There is a way to map from the JSON serialization to the compact serialization.  The mapping requires a set of constraints on the original serialization.  Thus in my world, I build the internal JSON object representation, run the computations on that internal representation and then either run the mapping to the compact serialization or serialize the JSON object representation to get the output.  Using this as the method would mean that section 5 would be an object representation for JSON, section 6 would be how to do the mappings to and from the compact form, section 7 would be the how to do this.



Mike> What you're doing is functionally equivalent to what's in the spec now, but pretty inefficient and unnecessary if you're only using the Compact Serialization, which will be a common model for many use cases.  I think a better model is that the Compact Serialization and JSON Serialization are peers - sharing 95%+ of the processing rules and then applying a particular serialization for the data values manipulated by those processing rules.  That's why the specs describe things in terms of abstract fields and bindings of those fields to elements of serializations - rather than describing things only in terms of the serialized representations.



[JLS] Neither of us can make a statement about which is going to be the most implemented version.  Indeed if the mandatories are changed then you are wrong and they would both be equally implemented.  I think that making things clear is always better and I don't think the current text is very clear at all.



23.  In section 5.3 - Are steps #1 and #2 not the requirement of the JSON parser and not my application?  I would suggest reading some of the updated text on member name string comparison from the JSON mailing list for a cleaner way to write this section.



Mike> Specific text suggestions welcomed.



25.  Section 7 would appear to be better served by making it section 4.1.2 and making section on jku, jwk, x5u, x5t, x5c and kid as subjections of it.



Mike> The problem with this suggestion is that it would make the list of reserved header parameters no longer syntactically parallel.  And I do believe there's value in having a paragraph that talks about the semantics of key identification all-up, rather than trying to do it in a manner that's scattered in bits and pieces into the individual parameter definitions.



[JLS} I don't think that this changes the syntax of the output in anyway shape or form.  I think it makes the fact that these things are common and apply to the sub sections clear and does not interfere with reading the document in any way.



Mike> No, it would change the syntax of the Reserved Header Parameters section to no longer be parallel.



26.  Section 8 - I found the presentation confusing.  I would have expected that it would be made in the normal manner - that is you have an object and a list of members each with its own section - and those members may have sub members which are listed.  There would then be references back to the members defined in section 4



Mike> I agree that an object-centered approach will be easier to follow.  Thanks for suggesting it.  Some of that content is now in prose.  I'll restructure to use lists/tables instead as you suggest.



Mike> I will take a stab at this in the next version.  I'm going to publish without this restructuring in the interest of getting the specs out in time to review before the call.



27.  Section 9 - I would dispute the content of this section vigorously.


Mike> Hannes and Derek and Stephen and Sean, at least to the OAuth WG, have made it VERY CLEAR that the IESG requires MTI features to be defined.  Of the JSON and Compact serializations, the latter is the only one in widespread use, therefore it makes sense for it to be the MTI serialization.  Particularly since JWTs mandate that only the Compact Serialization be used, it would make no sense from a working group coordination point of view to try to mandate that the JSON serialization also be MTI - especially since it's more complicated.

[JLS} Great - the mandatory to implement is now the JSON serialization with one signer as well as the compact serialization.



Mike> Again, the JSON Serialization is unnecessary for JWT and many other JOSE applications, and so should not be MTI.



I stopped reviewing after section 9.



Mike> Thanks for all the useful comments.



                                                            -- Mike

Jim





_______________________________________________

jose mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/jose