Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms

From: Mike Jones <[email-masked]>
Date: Wed, 11 Jun 2014 07:19:12 +0000

Hi Kathleen,

I believe that the -27 drafts address all your outstanding comments on JWA, other than the following:

·        Simplify presentation of CBC-HMAC algorithms.  Status - there is a back-channel discussion ongoing with David McGrew and his co-authors about the possibility of updating draft-mcgrew-aead-aes-cbc-hmac-sha2 in a way that would remove inconsistencies in the current draft and meet JOSE’s needs.

                                                            -- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Thursday, May 01, 2014 11:10 AM
To: Kathleen Moriarty
Cc: [email-masked]
Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms

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-masked]]

Sent: Thursday, May 01, 2014 10:47 AM

To: Mike Jones

Cc: [email-masked]<mailto:[email-masked]>

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-masked]<mailto:[email-masked]>> 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-masked]] On Behalf Of Mike Jones

> Sent: Friday, April 25, 2014 6:38 PM

> To: Kathleen Moriarty; Jim Schaad

> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> 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-masked]] On Behalf Of Kathleen

> Moriarty

> Sent: Friday, April 25, 2014 2:07 PM

> To: Jim Schaad

> Cc: Mike Jones; [email-masked]<mailto:[email-masked]>;

> [email-masked]<mailto:[email-masked]>

> 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-masked]<mailto:[email-masked]>> wrote:

>> From: jose [mailto:[email-masked]] On Behalf Of Mike Jones

>> Sent: Thursday, April 17, 2014 10:46 AM

>> To: Kathleen Moriarty; [email-masked]<mailto:[email-masked]>

>> Cc: [email-masked]<mailto:[email-masked]>

>> 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-masked]]

>> Sent: Thursday, April 17, 2014 7:51 AM

>> To: [email-masked]<mailto:[email-masked]>

>> Cc: Mike Jones; [email-masked]<mailto:[email-masked]>

>> 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-masked]<mailto:[email-masked]>

> https://www.ietf.org/mailman/listinfo/jose

>                                                                 Thanks

> again,

>                                                                 --

> Mike

Thanks for your help!!

--

Best regards,

Kathleen

_______________________________________________

jose mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/jose

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 13 Jun 2014 16:21:19 -0400

Hi Mike,

I just took a quick look and need to check more carefully, but it appears
rewording of the intro to the Security Considerations has not occurred yet.
 WIll that be in the next iteration?  I did list some specific concerns
that should be easy to fix.

I think we are waiting on 2 items then, correct?  I'll read through to
confirm.  Thank you for your effort on the draft updates!

On Wed, Jun 11, 2014 at 3:19 AM, Mike Jones <[email-masked]>
wrote:

> ·        Simplify presentation of CBC-HMAC algorithms.  Status - there is
> a back-channel discussion ongoing with David McGrew and his co-authors
> about the possibility of updating draft-mcgrew-aead-aes-cbc-hmac-sha2 in a
> way that would remove inconsistencies in the current draft and meet JOSE’s
> needs.
>
>
>
>                                                             -- Mike
>
>
>
> 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
> .
>
>
>
> 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
>
>
>
> From: Kathleen Moriarty [mailto:[email-masked]
> <[email-masked]>]
>
> 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-masked]>
> wrote:
>
> > From: jose [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Mike Jones
>
> > Cc: [email-masked]; [email-masked]
>
> >
>
> > From: jose [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Kathleen
>
> > Moriarty
>
> > Cc: Mike Jones; [email-masked];
>
> > [email-masked]
>
> > On Thu, Apr 17, 2014 at 5:20 PM, Jim Schaad <[email-masked]>
> wrote:
>
> >
>
> >>
>
> >
>
> >>
>
> >
>
> >>
>
> >
>
> >>
>
> >
>
> >> From: jose [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Mike Jones
>
> >
>
> >> To: Kathleen Moriarty; [email-masked]
>
> >
>
> >> Cc: [email-masked]
>
> >
>
> >> From: Kathleen Moriarty [mailto:[email-masked]
> <[email-masked]>]
>
> >
>
> >> To: [email-masked]
> >> Cc: Mike Jones; [email-masked]
>
> >
>
> > described at
> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25#section-7
> .
>
> 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.
>
>
>
> >
>
> >
>
> >>
>
> >
>
> > 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.
>
> >
>
> >
>
>
>
> 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
>
> >
>
> >
>
> >
>
> > [email-masked]
> [email-masked]

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Fri, 13 Jun 2014 20:26:30 +0000

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.

FYI, I received a response from David McGrew saying that he thought he agreed on my suggestions for improving draft-mcgrew-aead-aes-cbc-hmac-sha2 and that he’d work on an updated draft on 6/16 and run it past me and his co-authors.

I assume that the two items you’re referring to that we’re waiting on are the introductions to the security considerations sections and the McGrew draft?

                                                            -- Mike

From: Kathleen Moriarty [mailto:[email-masked]]
Sent: Friday, June 13, 2014 1:21 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms

Hi Mike,

I just took a quick look and need to check more carefully, but it appears rewording of the intro to the Security Considerations has not occurred yet.  WIll that be in the next iteration?  I did list some specific concerns that should be easy to fix.

I think we are waiting on 2 items then, correct?  I'll read through to confirm.  Thank you for your effort on the draft updates!

On Wed, Jun 11, 2014 at 3:19 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kathleen,

•        Simplify presentation of CBC-HMAC algorithms.  Status - there is a back-channel discussion ongoing with David McGrew and his co-authors about the possibility of updating draft-mcgrew-aead-aes-cbc-hmac-sha2 in a way that would remove inconsistencies in the current draft and meet JOSE’s needs.

                                                            -- Mike

-----Original Message-----
From: jose [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mike Jones
Sent: Thursday, May 01, 2014 11:10 AM
To: Kathleen Moriarty
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms

                                                            Best wishes,

                                                            -- Mike

-----Original Message-----

To: Mike Jones

Hi Mike,

Thanks for your help!!

--

Best regards,

Kathleen

jose mailing list

--

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 13 Jun 2014 17:07:39 -0400

On Fri, Jun 13, 2014 at 4:26 PM, Mike Jones <[email-masked]>
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!

>
>
> FYI, I received a response from David McGrew saying that he thought he
> agreed on my suggestions for improving draft-mcgrew-aead-aes-cbc-hmac-sha2
> and that he’d work on an updated draft on 6/16 and run it past me and his
> co-authors.
>
Great, thanks for pushing on this!  It will be good to see this get
resolved.

>
>
> I assume that the two items you’re referring to that we’re waiting on are
> the introductions to the security considerations sections and the McGrew
> draft?
>
Yes, thanks!

Have a good weekend!
Kathleen

>
>
>                                                             -- Mike
>
>
>
> *From:* Kathleen Moriarty [mailto:[email-masked]]
> *Sent:* Friday, June 13, 2014 1:21 PM
>
> *To:* Mike Jones
> *Cc:* [email-masked]
> *Subject:* Re: [jose] AD review of draft-ietf-jose-json-web-algorithms
>
>
>
> Hi Mike,
>
>
>

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Fri, 13 Jun 2014 22:15:13 +0000

Responses to the Security Considerations wording issue are inline below (with the text unrelated to this issue removed for brevity)…

From: Kathleen Moriarty [mailto:[email-masked]]
Sent: Friday, June 13, 2014 2:08 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms

On Fri, Jun 13, 2014 at 4:26 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> 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!

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?

Best regards,
Kathleen

                                                            Have a good weekend!
                                                            -- Mike

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 16 Jun 2014 17:09:32 -0400

On Fri, Jun 13, 2014 at 6:15 PM, Mike Jones <[email-masked]>
wrote:

>  Responses to the Security Considerations wording issue are inline below
> (with the text unrelated to this issue removed for brevity)…
>
Thanks!

> *Sent:* Friday, June 13, 2014 2:08 PM
>
> *To:* Mike Jones
> *Cc:* [email-masked]
> 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!
>
>
>
> 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.
>
>
>

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.

I read through the updated version in JWA and am wondering why the
considerations for [JWE
<http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-27#ref-JWE>],
[JWK
<http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-27#ref-JWK>],
[JWS
<http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-27#ref-JWS>],
are included here?  Isn't it that the other documents rely on JWA and not
the reverse?

We are getting close :-)

Thanks,
Kathleen

>                                                             Have a good
> weekend!

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Mon, 16 Jun 2014 21:32:56 +0000

Mike> Thanks.  Responses inline…

From: Kathleen Moriarty [mailto:[email-masked]]
Sent: Monday, June 16, 2014 2:10 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms

On Fri, Jun 13, 2014 at 6:15 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>]
Sent: Friday, June 13, 2014 2:08 PM

To: Mike Jones

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?

I read through the updated version in JWA and am wondering why the considerations for [JWE<http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-27#ref-JWE>], [JWK<http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-27#ref-JWK>], [JWS<http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-27#ref-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.  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.

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.

We are getting close :-)

Mike> Agreed :-)

Thanks,
Kathleen

Best regards,
Kathleen

                                                            Have a good weekend!
                                                            -- Mike

--

Best regards,
Kathleen

                                                                -- Mike

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 16 Jun 2014 17:50:46 -0400

Thanks, Mike.  Answers in-line.

On Mon, Jun 16, 2014 at 5:32 PM, Mike Jones <[email-masked]>
wrote:

> *Sent:* Monday, June 16, 2014 2:10 PM
>
> *To:* Mike Jones
> *Cc:* [email-masked]
> 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!

> 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.)

> 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

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Mon, 16 Jun 2014 22:05:35 +0000

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-masked]]
Sent: Monday, June 16, 2014 2:51 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms

On Mon, Jun 16, 2014 at 5:32 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Mike> Thanks.  Responses inline…

To: Mike Jones

To: Mike Jones

Yes, thanks!

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.

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 16 Jun 2014 18:22:57 -0400

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-masked]> wrote:
> 
> On Mon, Jun 16, 2014 at 5:32 PM, Mike Jones <[email-masked]> wrote:
> On Fri, Jun 13, 2014 at 6:15 PM, Mike Jones <[email-masked]> wrote:
> On Fri, Jun 13, 2014 at 4:26 PM, Mike Jones <[email-masked]> wrote:
> 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?
>

---

From: Mike Jones <[email-masked]>
Date: Sat, 21 Jun 2014 00:04:49 +0000

The Security Considerations changes we’ve discussed have all been applied to the -28 drafts.

                                                            -- Mike

From: Kathleen Moriarty [mailto:[email-masked]]
Sent: Monday, June 16, 2014 3:23 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms

Thanks,
Kathleen

Sent from my iPhone

On Jun 16, 2014, at 6:05 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Mike> Just one answer to a question that you asked is inline below.  I agree with all the proposed resolutions described.

To: Mike Jones

To: Mike Jones

Yes, 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