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: Mon, 6 Oct 2014 07:54:09 +0000

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.

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

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 6 Oct 2014 13:59:15 -0700

> 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-
> Subject: Re: [jose] 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
> > Sorry to pile on, but I guess such a detailed and broad piece of work
> > is likely to attract many comments and discusses.
> > (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?

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

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.

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

> be added, if wanted/needed.

Everybody is going EC these days.

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

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

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

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

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-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Oct 2014 22:17:55 +0100

(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-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- 
>> 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.
>>> 
>>> 
>>> 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.
>> 
> 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 tricky yes. I'll clear that as a DISCUSS and make it a
comment.

S.

>> 
>> 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.
> 
>> 
>> No one has previously asked about it.  But there registry will be
>> there for it to be added, if wanted/needed.
> 
>>> (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
>> 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.
> 
>> 
>> 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....
> 
>> 
>> 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.
>> 
> 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-masked] https://www.ietf.org/mailman/listinfo/jose
>

---

From: John Bradley <[email-masked]>
Date: Mon, 6 Oct 2014 19:35:52 -0300

The reference for key lengths is SP-800-57 http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf

Note table 2 lists 80 bits of security for RSA k=1025 and ECC f=160-233  and 112 bits for RSA k=2048 and ECC f=224-255

Table 4 lists 80 bits as being disallowed for applying while it may still be used for legacy use processing.
112 bits is acceptable to 2030 (if we are lucky).

There is no real legacy use of JOSE so starting at 112 bits seemed reasonable.  
(Depending on a number of factors this should be a minimum depending on how long you want to have integrity over verifying the signatures.)

John B.

---

From: Mike Jones <[email-masked]>
Date: Tue, 7 Oct 2014 02:52:40 +0000

> Sent: Monday, October 06, 2014 2:18 PM
> To: Jim Schaad; Mike Jones; 'The IESG'
> [email-masked]; [email-masked]
> (Sooo many messages on JOSE, I'll work backwards and see how far I get:-)
> 
> >> -----Original Message----- From: jose [mailto:[email-masked]]
> >> On Behalf Of Mike Jones Sent:
> >> Thanks for your review, Stephen.  I've included the working group on
> >> the thread so they're aware of your comments.
> >>
> >>> all email addresses included in the To and CC lines. (Feel free to
> >>> cut this introductory paragraph, however.)
> >>>
> >>>
> >>> Please refer to
> >>> 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"
> >>> this was discussed by the WG, I just want to check as I don't recall
> >>> it.)
> >>
> >> 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.
> >

These fields were actually added in https://tools.ietf.org/html/draft-jones-jose-json-private-key-01 before their adoption by the WG.  They had been absent in the -00 version of that draft.  The other change in -01 was to align the field names from RFC 3447.  It was in the interest of RFC 3447 alignment, which I believe James Manger had suggested, that the >= 3 primes fields were added.  That draft became https://tools.ietf.org/html/draft-jones-jose-json-private-and-symmetric-key-00 when symmetric keys were added at the WG's request.  The working group then decided to incorporate the content of https://tools.ietf.org/html/draft-jones-jose-json-private-and-symmetric-key-00 into http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 and https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-09.  Given that "oth", etc. were included in multiple individual submission drafts before the WG decision to incorporate their content into the WG drafts, I took that as agreement that that feature should be included.

FYI, Richard Barnes had proposed in a DISCUSS that we cite RFC 3447 in the definitions of these fields.  I agree that we should do this.

I personally came around to the view that defining syntax for the >= 3 primes keys, as RFC 3447 did, would do no harm.  If applications choose not to support it or use it, that's fine.

> >>> 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.
> >>
> >> 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
> > 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 tricky yes. I'll clear that as a DISCUSS and make it a comment.

Thanks.  I agree that it's tricky.  I'll still keep listening for suggested language improvements, but I don't personally have any in mind.

> >> 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.
> >
> >>> 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.)
> >>
> >> representation than multiple representations.  Given the curve
> >> discussions, that's also another reason I'd opt for "later".
> >>
> >
> > They were also added for ASN.1 because these were positive numbers and
> > not negative numbers.  This affects prefix removal for integers.

As Jim points out, being able to know the length of the key by doing a .Length operation is another reason for keeping things the way they are.

Finally, existing implementations are having no problems that I've heard of using the keys as specified.  If it ain't broke - don't fix it.

> > will be created by a KDF), then....

Thanks, Jim.

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

Thanks, Jim.

> > implementations should set an upper limit on the key sizes they accept
> > and enforce it.

I agree that this language should be significantly simplified.  I'll try to do something along the lines suggested.

---

From: Mike Jones <[email-masked]>
Date: Tue, 7 Oct 2014 02:54:16 +0000

> From: John Bradley [mailto:[email-masked]]
> Sent: Monday, October 06, 2014 3:36 PM
> To: Mike Jones
> Cc: Stephen Farrell; The IESG; [email-masked]; [email-masked]; draft-
> [email-masked]
> The reference for key lengths is SP-800-57
> http://csrc.nist.gov/publications/nistpubs/800-57/sp800-
> 57_part1_rev3_general.pdf

Thanks for this reference, John.  I'll plan to use it where the 2048 bit requirement is specified.

> (Depending on a number of factors this should be a minimum depending on how
> long you want to have integrity over verifying the signatures.)
> 
> John B.
> 
> 
> 
> 
> > Thanks for your review, Stephen.  I've included the working group on the
> thread so they're aware of your comments.
> >
> >> (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
> >> - 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.
> >> 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.
> >
> > 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?
> >
> > 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.
> >
> >> work it would be to add now, vs to add later. If "later" would cause
> >> a lot of duplication, then maybe "now"
> representation than multiple representations.  Given the curve discussions, that's
> also another reason I'd opt for "later".
> >
> > I don't actually recall.  I think the two choices reasonably available to us at this
> >> - 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.5: I'd prefer there was no none. The WG did discuss it though, so
> >> I'll hold my nose.
> >
> > Understood.
> >
> >> - 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.
> >