From: Mike Jones [mailto:[email protected]] Sent: Thursday, June 27, 2013 3:48 PM To: Jim Schaad; [email protected] Cc: [email protected] 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: [email protected] [mailto:[email protected]] On Behalf Of Jim Schaad Sent: Saturday, June 15, 2013 1:14 PM To: [email protected] Cc: [email protected] 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. 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. 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)" 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. I stopped reviewing after section 9. Mike> Thanks for all the useful comments. -- Mike Jim _______________________________________________ jose mailing list <mailto:[email protected]> [email protected] <https://www.ietf.org/mailman/listinfo/jose> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
