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

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 17 Apr 2014 10:50:57 -0400

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 17 Apr 2014 11:07:11 -0400

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!

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Thu, 17 Apr 2014 17:45:34 +0000

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]
Cc: Mike Jones; [email-masked]
Subject: AD review of draft-ietf-jose-json-web-algorithms

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.

Mike> So you’re suggesting that future JWA drafts might obsolete the 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.

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

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

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.

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.

Mike> If adding a new “RSA-OAEP-256” algorithm identifier for “RSAES 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…

--

Best regards,
Kathleen

                                                            Thanks a bunch,
                                                            -- Mike

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 17 Apr 2014 14:16:00 -0700

From: jose [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Thursday, April 17, 2014 7:51 AM
To: [email-masked]
Cc: Michael Jones; [email-masked]
Subject: [jose] AD review of draft-ietf-jose-json-web-algorithms

[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.  I would point to the following as examples:

TLS uses registries for all of their algorithm assignments.

http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18 – The TLS HashAlgorithm Registry

Kerberos has their OIDS registered with IANA

http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-26

PKIX and CMS have been moving towards keeping their OID trees in IANA registries

RFC 7101 and https://datatracker.ietf.org/doc/draft-housley-pkix-oids/

This is only a small set of the algorithm registries that are kept by IANA.  The only new thing is that the requirements level of algorithm is now being kept in the registry, however that requires a document of some type to change the top level requirements.

I would note that we already have the following non-IETF document that is going to make changes to the IANA registry http://www.w3.org/TR/WebCryptoAPI

jim

 

   Among these issues are

-- 

Best regards,

Kathleen

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 17 Apr 2014 14:20:27 -0700

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Thursday, April 17, 2014 10:46 AM
To: Kathleen Moriarty; [email-masked]
Cc: [email-masked]
Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms

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

   Among these issues are

-- 

Best regards,

Kathleen

                                                            Thanks a bunch,

                                                            -- Mike

---

From: Mike Jones <[email-masked]>
Date: Thu, 17 Apr 2014 23:21:36 +0000

I strongly agree with a point that Jim is making below:  JWA must continue to create the algorithms registries so that other specifications can add algorithm identifiers.  http://www.w3.org/TR/WebCryptoAPI is only the first of many specs that we anticipate will use these registries.  For instance, it wouldn’t be at all surprising to have other specs register additional Elliptic Curve “crv” identifiers in the near future.

Kathleen, I took your suggestion as being that the Required/Recommended/Optional/Deprecated/Prohibited status of algorithms defined by the initial JWA RFC would be updated by new RFCs that obsoleted the initial JWA RFC – not that the algorithm identifiers themselves would not be registered in the appropriate registries.  That’s the change I was planning on working on, based upon your feedback.  Please confirm that that’s your intent, or if not, let’s talk further.

                                                                Best wishes,
                                                                -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Thursday, April 17, 2014 2:16 PM
To: 'Kathleen Moriarty'; [email-masked]
Cc: Mike Jones; [email-masked]
Subject: RE: [jose] AD review of draft-ietf-jose-json-web-algorithms

From: jose [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Thursday, April 17, 2014 7:51 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Michael Jones; [email-masked]<mailto:[email-masked]>
Subject: [jose] AD review of draft-ietf-jose-json-web-algorithms

jim

--

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 25 Apr 2014 17:07:22 -0400

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]> wrote:
> 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.
>
>
>
> Mike> So you’re suggesting that future JWA drafts might obsolete the 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> This is included to enable representing content that is 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?

>
> 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
> Mike> Sure.  The key part of the message you cited is “Once the McGrew 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> 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.
>
>
KM> Great, thank you!
> 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.
>
>
>
> Mike> If adding a new “RSA-OAEP-256” algorithm identifier for “RSAES 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.

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Sat, 26 Apr 2014 01:38:23 +0000

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]; [email-masked]
Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms

Thanks!

On Thu, Apr 17, 2014 at 5:20 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:

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

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

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

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

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

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.

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

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

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 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 was added in draft-ietf-jose-json-web-algorithms-16, published on 9/15/13.  Jim closed the issue on 10/28/13.

> 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

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

> 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

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

clear this up?

Mike> I’d had in-person and phone conversations with him about it last 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.

> 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

>    protecting the user's private and symmetric keys, preventing

> various

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

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

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.

> 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!!

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

> Mike> If adding a new “RSA-OAEP-256” algorithm identifier for “RSAES

> Mike> with

> 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…

Mike> OK – I’ll add it.

Mike> Per your JWS comment, SHA-1 thumbprints are widely deployed.  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. ☺)

>                                                             Thanks a

> bunch,

--

Best regards,

Kathleen

_______________________________________________

jose mailing list

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

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

                                                                Thanks again,

                                                                -- Mike