I'm going to add one more question to the review as I had the same thought as Scott & Burt in their review of JWA (and also in JWS). Why are there no other options in addition to SHA1? The response to Scott pointed back to early WG decisions, but I have heard this concern from others and have it myself, so I am not sure this one is resolved. I'd like to revisit it.
http://www.ietf.org/mail-archive/web/jose/current/msg04020.html Thanks! On Thu, Apr 17, 2014 at 10:50 AM, Kathleen Moriarty < [email protected]> wrote: > 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 > -- Best regards, Kathleen
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
