Hello Mike & JOSE members, I am working my way through the requested reviews to progress the JOSE drafts and can see a lot of work has been done, thank you. As I read through the Algorithms (JWA) draft there are some changes that will need to be made to avoid problems during the IESG review. This is a pretty big change for the draft, but will help make the review and approval faster. Typically, the lists of algorithms are handled through a draft update as opposed to creating an IANA registry. A good example is a recent update of a draft in the IPSECME working group so you can see the structure and the precedence for this model.
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts Now for other edits and questions: Section 3.6 - Can you explain why would this be included? If you are not going to sign, I am not sure why one would use JOSE at all. Section 5.2 - The write up of this section seems a bit more complicated than necessary. It seems it would have just been simpler to state that the sizes vary as required by the algorithms and key lengths used rather than providing the differences from one to the next. Can you simplify this? After looking through some of the mailing list discussions, it seems there was already agreement to slim this and other sections down by pointing to the draft-mcgrew-aead-aes-cbc-hmac-sha2 http://www.ietf.org/mail-archive/web/jose/current/msg02276.html Can I get an update as to where that stands, referencing what you can from that draft as opposed to duplicating text? Thanks! Security Considerations: While it is true the content is covered in other places, this section could benefit from improvement before it goes to the SecDir review. The second sentence in the first paragraph says the following: Among these issues are protecting the user's private and symmetric keys, preventing various attacks, and helping the user avoid mistakes such as inadvertently encrypting a message for the wrong recipient. It would be helpful if you could expand the text and make it more descriptive and applicable to this document. For example, shouldn’t the first section say user’s private asymmetric and symmetric keys? I assume that is what was intended with private, but it reads funny to me without that. The only ‘attack’ or caution mentioned in the document is for the application to prevent a user from selecting the wrong key. Please include some attacks that developers and implementers should be aware and cautioned on, or state that specific attacks and considers are detailed in the subsections to follow. I think that's it for now. Although I do need to look through some more of the previous conversations on the mailing list and in the issue tracker. I see there are some open discussions, like the one Richard raised yesterday that need to be resolved in the document as well before we move forward with this one. Thanks for all of your effort on this draft!! -- Best regards, Kathleen
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
