As one data point (and nothing more than that), I have the other primes member and parameter names defined in my implementation[1] but they are unused and there's a "TODO" comment next to them[2] as a reminder to look at it someday maybe. It's been that way for well over a year.
[1] https://bitbucket.org/b_c/jose4j [2] line 43 https://bitbucket.org/b_c/jose4j/annotate/8debf5f97252a27bfa613df86b5a0e7febdbdba0/src/main/java/org/jose4j/jwk/RsaJsonWebKey.java?at=master On Tue, Oct 21, 2014 at 6:33 AM, Stephen Farrell <[email protected]> wrote: > > Hi Mike, > > Just on my one remaining discuss point which is about > RSA key pairs where the modules has >2 prime factors > and the "oth" field... > > On 14/10/14 13:51, Mike Jones wrote: > > The proposed resolutions have been incorporated in the -34 draft. > Hopefully you'll be able to clear your DISCUSSes on that basis. > > > > Note that I did manage to come up with some guidance to the designated > experts about performing reasonable due diligence on registered algorithms > in Section 7.1. References were added backing lots of the previously > mysterious statements about key sizes, etc. as well. > > > > Thanks again, > > -- Mike > > > >> -----Original Message----- > >> From: jose [mailto:[email protected]] On Behalf Of Mike Jones > >> Sent: Monday, October 06, 2014 12:54 AM > >> To: Stephen Farrell; The IESG > >> Cc: [email protected]; [email protected]; > draft-ietf-jose-json-web- > >> [email protected] > >> Subject: Re: [jose] Stephen Farrell's Discuss on > draft-ietf-jose-json-web- > >> algorithms-33: (with DISCUSS and COMMENT) > >> > >> Thanks for your review, Stephen. I've included the working group on > the thread > >> so they're aware of your comments. > >> > >>> -----Original Message----- > >>> From: Stephen Farrell [mailto:[email protected]] > >>> Sent: Thursday, October 02, 2014 3:37 AM > >>> To: The IESG > >>> Cc: [email protected]; draft-ietf-jose-json-web- > >>> [email protected] > >>> Subject: Stephen Farrell's Discuss on > draft-ietf-jose-json-web-algorithms-33: > >>> (with DISCUSS and COMMENT) > >>> > >>> Stephen Farrell has entered the following ballot position for > >>> draft-ietf-jose-json-web-algorithms-33: Discuss > >>> > >>> 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/ > >>> > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> DISCUSS: > >>> ---------------------------------------------------------------------- > >>> > >>> > >>> Sorry to pile on, but I guess such a detailed and broad piece of work > >>> is likely to attract many comments and discusses. > >>> Mine should be cleared up easily enough I hope. > >>> > >>> (1) 6.3.2.7: Hmm, where was that discussed on the list? I think it'd > >>> be better if >2 prime RSA was considered a separate algorithm. (I > >>> vaguely recall some IPR with such moduli for some uses too, but not > >>> sure.) I'd recommend dropping the whole "oth" parameter entirely. > >>> (I'll clear this discuss once its clear that this was discussed by the > >>> WG, I just want to check as I don't recall it.) > >> > >> This was discussed in the thread "private keys, leading zeros" > initiated by James > >> Manger on August 15, 2012. (Sorry, I can't get you the archive URL > reference at > >> present because I'm writing this offline on an airplane over the > Pacific.) It was > >> also discussed as issue #153. This feature was directly modelled on > RFC 3447. > >> Applications are free to profile the JWK spec to prohibit the use of > such keys, so > >> I don't see a compelling case to remove it. > > Well that was a modest dicussion wasn't it - James said, "hey > what about >2 primes?" and you said "yurgh, do we need it or > is that theoretical?" and that was it. > > I understand the reluctance to drop it now but would like to > check if the WG want to keep this or not as I'd not be at all > surprised if few or none had code or had thought much about > it. I'd equally not be surprised if some code did exist. I > would be surprised if lots of well-tested code existed:-) > > Cheers, > S. > > PS: I didn't scan the comments. > > >> > >>> (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. > >> > >> Registering DES with the Implementation Requirements value "Prohibited" > >> would be permitted. The instructions on the "JOSE Implementation > >> Requirements" registry field include: > >> Any identifiers registered for non-authenticated encryption > algorithms > >> or other algorithms that are otherwise unsuitable for direct use > >> as JWS or JWE algorithms must be registered as "Prohibited". > >> > >> Note that this capability was added at the request of the W3C WebCrypto > WG. > >> (WebCrypto is choosing to support some algorithms that JOSE explicitly > chose > >> not to, including some non-authenticated encryption algorithms.) > "Deprecated" > >> is also a value available to registrants and the DEs. > >> > >> If you want to supply additional proposed language to the DEs, that > would be > >> welcomed. > >> > >>> ---------------------------------------------------------------------- > >>> COMMENT: > >>> ---------------------------------------------------------------------- > >>> > >>> > >>> - 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.) > >> > >> I concur with your synopsis of the discussion that occurred in the > working group > >> and the conclusions reached. > >> > >>> - 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. > >> > >> Rather than us inventing new text, is there an RFC or other doc we can > reference > >> that provides appropriate guidance on acceptable RSA key lengths? I > know that > >> the 2048 came from NIST key usage requirements that I believe ekr > pointed us > >> to. > >> > >>> - 4.1 (and elsewhere): adding table captions with numbers would be > good. > >> > >> I don't feel strongly about this, but each table is in its own section, > and so can be > >> referenced by section number. I'd experimented with adding captions at > one > >> point and it just seemed to take up additional vertical space without > making the > >> spec clearer. But I could be convinced otherwise. Why do you want > captions? > >> > >>> Col 1 of the final 3 rows are unfortunate. > >> > >> I don't know how to teach xml2rfc to not do what it did to the final 3 > rows, but I > >> can make a note to have the RFC editor manually address this if the > tool can't. > >> > >>> - Surprised there was no need for integer DH. Can be added later I > guess. > >> > >> No one has previously asked about it. But there registry will be there > for it to be > >> added, if wanted/needed. > >> > >>> - 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.) > >> > >> I recall that in the discussions, people were happier having a single > >> representation than multiple representations. Given the curve > discussions, that's > >> also another reason I'd opt for "later". > >> > >>> - 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. > >> > >> Yeah, I realize why the Java library does this. This was another case > where we > >> decided that having a single representation would create less interop > problems > >> down the road than allowing multiple representations. > >> > >>> - 7.1, 2nd para: why not RSA2048 earlier then? > >> > >> I don’t actually recall. I think the two choices reasonably available > to us at this > >> point are to either keep or delete this paragraph. Which would you > prefer? > >> > >>> - 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. > >> > >> Good idea. > >> > >>> - 8.3: Is 65537 considered a "low" e? "Low" is too vague there. > >> > >> No, it's not "low", but I can't back that up with a reference off the > top of my > >> head. Working group, what are the relevant documents here that we could > >> reference for this information? > >> > >>> - 8.5: I'd prefer there was no none. The WG did discuss it though, so > >>> I'll hold my nose. > >> > >> Understood. > >> > >>> - 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. > >> > >> Sean Turner suggested adding that text on July 6, 2012. Proposed edits > would > >> be welcomed. > >> > >>> - 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. > >> > >> You're welcome! > >> > >> I'll plan to work with the RFC Editor to figure out how to best present > it and how > >> to achieve that. I agree that the presentation is screwed up right now. > >> > >>> - 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. > >> > >> Thanks again for your review and your participation in the working > group. > >> > >> -- Mike > >> > >> _______________________________________________ > >> 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
