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

[Stephen Farrell <[e-mail]>]

(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:[e-mail]] On Behalf Of Mike Jones Sent:
>> Monday, October 06, 2014 12:54 AM To: Stephen Farrell; The IESG Cc:
>> [e-mail]; [e-mail];
>> draft-ietf-jose-json-web- [e-mail] 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:[e-mail]] Sent: Thursday, October 02,
>>> 2014 3:37 AM To: The IESG Cc: [e-mail];
>>> draft-ietf-jose-json-web- [e-mail] 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 
>> [e-mail] https://www.ietf.org/mailman/listinfo/jose
>