Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)
Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 06 October 2014 21:18 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
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 6D6591A8A25; Mon, 6 Oct 2014 14:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level:
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham
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 yQtSf9157dVG; Mon, 6 Oct 2014 14:17:59 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C66671A1A19; Mon, 6 Oct 2014 14:17:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2B0B1BE09; Mon, 6 Oct 2014 22:17:58 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qceCC2SiL8_r; Mon, 6 Oct 2014 22:17:55 +0100 (IST)
Received: from [10.87.48.8] (unknown [86.41.57.167]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B2C63BE07; Mon, 6 Oct 2014 22:17:55 +0100 (IST)
Message-ID: <54330703.3050806@cs.tcd.ie>
Date: Mon, 06 Oct 2014 22:17:55 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Jim Schaad <ietf@augustcellars.com>, 'Mike Jones' <Michael.Jones@microsoft.com>, 'The IESG' <iesg@ietf.org>
References: <20141002103700.19412.21857.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C06@TK5EX14MBXC286.redmond.corp.microsoft.com> <00d801cfe1a8$63e45f20$2bad1d60$@augustcellars.com>
In-Reply-To: <00d801cfe1a8$63e45f20$2bad1d60$@augustcellars.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/Q-TEHkernFew6H_QeVnU3T1ERZY
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)
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: Mon, 06 Oct 2014 21:18:01 -0000
(Sooo many messages on JOSE, I'll work backwards and see how far I get:-) On 06/10/14 21:59, Jim Schaad wrote: > > >> -----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. > > Mike, I may be missing some messages in my archive, however the last > message I see on this was you said that unless there was a demand for > it you saw no need to include this. It then got included. Do you > have a message I am missing? Ah, ok, I'll leave this bit open for the present. > >> >>> (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. > > I would tend to say that registering algorithms that we know now are > blah would not be acceptable. (Note that you would need to create > an AEAD version of DES but that is doable.) However, I would say > that registration of vanity algorithms would not necessarily be > verboten. I would hope that the DEs did some small due diligence > that the algorithm has been analyzed and is not trivially bad. > > It is not clear to me that it is possible to give language beyond "Do > the right thing" that would be usable. It is tricky yes. I'll clear that as a DISCUSS and make it a comment. S. > >> >>> ---------------------------------------------------------------------- >>> >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> >>> 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. > > Add a width attribute to the ttcol with either "digits" (for fixed > width) or "digits%" (for percent width) to the column in question. > >> >>> - 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. > > Everybody is going EC these days. > >> >>> - 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". >> > > There was discussion on having compressed points. Richard suggested > it in his message to change how points were done. Mike said that he > wanted a single method and Russ said that the uncompressed method had > to be mandatory. The group kinda drifted into just having the > uncompressed format. > >>> - 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. > > They were also added for ASN.1 because these were positive numbers > and not negative numbers. This affects prefix removal for integers. > Would not have been an issue if they had been octet strings. I am > agnostic about removal or keeping. Knowing the length of the key by > doing a simple strlen seems to me to be a win. > >> >>> - 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? > > > Might be better to say. If multiple variations of an algorithms are > being registered that vary only in key length (for example AES128 and > AES256) and the key length needs to be fixed (for example because it > will be created by a KDF), then.... > >> >>> - 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? > > Boneh, Dan (1999). "Twenty Years of attacks on the RSA Cryptosystem". > Notices of the American Mathematical Society 46 (2): 203–213. > >>> - 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. > > Yeah, I tend to agree. It might be better to just say that > implementations should set an upper limit on the key sizes they > accept and enforce it. > >> >> -- Mike >> >> _______________________________________________ jose mailing list >> jose@ietf.org https://www.ietf.org/mailman/listinfo/jose >
- Re: [jose] Stephen Farrell's Discuss on draft-iet… Mike Jones
- Re: [jose] Stephen Farrell's Discuss on draft-iet… Jim Schaad
- Re: [jose] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
- Re: [jose] Stephen Farrell's Discuss on draft-iet… John Bradley
- Re: [jose] Stephen Farrell's Discuss on draft-iet… Mike Jones
- Re: [jose] Stephen Farrell's Discuss on draft-iet… Mike Jones
- Re: [jose] Stephen Farrell's Discuss on draft-iet… Mike Jones
- Re: [jose] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
- Re: [jose] Stephen Farrell's Discuss on draft-iet… Brian Campbell
- Re: [jose] Stephen Farrell's Discuss on draft-iet… Mike Jones
- Re: [jose] Stephen Farrell's Discuss on draft-iet… Mike Jones
- Re: [jose] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
- Re: [jose] Stephen Farrell's Discuss on draft-iet… Mike Jones
- Re: [jose] Stephen Farrell's Discuss on draft-iet… Mike Jones