Thank you, Karen. 'They' below should have said the chairs.
Thanks, Kathleen Sent from my iPhone > On May 2, 2014, at 9:54 AM, Karen ODonoghue <[email protected]> wrote: > > Kathleen, > > I will add some text to the tracker to make this clearer. My apologies for > the confusion. Thanks for your efforts. I know there is a pile of stuff to > plow through... > > Regards, > Karen > >> On 5/2/14 10:18 AM, Kathleen Moriarty wrote: >> Thanks for the detailed response and all of your efforts on this draft. >> >> I need to backtrack on the statement I made about the WG decision on >> consensus for alg none. They both have informed me that there was >> consensus, not just agreement to keep it in for implementations. Could this >> be more explicit in the issue tracker or on the list by the chairs so I have >> something to point to if it comes up in last call? >> >> I am traveling today, so I don't have time to search for links on the >> equivalent for 'thumbprints' in XML. They refer to this as a fingerprint >> and it was implemented in the XML oxygen editor used for certificates. This >> may help in case folks are interested and have some time to look into it. >> >> Thank you, >> Kathleen >> >> Sent from my iPhone >> >>> On May 1, 2014, at 1:10 PM, Mike Jones <[email protected]> wrote: >>> >>> Yes, I realize that I haven't revised the security considerations yet. I >>> started to do it and realized that it was a more intricate exercise than >>> I'd originally anticipated, so decided to get the -26 drafts out with the >>> easy stuff first, for working group review. These mostly address comments >>> by you, Scott, Hannes Tschofenig (which was actually a comment on JWT, but >>> that applied to JOSE as well), and Antonio Sanso. >>> >>> WORKING GROUP: I would appreciate any specific suggestions on additions >>> that you'd like to have made to the security considerations section at >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#section-8. >>> >>> I also realize that I still need to write the note to David McGrew. >>> >>> Kathleen, can you point us to the XML equivalents of certificate >>> thumbprints that you used? That could be interesting. FYI, I also >>> submitted an individual -00 JSON thumbprint draft last month at >>> http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-00 (because the >>> need for a JSON-based thumbprint came up in practice), but I'm not >>> proposing that we try to jam it into JWS at this point. It's fine for that >>> to be work after a recharter, should the WG want to take it up. >>> >>> Best wishes, >>> -- Mike >>> >>> -----Original Message----- >>> From: Kathleen Moriarty [mailto:[email protected]] >>> Sent: Thursday, May 01, 2014 10:47 AM >>> To: Mike Jones >>> Cc: [email protected] >>> Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms >>> >>> Hi Mike, >>> >>> Thanks for posting the updated draft. At a minimum, the security >>> considerations update still needs to be updated. I'd like an okay from >>> Jim, the document shepherd when he thinks this is all ready in case I am >>> missing any other open issues. The rest is in-line as this seems to >>> summarize all of the issues and there were discussions in other threads >>> that I would prefer to not see them get lost. >>> >>>> On Thu, May 1, 2014 at 3:09 AM, Mike Jones <[email protected]> >>>> wrote: >>>> The algorithm name “RSA-OAEP-256” for RSAES OAEP using SHA-256 and >>>> MGF1 with >>>> SHA-256 has been added at >>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#sect >>>> ion-4.3, >>>> per your request, Kathleen. >>>> >>>> >>>> >>>> >>>> -- Mike >>>> >>>> >>>> >>>> From: jose [mailto:[email protected]] On Behalf Of Mike Jones >>>> Sent: Friday, April 25, 2014 6:38 PM >>>> >>>> >>>> To: Kathleen Moriarty; Jim Schaad >>>> Cc: [email protected]; [email protected] >>>> >>>> Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms >>>> >>>> >>>> >>>> Thanks, Kathleen. Comments are inline, marked “Mike>”… >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: jose [mailto:[email protected]] On Behalf Of Kathleen >>>> Moriarty >>>> Sent: Friday, April 25, 2014 2:07 PM >>>> To: Jim Schaad >>>> Cc: Mike Jones; [email protected]; >>>> [email protected] >>>> Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms >>>> >>>> >>>> >>>> Sorry for the delay in my response. I'll answer in-line below. >>>> >>>> >>>> >>>> Thanks! >>>> >>>> >>>> >>>>> On Thu, Apr 17, 2014 at 5:20 PM, Jim Schaad <[email protected]> >>>>> wrote: >>>> >>>> >>>> >>>>> From: jose [mailto:[email protected]] On Behalf Of Mike Jones >>>>> Sent: Thursday, April 17, 2014 10:46 AM >>>>> To: Kathleen Moriarty; [email protected] >>>>> Cc: [email protected] >>>>> Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms >>>> >>>> >>>> >>>>> Thanks for taking the time to do the review, Kathleen. Responses are >>>>> inline, flagged by “Mike>”. I also pasted your follow-on note in and >>>>> responded to it as well. >>>> >>>> >>>> >>>>> From: Kathleen Moriarty [mailto:[email protected]] >>>>> Sent: Thursday, April 17, 2014 7:51 AM >>>>> To: [email protected] >>>>> Cc: Mike Jones; [email protected] >>>>> Subject: AD review of draft-ietf-jose-json-web-algorithms >>>> >>>> >>>> >>>>> 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 >>>> >>>> >>>> >>>>> Mike> So you’re suggesting that future JWA drafts might obsolete the >>>>> Mike> current >>>>> one, much like draft-ietf-ipsecme-esp-ah-reqts will obsolete RFC >>>>> 4835, >>>>> which obsoleted RFC 4305, etc.? If so, could work on revising the >>>>> JWA >>>>> draft accordingly and send proposed changes to the working group. >>>> >>>> >>>> KM> I am not sure where Jim's response is, but I have been looking >>>> >>>> into this. My initial message came after some conversations with >>>> Sean. In response to your posts, I reached out to a couple of other >>>> ADs who may have had concerns and *think* we are okay as long as the >>>> registries will be used with a designated expert review to add to the >>>> registry. If a draft is required for an update, that would cause >>>> problems as opposed to a draft with no registries. Sorry for the >>>> confusion here. >>>> >>>> >>>> >>>> Mike> Jim’s response is at >>>> http://www.ietf.org/mail-archive/web/jose/current/msg04071.html, >>>> starting with “[JLS] Kathleen, I don’t know that I agree with this >>>> statement. There are a number of different places where IANA >>>> registries are used for the purpose of having lists of algorithms.” >>>> All the registries established already require expert review, as >>>> described at >>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25#section-7. >>>> So it sounds like we should be OK. That’s good. Thanks for working >>>> the issue. >>>> >>>> >>>> >>>> >>>>> 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. >>>> >>>> >>>> >>>>> Mike> This is included to enable representing content that is >>>>> Mike> optionally >>>>> signed in protocols using JWS. Having this means that whether or not >>>>> the content is signed, it can use a uniform representation, which is >>>>> easy to parse. This is in production use, for instance, to enable >>>>> OAuth authorization request messages that are optionally signed. >>>>> Sometimes content need not be signed at the JWS level because it’s >>>>> integrity protected by other protocol layers – in particular, often >>>>> by >>>>> the use of TLS. Another use case is where signing adds additional >>>>> optional value, but where there’s no harm in using unsigned content – >>>>> for instance, while normal OAuth requests are inline and unsigned, a >>>>> registered extension enables request parameters to be passed by >>>>> reference, rather than by value; the object referenced containing the >>>>> parameters is a JWS; the JWS can optionally be signed. The current, >>>>> carefully refined treatment of “none” is the result of substantial >>>>> mailing list discussions and discussions on working group calls. >>>>> While a less parallel treatment of unsigned JWSs was proposed in >>>>> http://trac.tools.ietf.org/wg/jose/trac/ticket/36, this alternative >>>>> syntax was rejected by the working group in favor of the current approach. >>>> >>>> >>>> KM> I responded to Vladamir on this one and would just like to know if >>>> >>>> there is WG consensus behind the decision. Can you point me to >>>> discussions on this? >>>> >>>> >>>> >>>> Mike> Brian Campbell did a good job summarizing the consensus in his >>>> Mike> note >>>> http://www.ietf.org/mail-archive/web/jose/current/msg04082.html. Jim >>>> Schaad documented the consensus in his note closing issue #36 at the >>>> end of http://trac.tools.ietf.org/wg/jose/trac/ticket/36. >>>> >>>> >>>> >>>> Mike> This was extensively discussed on a thread titled “[jose] #36: >>>> Algorithm "none" should be removed” between 7/31/13 and 8/22/13 and >>>> then also on a follow-up thread named “[jose] Text about applications >>>> and "alg":"none"” between 9/3/13 and 9/9/13. The latter thread >>>> resulted from an action items from the preceding interim working group >>>> call (the agenda for which was published at >>>> http://www.ietf.org/proceedings/interim/2013/08/19/jose/agenda/agenda-interim-2013-jose-5). >>>> >>>> >>>> >>>> Mike> The text agreed to by the working group that Brian referred to >>>> Mike> was >>>> added in draft-ietf-jose-json-web-algorithms-16, published on 9/15/13. >>>> Jim closed the issue on 10/28/13. >>> My read of the threads and issue tracker was that implementations won out >>> to close this discussion, but that there was no consensus. There were many >>> involved in the discussion that provided arguments and support for not >>> including alg none. I'll support this as a WG decision based on >>> implementations, as that's how I read it. I appreciate all of the feedback >>> on actual use of this as it will be helpful in case this comes up during >>> last call. >>> >>>> >>>> >>>>> 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! >>>> >>>>> Mike> Sure. The key part of the message you cited is “Once the >>>>> Mike> McGrew >>>>> Mike> draft >>>>> has been refactored to separate the description of the calculation >>>>> steps (which JOSE is using) from the AEAD representation steps (which >>>>> JOSE is not using), and to include test vector values that show >>>>> results without performing the AEAD representation concatenations, I >>>>> agree that we'll be able to just reference it, rather than >>>>> duplicating >>>>> it.” The problem is that the refactoring was never done. The >>>>> algorithm description in >>>>> draft-mcgrew-aead-aes-cbc-hmac-sha2 is written in such a way that the >>>>> ciphertext C, as described, also includes the IV value as a prefix >>>>> and >>>>> the authentication tag T as a suffix, rather than treating each of >>>>> those as separate values. The test vectors do the same. Yes, David >>>>> added appendix B saying that the values could be treated as separate, >>>>> but the write-up does no favors to implementers, as both the core >>>>> algorithm description and the test vectors assume they are combined. >>>>> (I personally know that working out how to treat them as separate >>>>> from >>>>> David’s current draft is a tedious and error-prone exercise, having >>>>> had to do so to tease them apart for the current JWA write-up.) >>>>> David >>>>> has been asked about doing the refactoring several times by multiple >>>>> parties, but he’s a busy guy, and I don’t think it’s ever reached the >>>>> top of his queue. As it is, the JWA description is clear and >>>>> semantically equivalent and implementers have shown that they can >>>>> successfully build it. Finally, we wouldn’t want to take a normative >>>>> dependency upon a draft that appears to have been largely abandoned >>>>> (or at least neglected), as doing so could indefinitely stall >>>>> publication of RFC versions of the JOSE specs. >>>> >>>> >>>> >>>>> [JLS] I always considered this to be a sufficient refactoring to use >>>>> the mcgrew draft as a basis. I did not have the same type of >>>>> problems >>>>> with breaking the test vectors apart that you seem to have had. >>>> >>>> >>>> >>>> KM> OK, has anyone reached out to Dave McGrew to discuss? How can we >>>> >>>> clear this up? >>>> >>>> >>>> >>>> Mike> I’d had in-person and phone conversations with him about it last >>>> Mike> year, >>>> but not much happened as a result. >>>> >>>> >>>> >>>> Mike> I wrote more about your question at >>>> http://www.ietf.org/mail-archive/web/jose/current/msg04074.html in >>>> which I pointed out errors and sources of confusion in David’s draft >>>> that would complicate life for developers and possibly result in >>>> incorrect implementations; Jim responded at >>>> http://www.ietf.org/mail-archive/web/jose/current/msg04075.html. I’ll >>>> send a note to David pointing these out and offering to produce >>>> proposed changes for him to incorporate, but unless he either decides >>>> to devote bandwidth to advancing the draft (it’s already expired once) >>>> or is willing to delegate it to us to do so, I think we don’t have >>>> much choice but to continue to have a complete and accurate >>>> description of the algorithms in the JWA doc, and let his draft >>>> advance at its own pace. I’ll note that we also don’t have a >>>> publication vehicle for the draft to become an RFC, because it’s not in >>>> any working group, nor does it have AD sponsorship that I’m aware of. >>> Thank you, please keep us posted on the status/progress so we know how to >>> move forward. >>> >>>> >>>> >>>>> 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! >>>> KM> Great, thank you! >>>> >>>> >>>>> 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!! >>>> >>>> >>>> >>>>> Mike> Per my note >>>>> http://www.ietf.org/mail-archive/web/jose/current/msg04061.html, I >>>>> don’t believe that that particular issue is open. It had been >>>>> extensively discussed within the working group multiple times and the >>>>> issue was explicitly closed by the chairs, leaving the status quo in >>>>> place in which there are required algorithms for interoperability reasons. >>>> >>>> >>>> >>>>> 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 >>>> >>>> >>>> >>>>> Mike> If adding a new “RSA-OAEP-256” algorithm identifier for “RSAES >>>>> Mike> with >>>>> Optimal Asymmetric Encryption Padding using the MGF1 mask generation >>>>> function and the SHA-256 hash function” would make a number of people >>>>> more comfortable, including you, there’s nothing wrong with doing so. >>>>> However, it’s also not clear that it would be of much short-term >>>>> practical benefit because, at least as of the implementation survey >>>>> done in July 2012, many crypto libraries don’t expose a way to get at >>>>> this algorithm combination. >>>>> However, the same argument could be made about RSASSA-PSS, which we >>>>> did add identifiers for in the end. In short, I don’t think anyone >>>>> in >>>>> the working group would stridently object if you asked for this >>>>> additional algorithm identifier to be added. Your call… >>>> >>>> KM> I'd say to add it. I'll have a similar comment for the JWS draft >>>> >>>> for SHA256 support on thumbprints. >>>> >>>> >>>> >>>> Mike> OK – I’ll add it. >>> Thanks, and I see Scott's review and okay as well, which is helpful. >>>> >>>> Mike> Per your JWS comment, SHA-1 thumbprints are widely deployed. >>>> Mike> I’m >>>> aware of no SHA-256 certificate thumbprint deployments. I’ll note >>>> that even if SHA-1 were completely broken, that wouldn’t be a security >>>> issue because it’s just being used to generate a digest of publicly >>>> available certificate information. It’s not being used to >>>> cryptographically obscure anything. >>>> (But that’s actually a discussion for another draft. J) >>> This is in place for the XML equivalents and should be possible for JSON. >>> I used this at least 2 years ago in the XML Oxygen editor. I believe this >>> has been brought up before in terms of JSON, so I am not the first. But it >>> is another draft... I'd like to get through these all soon :-) >>> >>>> >>>> >>>> >>>>> -- >>>> >>>> >>>> >>>>> Best regards, >>>> >>>>> Kathleen >>>> >>>> >>>> >>>>> Thanks a >>>>> bunch, >>>> >>>>> -- Mike >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> Best regards, >>>> >>>> Kathleen >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> jose mailing list >>>> >>>> [email protected] >>>> >>>> https://www.ietf.org/mailman/listinfo/jose >>>> >>>> >>>> >>>> Thanks >>>> again, >>>> >>>> -- >>>> Mike >>> Thanks for your help!! >>> >>> -- >>> >>> Best regards, >>> Kathleen >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
