Subject: Re: [jose] Stephen Farrell's No Objection on draft-ietf-jose-json-web-algorithms-37: (with COMMENT)

From: Mike Jones <[email-masked]>
Date: Wed, 3 Dec 2014 18:40:14 +0000

Hi Stephen,

My editor's draft now uses the following language, which I believe addresses your request:

If the consumer of a JWK does not support private keys with more than two primes and it encounters a private key that includes the "oth" parameter, then it MUST NOT use the key.

				Thanks again,
				-- Mike

-----Original Message-----
From: Mike Jones [mailto:[email-masked]] 
Sent: Thursday, November 27, 2014 11:36 AM
To: Stephen Farrell; The IESG
Cc: [email-masked]; [email-masked]
Subject: RE: Stephen Farrell's No Objection on draft-ietf-jose-json-web-algorithms-37: (with COMMENT)

Thanks, Stephen.  I'll plan to do as you suggest and "say that if you don't support >2 prime RSA then you MUST barf on all such keys" (barf being a term of the art :-) ).

And despite you not being from the U.S., I'll also wish you Happy Thanksgiving.

				-- Mike

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, November 27, 2014 8:04 AM
To: The IESG
Cc: [email-masked]; [email-masked]
Subject: Stephen Farrell's No Objection on draft-ietf-jose-json-web-algorithms-37: (with COMMENT)

Stephen Farrell has entered the following ballot position for
draft-ietf-jose-json-web-algorithms-37: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm clearing but think it's still a bad plan to include the unimplemented >2 prime RSA support here. It's even worse to have it as you do where implementations that don't support this are allowed to use the key pair nonetheless - that seems designed to lead to a lack of security or else horrible performance. You should say that if you don't support >2 prime RSA then you MUST barf on all such keys. However, based on my belief that this won't get used in any case, I'm willing to hold my nose and clear.

-- older comments below, I didn't check them vs. -37 and there's no need to worry about them unless you want to.

First point was a discuss, now a comment:

(2) Instructions to DEs: would registering DES be considered ok or not? What about myJustInventedPrivateAlg?  What about a request for 10 ccTLD specific Algs? I think these need a bit more clarity wrt cryptographic "goodness." As a nit, "makes sense" isn't going to help too much, we've seen that reasonable folks can differ on that here. Again I don't recall that discussion on the list, but please point me at it if it happened.

- Unlike others, I do think implementation requirements are needed. The WG did specifically discuss this (a lot) and landed where it did. I don't think the IESG should second guess that without specific evidence that it'd cause damage.
(Richard's points were made previously I believe.)

- 3.3 (and elsewhere) says 2048 bits or larger. I guess that
2049 bit keys might not work for many implementations and are not a great idea (as Bleichenbacher works quicker against such lengths if I recall correctly). Could be worth a note somewhere even though I guess most folks know what's what.

- 4.1 (and elsewhere): adding table captions with numbers would be good. Col 1 of the final 3 rows are unfortunate.

- Surprised there was no need for integer DH. Can be added later I guess.

- 6.2.1: Given that the point compression IPR is now expired
(right?) did the WG consider now allowing that? I wondered how much work it would be to add now, vs to add later. If "later" would cause a lot of duplication, then maybe "now"
would actually be worth it. ("Later" might also be fine considering the current work in CFRG on additional curves.) 

- 6.3.1.1: allowing the extra 0x00 would be a better choice IMO, but whatever. Those were historically added so that buggy decoders wouldn't wrongly think numbers negative, which could still happen maybe. 

- 7.1, 2nd para: why not RSA2048 earlier then?

- 7.1.1: It might help the DE if the template here required references to well know academic crypto conference publications that consider cryptanalysis of the alg in question, e.g. from crypto, or eurocrypt etc. One good rule of thumb here is that if there are no such references then you really should not register the thing.

- 8.3: Is 65537 considered a "low" e?  "Low" is too vague there.

- 8.5: I'd prefer there was no none. The WG did discuss it though, so I'll hold my nose.

- 8.6: suggesting a CA as a cure for oversized keys is odd, I think those are separable things and e.g. TOFU might be just as or more effective then X.509 here.

- Appendix A:  Thanks for that! It'll save folks a lot of time. Might be better presented as a set of records and not as a fixed width table.

- I think most of the secdir stuff has been handled (and thanks for that) so I'm fine that the authors and AD are on top of that.