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 protected]]
Sent: Thursday, November 27, 2014 11:36 AM
To: Stephen Farrell; The IESG
Cc: [email protected];
[email protected]
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 protected]]
Sent: Thursday, November 27, 2014 8:04 AM
To: The IESG
Cc: [email protected];
[email protected]
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.
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
