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

From: Mike Jones <[email-masked]>
Date: Fri, 14 Nov 2014 23:09:17 +0000

Hi Stephen,

The "oth" RSA parameter was discussed during the JOSE meeting at IETF 91 and several people spoke up in favor of keeping it.  We discussed adding text saying that if the >2 primes case isn't supported, that private keys using "oth" have to be ignored.  The text that I've added to my editor's draft follows.  Does that work for you?

   If the consumer of a JWK does not
   support private keys with more than two primes and it encounters a
   private key that includes the "oth" parameter, then it MUST either
   reject the key or ignore all the private key parameters other than
   "d".

				Thanks,
				-- Mike

-----Original Message-----
From: Mike Jones [mailto:[email-masked]] 
Sent: Friday, October 24, 2014 12:59 PM
To: Stephen Farrell; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Stephen Farrell's Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)

Hi Stephen,

On your "oth" DISCUSS, at Richard's request, I did add this sentence to the description of the "oth" parameters:

   For more
   information on this case, see the description of the OtherPrimeInfo
   parameters in Section A.1.2 of RFC 3447 [RFC3447], upon which the
   following parameters are modelled.

I agree that these will be lightly used, but there's a good interop argument for maintaining syntax parity with RFC 3447 Section A.1.2.  If two implementations both want to use these parameters for some reason, they'll then do it the same way.  Whereas having this syntax defined doesn't place any burden on those who choose not to use it.

I'll therefore ask you to consider clearing this DISCUSS on this basis.

				Thanks again,
				-- Mike

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, October 21, 2014 5:33 AM
To: Mike Jones; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Stephen Farrell's Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 14 Nov 2014 23:18:55 +0000

Hi Mike,

On 14/11/14 23:09, Mike Jones wrote:
> Hi Stephen,
> 
> The "oth" RSA parameter was discussed during the JOSE meeting at IETF
> 91 and several people spoke up in favor of keeping it. 

So all the mail I saw said that it wasn't supported, or am I
mis-remembering? (Which is quite possible, and apologies if
so.)

> We discussed
> adding text saying that if the >2 primes case isn't supported, that
> private keys using "oth" have to be ignored.  The text that I've
> added to my editor's draft follows.  Does that work for you?

So if the above is correct, then we have a bunch of jose
implementations, but no interop for that feature, but yet
you want to keep it. Hmm.

> If the consumer of a JWK does not support private keys with more than
> two primes and it encounters a private key that includes the "oth"
> parameter, then it MUST either reject the key or ignore all the
> private key parameters other than "d".

And hence go very very slow, is that correct?

And of course RSA moduli with >2 factors are either less secure
or longer and hence slower, so not using the CRT means that it'll
be dog slow or insecure.

Why keep the feature, really?

What is the basis on which people wanted to keep it?

S.

> 
> Thanks, -- Mike
> 
> -----Original Message----- From: Mike Jones
> [mailto:[email-masked]] Sent: Friday, October 24, 2014
> 12:59 PM To: Stephen Farrell; The IESG Cc:
> [email-masked];
> [email-masked]; [email-masked] 
> Subject: RE: Stephen Farrell's Discuss on
> draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)
> 
> Hi Stephen,
> 
> On your "oth" DISCUSS, at Richard's request, I did add this sentence
> to the description of the "oth" parameters:
> 
> For more information on this case, see the description of the
> OtherPrimeInfo parameters in Section A.1.2 of RFC 3447 [RFC3447],
> upon which the following parameters are modelled.
> 
> I agree that these will be lightly used, but there's a good interop
> argument for maintaining syntax parity with RFC 3447 Section A.1.2.
> If two implementations both want to use these parameters for some
> reason, they'll then do it the same way.  Whereas having this syntax
> defined doesn't place any burden on those who choose not to use it.
> 
> Thanks again, -- Mike
> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Tuesday, October 21, 2014
> 5:33 AM To: Mike Jones; The IESG Cc: [email-masked];
> [email-masked]; [email-masked] 
> Subject: Re: Stephen Farrell's Discuss on
> draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)
> 
> 
> 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...
> 
>> 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:[email-masked]] On Behalf Of Mike Jones Sent:
>>> Monday, October 06, 2014 12:54 AM To: Stephen Farrell; The IESG 
>>> draft-ietf-jose-json-web- [email-masked] Subject: Re:
>>> [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web- 
>>> 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-masked]] Sent: Thursday, October 02,
>>>> 2014 3:37 AM To: The IESG Cc: [email-masked];
>>>> draft-ietf-jose-json-web- [email-masked] Subject:
>>>> Stephen Farrell's Discuss on
>>>> draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and
>>>> COMMENT)
>>>> 
>>>> 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.
>>>> 
>>>> 
>>>> -- 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.)
>>> 
>>> 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.
> 
>>>> (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.
>>> 
--
--
>>>> 
>>>> 
>>>> - 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.
>>> I concur with your synopsis of the discussion that occurred in
>>> the working group and the conclusions reached.
>>> 
>>>> 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 
>>> 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?
>>> 
>>> 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.
>>> 
>>>> (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 
>>> 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.
>>> 
>>>> 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.
>>> 
>>> 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.
>>> 
>>>> - 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.
>>> 
>>> _______________________________________________ jose mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Fri, 14 Nov 2014 23:47:00 +0000

> So all the mail I saw said that it wasn't supported, or am I mis-remembering?
> (Which is quite possible, and apologies if
> so.)

Yes, I'm not aware of an implementation that supports it today.

> > private keys using "oth" have to be ignored.  The text that I've added
> > to my editor's draft follows.  Does that work for you?
> 
> So if the above is correct, then we have a bunch of jose implementations, but no
> interop for that feature, but yet you want to keep it. Hmm.

From my personal notes during the meeting, Richard Barnes, John Bradley, and Justin Richer stood up at the microphone to advocate keeping it, for completeness sake, and for future interop sake.  Their point was that if someone ever does want to use keys with >2 primes, it's better that they all do it in the same way in the future, rather than having each of them invent their own representation.  The real meeting notes may also record more of this discussion.

> And hence go very very slow, is that correct?

... or refuse to go at all by rejecting the key if it contains "oth" and you don't grok it.

> And of course RSA moduli with >2 factors are either less secure or longer and
> hence slower, so not using the CRT means that it'll be dog slow or insecure.
> 

They wanted to keep it so if, in the future, implementations do want to use keys with >2 primes, that they do it the same way.

				-- Mike

> > OtherPrimeInfo parameters in Section A.1.2 of RFC 3447 [RFC3447], upon
> > which the following parameters are modelled.
> >
> >> 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:[email-masked]]
> >>> On Behalf Of Mike Jones Sent:
> >>>> http://www.ietf.org/iesg/statement/discuss-criteria.html for more
> >>>> information about IESG DISCUSS and COMMENT positions.
> >>>>
> >>>>
> >>>> work is likely to attract many comments and discusses. Mine should
> >>>> be cleared up easily enough I hope.
> >>>>
> >>>> 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.)
> >>>
> >>> offline on an airplane over the Pacific.)  It was also discussed as
> >>> issue #153.  This feature was directly modelled on RFC 3447.
> >>>> 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.
> >>>
> >>> 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".
> >>>
> >>> 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.
> >>>
> >>>> 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.
> >>> take up additional vertical space without making the spec clearer.
> >>> But I could be convinced otherwise.  Why do you want captions?
> >>>
> >>>> 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.)
> >>>
> >>> 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.
> >>>
> >>>> 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.
> >>>
> >>> the top of my head.  Working group, what are the relevant documents
> >>> here that we could reference for this information?
> >>>
> >>> _______________________________________________ jose mailing list
> >>> [email-masked] https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Thu, 20 Nov 2014 01:27:52 +0000

This resolution is incorporated in the -37 drafts.  Please let me know if this works (well enough) for you, Stephen.

				Thanks again,
				-- Mike

-----Original Message-----
From: Mike Jones [mailto:[email-masked]] 
Sent: Friday, November 14, 2014 3:47 PM
To: Stephen Farrell; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Stephen Farrell's Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)

> implementations, but no interop for that feature, but yet you want to keep it. Hmm.

> > If the consumer of a JWK does not support private keys with more 
> > than two primes and it encounters a private key that includes the "oth"

> And of course RSA moduli with >2 factors are either less secure or 
> longer and hence slower, so not using the CRT means that it'll be dog slow or insecure.
> 

				-- Mike

> >>>> all email addresses included in the To and CC lines. (Feel free 
> >>>> to cut this introductory paragraph, however.)
> >>>>
> >>>>
> >>>> Please refer to
> >>>> http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorith
> >>>> ms
> >>>> /
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> -----------------------------------------------------------------
> >>>> --
> >>>> -
> >>>>
> >>>>
> --
> >>>>
> >>>>
> >>>> work is likely to attract many comments and discusses. Mine 
> >>>> (I vaguely recall some IPR with such moduli for some uses too, 
> >>>> but not sure.) I'd recommend dropping the whole "oth"
> >>> 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.
> >
> > 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 
> >>>> request for
> >>>> 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.
> >>>
> >>> identifiers registered for non-authenticated encryption algorithms 
> >>>> -----------------------------------------------------------------
> >>>> --
> >>>> -
> >>>>
> >>>>
> --
> >>>> COMMENT:
> >>>> -----------------------------------------------------------------
> >>>> --
> >>>> -
> >>>>
> >>>>
> --
> >>>>
> >>>>
> >>>> 2049 bit keys might not work for many implementations and are not 
> >>>> a great idea (as Bleichenbacher works quicker against such 
> >>> to take up additional vertical space without making the spec clearer.
> >>> final
> >>>> but whatever. Those were historically added so that buggy 
> >>>> for