(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:[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.
>
> 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
>> [email protected] https://www.ietf.org/mailman/listinfo/jose
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
