Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)

Brian Campbell <bcampbell@pingidentity.com> Tue, 21 October 2014 21:33 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033861A8761 for <jose@ietfa.amsl.com>; Tue, 21 Oct 2014 14:33:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.577
X-Spam-Level:
X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yss0n4SqJQD for <jose@ietfa.amsl.com>; Tue, 21 Oct 2014 14:33:20 -0700 (PDT)
Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B38F81A874C for <jose@ietf.org>; Tue, 21 Oct 2014 14:33:19 -0700 (PDT)
Received: from mail-ie0-f169.google.com ([209.85.223.169]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKVEbRH+5vdHniHBkqJR92XQ0Zdy9O11YW@postini.com; Tue, 21 Oct 2014 14:33:19 PDT
Received: by mail-ie0-f169.google.com with SMTP id tr6so177847ieb.0 for <jose@ietf.org>; Tue, 21 Oct 2014 14:33:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qjNRbyOJ2DxC9XQeHp/VuGMLvac4PpPv3nB86FJH7AM=; b=X+d58C6McDyNcHKwNhgtVc3DTK85YNSMO++rYy/Rx+hG9hOB89Wf1xj2JtITF0luJB KmIkQy9XmZvvg7ierFJ+NmGbZaYgbnJHmwcbbfUM/0dwLd08MRdyh80PaMfVmF1ZFiKO yh5XV8sfmlIXDzYMaan34+ZZfg60nUFBCkQklFcfCHE+PMO+Oqp9stXLGCxClsViEnXR op8+blNzChW/dl+pKPPntLbnHQ93WJegX0A+fjjMPoWKSLHcw2ZGlvRQXfzpq6qFl24H cHezvHl+h+jiz3gr3EbXrYh7D/3+mENwA095M4cLRknvchZ/9xTkJ72VPFoQb6baxV+F vwQA==
X-Gm-Message-State: ALoCoQlZk0sQbyyyENy1i04OH7AxQYCqbdoFwP1bCNmxhVaFdROd8ABz8qfkaBwRIzGgcBYUrzK7fbNcM6Yy0VSiLIkOxghC7Hm6fA9QCgIRz0lzDRYQs6VNhZxMCRKEXDT8kVO5Sv2y
X-Received: by 10.42.224.3 with SMTP id im3mr720283icb.49.1413927199041; Tue, 21 Oct 2014 14:33:19 -0700 (PDT)
X-Received: by 10.42.224.3 with SMTP id im3mr720261icb.49.1413927198798; Tue, 21 Oct 2014 14:33:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.86.167 with HTTP; Tue, 21 Oct 2014 14:32:47 -0700 (PDT)
In-Reply-To: <54465282.2020304@cs.tcd.ie>
References: <4E1F6AAD24975D4BA5B16804296739439BB0D42D@TK5EX14MBXC286.redmond.corp.microsoft.com> <54465282.2020304@cs.tcd.ie>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 21 Oct 2014 15:32:47 -0600
Message-ID: <CA+k3eCSdZqgetmCsb6PhnA+c4QxLGyMcQSu3_rG+8bQv2CJF2w@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary=001a113328466c798d0505f594c0
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/s0yI5Je4CldKXArIBUlAhe8NKQw
Cc: "draft-ietf-jose-json-web-algorithms@tools.ietf.org" <draft-ietf-jose-json-web-algorithms@tools.ietf.org>, Mike Jones <Michael.Jones@microsoft.com>, "jose-chairs@tools.ietf.org" <jose-chairs@tools.ietf.org>, The IESG <iesg@ietf.org>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Oct 2014 21:33:25 -0000

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 <stephen.farrell@cs.tcd.ie>
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:jose-bounces@ietf.org] On Behalf Of Mike Jones
> >> Sent: Monday, October 06, 2014 12:54 AM
> >> To: Stephen Farrell; The IESG
> >> Cc: jose-chairs@tools.ietf.org; jose@ietf.org;
> draft-ietf-jose-json-web-
> >> algorithms@tools.ietf.org
> >> 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:stephen.farrell@cs.tcd.ie]
> >>> Sent: Thursday, October 02, 2014 3:37 AM
> >>> To: The IESG
> >>> Cc: jose-chairs@tools.ietf.org; draft-ietf-jose-json-web-
> >>> algorithms@tools.ietf.org
> >>> 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
> >> jose@ietf.org
> >> https://www.ietf.org/mailman/listinfo/jose
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>