I'm good with your explanation. Once you review and edits to fit the described model, let me know.
Thanks, Kathleen Sent from my iPhone > On Jun 16, 2014, at 6:05 PM, Mike Jones <[email protected]> wrote: > > Mike> Just one answer to a question that you asked is inline below. I agree > with all the proposed resolutions described. > > From: Kathleen Moriarty [mailto:[email protected]] > Sent: Monday, June 16, 2014 2:51 PM > To: Mike Jones > Cc: [email protected] > Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms > > Thanks, Mike. Answers in-line. > > > On Mon, Jun 16, 2014 at 5:32 PM, Mike Jones <[email protected]> > wrote: > Mike> Thanks. Responses inline… > > From: Kathleen Moriarty [mailto:[email protected]] > Sent: Monday, June 16, 2014 2:10 PM > > To: Mike Jones > Cc: [email protected] > Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms > > > > > On Fri, Jun 13, 2014 at 6:15 PM, Mike Jones <[email protected]> > wrote: > Responses to the Security Considerations wording issue are inline below (with > the text unrelated to this issue removed for brevity)… > Thanks! > > From: Kathleen Moriarty [mailto:[email protected]] > Sent: Friday, June 13, 2014 2:08 PM > > To: Mike Jones > Cc: [email protected] > Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms > > On Fri, Jun 13, 2014 at 4:26 PM, Mike Jones <[email protected]> > wrote: > I didn’t reword the introductions. I thought that your issue was that you > wanted additional security considerations to be described, which has now been > done. I’ll go back and re-read your comments and see if I can work out what > additional changes you were requesting there. > > Thank you, when you go back you'll see the request was two-fold. Thanks, I > think it will help the intro read better! > > >> 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. > >> > >> Mike> OK, I can work on expanding that. There are some other attacks > >> mentioned in the other drafts, such as timing attacks, which can > >> probably at least be mentioned here. I’ll send draft text to the > >> list > >> and consult with you before doing anything to the actual drafts. > >> Specific suggestions from working group participants would also be > >> highly appreciated. > > The Security Considerations section requires updating, let me know when this > has been done. Thanks! > > Mike> The current introduction to all the JOSE security considerations > sections says: > > All of the security issues faced by any cryptographic application > must be faced by a JWS/JWE/JWK agent. 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. The entire list of > security considerations is beyond the scope of this document, but > some significant considerations are listed here. > > (And the JWT Security Considerations introduction is the same, other than > also speaking about JWTs.) > > Now that the -27 drafts contain beefed-up text describing specific security > considerations apropos to each draft, I believe that the best way to address > the other part of your two-fold comment is simply to delete the second > sentence (beginning “Among these issues”). I agree with you that it doesn’t > add any value at this point. > > Do you agree with that proposed resolution, Kathleen? > > I can go either way, but think adding in the word asymmetric would be good. > It reads a little funny without it and I know it should be obvious that it is > intended, but... we have a broad set of folks who read drafts. > > Mike> OK, I can change “user’s private and symmetric keys” to “user’s > asymmetric private and symmetric secret keys” so that the wording is > parallel. Would that work for you in the introductions? > > Yes, thanks! > > I read through the updated version in JWA and am wondering why the > considerations for [JWE], [JWK], [JWS], are included here? Isn't it that the > other documents rely on JWA and not the reverse? > > Mike> There’s a balancing act caused by the fact that the specific algorithms > for JWS, JWE, and JWK are in the JWA spec. Where the consideration is > specific to a particular algorithm, I tried to put it in the JWA spec. > In principle, I agree. If the consideration is about the algorithm, it > should be in JWA. I suspect JWA will get used by many other drafts that may > or may not use the other JOSE drafts. Or will there be cases where other > working groups would only reference these algorithms with other JOSE work? > Is there a chance some other draft may need the combinations created for the > other JOSE drafts without the need for those drafts? (I can be convinced > here, but this will likely come up in last call as people read the set, so > well need a good answer on approach.) > > Mike> The one case I’m aware of that already exists where a spec is > referencing the JWA spec without all the other JOSE specs is the W3C Web > Cryptography API (http://www.w3.org/TR/WebCryptoAPI/). It is using JWKs but > also includes an algorithm cross-reference table to other JWA-defined > algorithm identifiers at http://www.w3.org/TR/WebCryptoAPI/#jwk-mapping-alg > (because they’re used in the JWK “alg” field). > > That being said, I don’t think that this use of the JOSE specs alters the > proposed logic about where security considerations for algorithms and > operations should be placed. > Where it is broader (more about signing, encrypting, or keys than about the > particular algorithm), I tried to put it in the JWS, JWE, or JWK spec. In > some cases, a consideration seemed applicable to both, in which case I put it > in the JWS, JWE, or JWK spec and referenced it from the JWA spec. > Great. > > It’s also entirely possible that I haven’t been completely consistent with > the above approach, so further review of the placements is probably in order. > But first, I’d like to know if you agree with the principles about where > things should be located that I described in the previous paragraph, or if > you’d like to see things be organized differently. After I hear back from > you on that, I’ll undertake the review to see if any of the considerations > should move between specs, for consistency sake. > Yes, in principle, thanks! > > Thanks, > Kathleen > > We are getting close :-) > > Mike> Agreed :-) > > Thanks, > Kathleen > > Best regards, > Kathleen > > Have a good > weekend! > -- Mike > > > > > -- > > Best regards, > Kathleen > > -- Mike > > > > -- > > Best regards, > Kathleen > > -- Mike
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
