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

Stephen Farrell <> Mon, 06 October 2014 21:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6D6591A8A25; Mon, 6 Oct 2014 14:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.686
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yQtSf9157dVG; Mon, 6 Oct 2014 14:17:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C66671A1A19; Mon, 6 Oct 2014 14:17:58 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B0B1BE09; Mon, 6 Oct 2014 22:17:58 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qceCC2SiL8_r; Mon, 6 Oct 2014 22:17:55 +0100 (IST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id B2C63BE07; Mon, 6 Oct 2014 22:17:55 +0100 (IST)
Message-ID: <>
Date: Mon, 06 Oct 2014 22:17:55 +0100
From: Stephen Farrell <>
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 <>, 'Mike Jones' <>, 'The IESG' <>
References: <> <> <00d801cfe1a8$63e45f20$2bad1d60$>
In-Reply-To: <00d801cfe1a8$63e45f20$2bad1d60$>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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
>> [] On Behalf Of Mike Jones Sent:
>> Monday, October 06, 2014 12:54 AM To: Stephen Farrell; The IESG Cc:
>> draft-ietf-jose-json-web- 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
>>> [] Sent: Thursday, October 02,
>>> 2014 3:37 AM To: The IESG Cc:;
>>> draft-ietf-jose-json-web- Subject:
>>> Stephen Farrell's Discuss on
>>> draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and
>>> 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 
>>> for more
>>> information about IESG DISCUSS and COMMENT positions.
>>> The document, along with other ballot positions, can be found
>>> here: 
>>> ----------------------------------------------------------------------
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) 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


>>> ----------------------------------------------------------------------
>>> ----------------------------------------------------------------------
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.
>>> - 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