Subject: Re: [jose] [apps-discuss] Appsdir review for draft-ietf-jose-json-web-algorithms-33

From: Mike Jones <[email-masked]>
Date: Wed, 15 Oct 2014 08:51:20 +0000

Thanks for your review, Carsten.  I apologize for not responding to it until now.  It had gotten sorted into a folder and I wasn't aware of it until Kathleen brought it to my attention.  Replies are inline below...

> -----Original Message-----
> From: apps-discuss [mailto:[email-masked]] On Behalf Of
> Carsten Bormann
> Sent: Thursday, October 02, 2014 12:22 AM
> To: [email-masked]; draft-ietf-jose-json-web-
> [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-algorithms-
> 33
> 
> I have been selected as the Applications Area Directorate reviewer for this draft
> (for background on appsdir, please see 
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
> ).
> 
> Please resolve these comments along with any other Last Call comments you
> may receive. Please wait for direction from your document shepherd or AD
> before posting a new version of the draft.
> 
> Document:  draft-ietf-jose-json-web-algorithms-33
> Title: JSON Web Algorithms (JWA)
> Reviewer: Carsten Bormann
> Review Date: 2014-10-02
> IESG Telechat date: 2014-10-02
> 
> Summary: This draft is ready for publication as a standards track RFC, with a few
> nits corrected.
> 
> However, some additional editorial improvements might improve the security
> outcome when it is referenced by application developers.
> 
> Major issues: None.
> 
> Minor issues:
> 
> 5.2:
> Add a reference that defines PKCS #7 padding.

I'll plan on adding a reference to RFC 2315 for this.

> 5.2.2.2
> Does "the PKCS #7 padding is removed" entail checking all of its bytes?

Should this be changed to "the PKCS #7 padding bytes are checked and then removed"?

> 6.2.1
> Is the intention that the sentence containing "point compression is not
> supported" also applies to any future registered value of "crv"?
> A similar comment applies to other specifications in 6.2.1.x, e.g., the reference
> to SEC1 representation to x and y.

It would apply to any future curves registered that use the "x", "y" point representation.  Others could define new key types that use a different representation or we could refine the definition of "kty":"EC" to make the representation specific to the "crv" value.

A discussion happened on the JOSE thread "JWK Elliptic Curve key representations and new curves".  The conclusion suggested by Richard Barnes and seconded by Stephen Farrell was to table defining any new key representations for new elliptic curves until the CRFG recommendations to TLS have been made.  That ended the discussion for now.

> 6.2.1.1
> »Additional "crv" values MAY be
> used, provided they are understood by implementations using that Elliptic Curve
> key.« How are conflicts between such implementation defined values and future
> registered values handled?

Conflicts are avoided using the IANA JSON Web Key Elliptic Curve registry defined in Section 7.6.

> 6.3.2:
> The MAY accept partially overrides the MUST include?
> Is the latter thus really a SHOULD?

"d" is REQUIRED.  The others SHOULD be included, and if any are included, the others MUST be included.  Those are requirements on producers.

Consumers may choose to accept keys that don't include all the CRT parameters.  Given that they can be computed from "n", "e", and "d" and sometimes they're not available, a previous reviewer had asked this language about consumers to be included.  It's a case of "Be conservative in what you send, be liberal in what you accept".  It's not clear to me that there's any value in relaxing the requirements on producers.

> 7.1:
> It is interesting that a mere registration (vetted only by a DE) can change the
> IETF consensus base specifications by making an algorithm "Required".

It is expected that the designated experts will be appointed, in part, for their cryptographic expertise.

> 8.
> I am unable to find a "security considerations" section in NIST SP 800-38A.
> 800-38D at least has a "practical considerations" section, is that meant?
> (Etc., I haven't checked all the references.) In general, I believe a security
> considerations section is most useful where it provides more directed guidance
> instead of saying the equivalent of "here is a textbook".

There are 14 subsections with directed guidance, plus more in the JWS, JWE, and JWK specifications.  If there is other directed guidance you'd like to see added, please supply proposed text.

Having skimmed through it, I agree that 800-30A doesn't contain clear enough security guidance to merit inclusion in the list.  I'll remove it.  If there are other specifications that you'd like to see added or removed, please let me know.

> 8.7 is not clear: is it NOT RECOMMENDED to reuse an entire set of key material
> (including IV), or to reuse any part of it?

I agree that this is ambiguous, as worded.  Its advice seems to be so broad as to be impractical, as never reusing a key means that a new key would have to be redistributed for each encryption, which then requires a key to use for the distribution...  This text came from http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-02#section-8.1, which was incorporated into the document after a working group decision to do so.  Matt Miller, you were the author of this text.  Could you clarify what the intent was?  Thanks.

> Nits/editorial comments:
> 
> 6.3.2.x:
> The constant repetition of »It is represented as the base64url encoding of the
> value's unsigned big endian representation as an octet sequence.
> The octet sequence MUST utilize the minimum number of octets to represent
> the value.« almost ensures that an implementer will stop reading the details
> (well, I did, and I did not write a program to verify the same phrase is used
> everywhere; if any parameter were using a different encoding, that sure would
> be missed).  Why not define another abstraction like base64url and use this?

I did just verify that they are all consistent.  Yes, if you're reading the spec linearly I'm sure it feels repetitive, but if you're an implementer going straight to a definition to implement it, having a complete description all in one place is valuable.  I understand your request but it's not clear to me that this rises to the level that a separate definition that the developer then has to go find is warranted.

> 6.2.3.1: This is not a positive integer?  6.2.3.x mentions this otherwise.

I may not understand this remark.  I'm guessing you're referring to 6.3.2.1 and the fact that the description includes the word "unsigned".  This is there to make it clear that no sign bit will be present in the representation - which is especially important since the high-order bit is always set for "n" and "d" for correctly generated keys.

> 7.1.1
> »Example description« is not a useful example for an "Algorithm Description".
> (Same comment for 7.x.1.)

See the actual registrations in Section 7.1.2 for more useful examples.

> 8.3:
> s/because it/because it is/

Good catch

> [sec1]
> (Given the date, this is probably referencing V2.0 of this spec.)

Hmmm - the version I have cached locally came from http://www.secg.org/collateral/sec1_final.pdf and is dated September 20, 2000.  But the site appears to be down at present.  The version referenced by Wikipedia at http://www.secg.org/download/aid-385/sec1_final.pdf is missing too. http://secg.org/download/aid-780/sec1-v2.pdf is missing too.  Can you point me to a good link?

RFC 5915 includes this reference:

   [SECG1]    Standards for Efficient Cryptography Group (SECG), "SEC 1:
              Elliptic Curve Cryptography", Version 2.0, May 2009.

Worst comes to worst, I'll either reference that or explicitly reference the 1.0 version.  But if I'm going to reference the 2.0 version, I'd like to be able to read a copy so that I can verify that the way we're using it is consistent with the actual spec, including the section numbers.

> [usascii]
> The reference to ANSI X3.4:1986 should probably be replaced by a reference to
> RFC 20.  There is little reason to reference a somewhat hard to obtain external
> document ($60!) when we have an RFC about the same subject.

OK

> (Tables in Appendix A need some formatting.)

Agreed.  It's on my to-do list.  Jim Schaad recently told me to "Add a width attribute to the ttcol with either "digits" (for fixed width) or "digits%" (for percent width) to the column in question".  I plan to give it a try.

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

				Thanks again,
				-- Mike

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Oct 2014 11:54:50 +0200

Hi Mike,

thanks for getting to this review — I don’t envy you for this herculean job.
A few more comments/clarifications inline below.

Grüße, Carsten

> I'll plan on adding a reference to RFC 2315 for this.

That would work (section reference would be 10.3)
Alternatively, you could reference RFC 5652 (section 6.3), which is an Internet Standard (STD70).

> Should this be changed to "the PKCS #7 padding bytes are checked and then removed”?

I think it is good to alert the reader to this need.

> A discussion happened on the JOSE thread "JWK Elliptic Curve key representations and new curves".  The conclusion suggested by Richard Barnes and seconded by Stephen Farrell was to table defining a…

Right, I didn’t want to anticipate that discussion; I would be happy if it didn’t appear that the avenue for any evolution on point compression/compact points were closed.

> Conflicts are avoided using the IANA JSON Web Key Elliptic Curve registry defined in Section 7.6.

Oh, but that’s not what the text says.  I read this as a general license to use random locally defined crv values.  Maybe the need for registration needs to be clarified.

> Consumers may choose to accept keys that don't include all the CRT parameters.  Given that they can be computed from "n", "e", and "d" and sometimes they're not available, a previous reviewer had asked this language about consumers to be included.  It's a case of "Be conservative in what you send, be liberal in what you accept”.  

[I’m not inserting my usual rant here that this bon mot may apply to implementations, but never to specifications.]

> It's not clear to me that there's any value in relaxing the requirements on producers.

Well, if the producer MUST send “all of the others” if “any of the other” parameters are present, it is not clear to me what the point of "MAY choose
   to accept an RSA private key that does not contain a complete set of
   the private key parameters other than “d”” is other than enabling producers to send just that.
(More importantly, it is not clear when a producer should be taking that license.)

> It is expected that the designated experts will be appointed, in part, for their cryptographic expertise.

There has been more discussion about the requirements levels here that I don’t want to repeat.
My comment here was that a DE (even with the best crypto knowledge) is in a hard place updating the consensus about *desirability of implementation* — there are more aspects to this than the technical ones.

> Having skimmed through it, I agree that 800-30A doesn't contain clear enough security guidance to merit inclusion in the list.  I'll remove it.  If there are other specifications that you'd like to…

This was more of a general comment that “Here is a reference to a textbook” type security considerations are less useful than specific, directed references.  I haven’t checked all those referenced documents, so I’m not in a position to recommend changes here.  Maybe something for a checklist to apply to the next security spec.

> I did just verify that they are all consistent.  Yes, if you're reading the spec linearly I'm sure it feels repetitive, but if you're an implementer going straight to a definition to implement it,…

My point was corroborated by the tiny error Richard found.  Repeating the same information again and again drowns out the important information.  A single paragraph at the end of 6.3’s intro of the form:

   Each of the positive integer parameters defined in this section 
   is represented as the base64url encoding
   of the value's unsigned big endian representation as an octet
   sequence.  The octet sequence MUST utilize the minimum number of
   octets to represent the value.

Note that the repetitive text already has a reference that needs to be looked up in that it uses the term "base64url encoding”, which has a slightly refined meaning here from that in RFC 4648.  So an even better way to handle this would be to add a new term “posint encoding” or some such to section 1.1,  turning e.g. the entirety of 6.3.2.2 into

           The "p" (first prime factor) member contains the first prime factor, in POSINT encoding.

> I may not understand this remark.  I'm guessing you're referring to 6.3.2.1 and the fact that the description includes the word "unsigned".  This is there to make it clear that no sign bit will be…

(Sorry, this is indeed about 6.3.2.x, not 6.2.3.x.)
That was not what I meant:  All 6.3.2.x have the form »The "p" (first prime factor) member contains the first prime factor, a positive integer.«
6.3.2.1 does not have the “, a positive integer”, but I can’t see a reason for that (d clearly cannot be zero, and it is still an unsigned value).
This is likely to confuse an implementer that reads this text closely.
(And I’m offering the fact that you are overlooking that inconsistency as another corroboration of my previous point…)

> See the actual registrations in Section 7.1.2 for more useful examples.

Maybe just take out the not so useful examples in 7.x.1?

> Hmmm - the version I have cached locally came from http://www.secg.org/collateral/sec1_final.pdf and is dated September 20, 2000.  But the site appears to be down at present.  The version reference…

I just had a look and embarrassingly found that the copy I’m using comes from the personal space of a researcher:
http://perso.univ-rennes1.fr/sylvain.duquesne/master/standards/sec1-v2.pdf
Not very satisfying as a reference.

>              Elliptic Curve Cryptography", Version 2.0, May 2009.

That looks good: We don’t need a URL, as long as we are certain which version we are referencing.

---

From: Mike Jones <[email-masked]>
Date: Thu, 16 Oct 2014 16:52:37 +0000

Replies to your replies are inline below.  Thanks again for your thoughtful and detailed review.

				-- Mike

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Wednesday, October 15, 2014 2:55 AM
> To: Mike Jones
> Cc: [email-masked]; draft-ietf-jose-json-web-
> [email-masked]; Matt Miller; [email-masked]; [email-masked]
> Subject: Re: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-
> algorithms-33
> 
> Hi Mike,
> 
> thanks for getting to this review - I don't envy you for this herculean job.
> > Thanks for your review, Carsten.  I apologize for not responding to it until
> now.  It had gotten sorted into a folder and I wasn't aware of it until Kathleen
> brought it to my attention.  Replies are inline below...
> >
> >> From: apps-discuss [mailto:[email-masked]] On Behalf
> >> Of Carsten Bormann
> >> I have been selected as the Applications Area Directorate reviewer
> >> for this draft (for background on appsdir, please see
> >> Please resolve these comments along with any other Last Call comments
> >> you may receive. Please wait for direction from your document
> >> shepherd or AD before posting a new version of the draft.
> >>
> >> Summary: This draft is ready for publication as a standards track
> >> RFC, with a few nits corrected.
> >>
> >> However, some additional editorial improvements might improve the
> >> security outcome when it is referenced by application developers.
> >>
> >> Major issues: None.
> >>
> >> Minor issues:
> >>
> >> 5.2:
> That would work (section reference would be 10.3) Alternatively, you could
> reference RFC 5652 (section 6.3), which is an Internet Standard (STD70).
> 
> >> 5.2.2.2
> >> Is the intention that the sentence containing "point compression is
> >> not supported" also applies to any future registered value of "crv"?
> >> A similar comment applies to other specifications in 6.2.1.x, e.g.,
> >> the reference to SEC1 representation to x and y.
> >
> > It would apply to any future curves registered that use the "x", "y" point
> representation.  Others could define new key types that use a different
> representation or we could refine the definition of "kty":"EC" to make the
> representation specific to the "crv" value.
> >
> > A discussion happened on the JOSE thread "JWK Elliptic Curve key
> representations and new curves".  The conclusion suggested by Richard Barnes
> and seconded by Stephen Farrell was to table defining any new key
> representations for new elliptic curves until the CRFG recommendations to TLS
> have been made.  That ended the discussion for now.
> 
> Right, I didn't want to anticipate that discussion; I would be happy if it didn't
> appear that the avenue for any evolution on point compression/compact points
> were closed.

I can add language saying that future curve registrations may use different parameters to represent the curve value.  That may get a little convoluted because currently it's the "kty" that determines which parameters are used.  But I agree with trying to accommodate new key representations for new curves.

> >> used, provided they are understood by implementations using that
> >> Elliptic Curve key.« How are conflicts between such implementation
> >> defined values and future registered values handled?
> >
> Oh, but that's not what the text says.  I read this as a general license to use
> random locally defined crv values.  Maybe the need for registration needs to be
> clarified.

I'll delete the sentence "Additional 'crv' values MAY be used, provided they are understood by implementations using that Elliptic Curve key."  The registry is already talked about in the previous sentences.

> > "d" is REQUIRED.  The others SHOULD be included, and if any are included, the
> others MUST be included.  Those are requirements on producers.
> >
> > Consumers may choose to accept keys that don't include all the CRT
> parameters.  Given that they can be computed from "n", "e", and "d" and
> sometimes they're not available, a previous reviewer had asked this language
> about consumers to be included.  It's a case of "Be conservative in what you
> send, be liberal in what you accept".
> 
> [I'm not inserting my usual rant here that this bon mot may apply to
> implementations, but never to specifications.]
> 
> Well, if the producer MUST send "all of the others" if "any of the other"
> parameters are present, it is not clear to me what the point of "MAY choose
>    the private key parameters other than "d"" is other than enabling producers to
> send just that.

I can delete the sentence " The consumer of a JWK MAY choose to accept an RSA private key that does not contain a complete set of the private key parameters..."

> >> 7.1:
> >> It is interesting that a mere registration (vetted only by a DE) can
> >> change the IETF consensus base specifications by making an algorithm
> "Required".
> >
> There has been more discussion about the requirements levels here that I don't
> want to repeat.
> My comment here was that a DE (even with the best crypto knowledge) is in a
> hard place updating the consensus about *desirability of implementation* -
> there are more aspects to this than the technical ones.

Thinking about this some more, I agree that "Required" is a special case.  I'm thinking that a reasonable safeguard for this case is to require that approval of both a designated expert and a sitting security area director be required to make an algorithm "Required" or to change it from "Required" to something else.  Kathleen and Carsten, would that work for you?

> >> (Etc., I haven't checked all the references.) In general, I believe a
> >> security considerations section is most useful where it provides more
> >> directed guidance instead of saying the equivalent of "here is a textbook".
> >
> > There are 14 subsections with directed guidance, plus more in the JWS, JWE,
> and JWK specifications.  If there is other directed guidance you'd like to see
> added, please supply proposed text.
> >
> > Having skimmed through it, I agree that 800-30A doesn't contain clear enough
> security guidance to merit inclusion in the list.  I'll remove it.  If there are other
> specifications that you'd like to see added or removed, please let me know.
> 
> This was more of a general comment that "Here is a reference to a textbook"
> type security considerations are less useful than specific, directed references.  I
> haven't checked all those referenced documents, so I'm not in a position to
> recommend changes here.  Maybe something for a checklist to apply to the next
> security spec.
> 
> >
> >> 8.7 is not clear: is it NOT RECOMMENDED to reuse an entire set of key
> >> material (including IV), or to reuse any part of it?
> >
> > I agree that this is ambiguous, as worded.  Its advice seems to be so broad as
> to be impractical, as never reusing a key means that a new key would have to be
> redistributed for each encryption, which then requires a key to use for the
> distribution...  This text came from http://tools.ietf.org/html/draft-miller-jose-
> jwe-protected-jwk-02#section-8.1, which was incorporated into the document
> after a working group decision to do so.  Matt Miller, you were the author of
> this text.  Could you clarify what the intent was?  Thanks.
> >
> >> Nits/editorial comments:
> >>
> >> 6.3.2.x:
> >> The constant repetition of »It is represented as the base64url
> >> encoding of the value's unsigned big endian representation as an octet
> sequence.
> >> The octet sequence MUST utilize the minimum number of octets to
> >> represent the value.« almost ensures that an implementer will stop
> >> reading the details (well, I did, and I did not write a program to
> >> verify the same phrase is used everywhere; if any parameter were
> >> using a different encoding, that sure would be missed).  Why not define
> another abstraction like base64url and use this?
> >
> > I did just verify that they are all consistent.  Yes, if you're reading the spec
> linearly I'm sure it feels repetitive, but if you're an implementer going straight to
> a definition to implement it, having a complete description all in one place is
> valuable.  I understand your request but it's not clear to me that this rises to the
> level that a separate definition that the developer then has to go find is
> warranted.
> 
> My point was corroborated by the tiny error Richard found.  Repeating the same
> information again and again drowns out the important information.  A single
> paragraph at the end of 6.3's intro of the form:
> 

OK - I'll see what I can do in this regard.  Editorially, it's a little bit complicated because there are different subsections for public and private key parameters.

> Note that the repetitive text already has a reference that needs to be looked up
> in that it uses the term "base64url encoding", which has a slightly refined
> meaning here from that in RFC 4648.  So an even better way to handle this
> would be to add a new term "posint encoding" or some such to section 1.1,
> turning e.g. the entirety of 6.3.2.2 into
> 
> > I may not understand this remark.  I'm guessing you're referring to 6.3.2.1 and
> the fact that the description includes the word "unsigned".  This is there to make
> it clear that no sign bit will be present in the representation - which is especially
> important since the high-order bit is always set for "n" and "d" for correctly
> generated keys.
> 
> (Sorry, this is indeed about 6.3.2.x, not 6.2.3.x.) That was not what I meant:  All
> 6.3.2.x have the form »The "p" (first prime factor) member contains the first
> prime factor, a positive integer.«
> 6.3.2.1 does not have the ", a positive integer", but I can't see a reason for that
> (d clearly cannot be zero, and it is still an unsigned value).
> (And I'm offering the fact that you are overlooking that inconsistency as another
> corroboration of my previous point.)

I can delete the unnecessary phrase "a positive integer", subject to how it does or doesn't fit into the edit above that you asked for.

> Maybe just take out the not so useful examples in 7.x.1?

All other registration templates that I have seen include examples of all parameters.  This is only one of the parameters in the template, and all need to be retained.  Would you be happier with the e.g. text "Example algorithm"?

> > Hmmm - the version I have cached locally came from
> http://www.secg.org/collateral/sec1_final.pdf and is dated September 20,
> 2000.  But the site appears to be down at present.  The version referenced by
> Wikipedia at http://www.secg.org/download/aid-385/sec1_final.pdf is missing
> too. http://secg.org/download/aid-780/sec1-v2.pdf is missing too.  Can you
> point me to a good link?
> 
> I just had a look and embarrassingly found that the copy I'm using comes from
> the personal space of a researcher:
> That looks good: We don't need a URL, as long as we are certain which version
> we are referencing.
> 
> > Worst comes to worst, I'll either reference that or explicitly reference the 1.0
> version.  But if I'm going to reference the 2.0 version, I'd like to be able to read a
> copy so that I can verify that the way we're using it is consistent with the actual
> spec, including the section numbers.
> >
> >> [usascii]
> >> The reference to ANSI X3.4:1986 should probably be replaced by a
> >> reference to RFC 20.  There is little reason to reference a somewhat
> >> hard to obtain external document ($60!) when we have an RFC about the
> same subject.
> >
> > OK
> >
> > Agreed.  It's on my to-do list.  Jim Schaad recently told me to "Add a width
> attribute to the ttcol with either "digits" (for fixed width) or "digits%" (for
> percent width) to the column in question".  I plan to give it a try.
> >

---

From: Mike Jones <[email-masked]>
Date: Thu, 16 Oct 2014 17:09:05 +0000

Adding one more reply below - this time new proposed text from Matt Miller...

-----Original Message-----
From: Mike Jones 
Sent: Thursday, October 16, 2014 9:53 AM
To: 'Carsten Bormann'
Cc: [email-masked]; [email-masked]; Matt Miller; [email-masked]; [email-masked]
Subject: RE: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-algorithms-33

				-- Mike

> now.  It had gotten sorted into a folder and I wasn't aware of it 
> until Kathleen brought it to my attention.  Replies are inline below...
> >
> >> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirec
> >> to
> >> rate
> >> ).
> >>
> >> Please resolve these comments along with any other Last Call 
> >> comments you may receive. Please wait for direction from your 
> >> document shepherd or AD before posting a new version of the draft.
> >>
> That would work (section reference would be 10.3) Alternatively, you 
> could reference RFC 5652 (section 6.3), which is an Internet Standard (STD70).
> 
> >> 5.2.2.2
> > Should this be changed to "the PKCS #7 padding bytes are checked and 
> > then
> removed"?
> 
> representation.  Others could define new key types that use a 
> different representation or we could refine the definition of 
> "kty":"EC" to make the representation specific to the "crv" value.
> >
> representations and new curves".  The conclusion suggested by Richard 
> Barnes and seconded by Stephen Farrell was to table defining any new 
> key representations for new elliptic curves until the CRFG 
> recommendations to TLS have been made.  That ended the discussion for now.
> 
> Right, I didn't want to anticipate that discussion; I would be happy 
> if it didn't appear that the avenue for any evolution on point 
> compression/compact points were closed.

> > Conflicts are avoided using the IANA JSON Web Key Elliptic Curve 
> > registry
> defined in Section 7.6.
> 
> Oh, but that's not what the text says.  I read this as a general 
> license to use random locally defined crv values.  Maybe the need for 
> registration needs to be clarified.

> parameters.  Given that they can be computed from "n", "e", and "d" 
> and sometimes they're not available, a previous reviewer had asked 
> this language about consumers to be included.  It's a case of "Be 
> conservative in what you send, be liberal in what you accept".
> 
> > It's not clear to me that there's any value in relaxing the 
> > requirements on
> producers.
> 
>    the private key parameters other than "d"" is other than enabling 
> producers to send just that.

> >> 7.1:
> >> It is interesting that a mere registration (vetted only by a DE) 
> >> can change the IETF consensus base specifications by making an 
> >> algorithm
> "Required".
> >
> > It is expected that the designated experts will be appointed, in 
> > part, for their
> cryptographic expertise.
> 
> There has been more discussion about the requirements levels here that 
> I don't want to repeat.
> My comment here was that a DE (even with the best crypto knowledge) is 
> in a hard place updating the consensus about *desirability of 
> implementation* - there are more aspects to this than the technical ones.

> >> (Etc., I haven't checked all the references.) In general, I believe 
> >> a security considerations section is most useful where it provides 
> >> more directed guidance instead of saying the equivalent of "here is a textbook".
> >
> and JWK specifications.  If there is other directed guidance you'd 
> like to see added, please supply proposed text.
> >
> security guidance to merit inclusion in the list.  I'll remove it.  If 
> there are other specifications that you'd like to see added or removed, please let me know.
> 
> type security considerations are less useful than specific, directed 
> references.  I haven't checked all those referenced documents, so I'm 
> not in a position to recommend changes here.  Maybe something for a 
> checklist to apply to the next security spec.
> 
> >
> >> 8.7 is not clear: is it NOT RECOMMENDED to reuse an entire set of 
> >> key material (including IV), or to reuse any part of it?
> >
> to be impractical, as never reusing a key means that a new key would 
> have to be redistributed for each encryption, which then requires a 
> key to use for the distribution...  This text came from 
> http://tools.ietf.org/html/draft-miller-jose-
> jwe-protected-jwk-02#section-8.1, which was incorporated into the 
> document after a working group decision to do so.  Matt Miller, you 
> were the author of this text.  Could you clarify what the intent was?  Thanks.

Matt proposed the following revised text.  I agree that this is significantly clearer and more actionable than the previous version:

It is NOT RECOMMENDED to reuse the same entire set of key material (Key Encryption Key, Content Encryption Key, Initialization Vector,
etc.) to encrypt multiple JWK or JWK Set objects, or to encrypt the same JWK or JWK Set object multiple times.  One suggestion for preventing re-use is to always generate at least one piece of key material for each encryption operation (e.g., a new Content Encryption Key, a new Initialization Vector, and/or a new PBES2 Salt), based on the considerations noted in this document as well as from RFC 4086 [RFC4086].

> linearly I'm sure it feels repetitive, but if you're an implementer 
> going straight to a definition to implement it, having a complete 
> description all in one place is valuable.  I understand your request 
> but it's not clear to me that this rises to the level that a separate 
> definition that the developer then has to go find is warranted.
> 
> My point was corroborated by the tiny error Richard found.  Repeating 
> the same information again and again drowns out the important 
> information.  A single paragraph at the end of 6.3's intro of the form:
> 

> Note that the repetitive text already has a reference that needs to be 
> looked up in that it uses the term "base64url encoding", which has a 
> slightly refined meaning here from that in RFC 4648.  So an even 
> better way to handle this would be to add a new term "posint encoding" 
> or some such to section 1.1, turning e.g. the entirety of 6.3.2.2 into
> 
> the fact that the description includes the word "unsigned".  This is 
> there to make it clear that no sign bit will be present in the 
> representation - which is especially important since the high-order 
> bit is always set for "n" and "d" for correctly generated keys.
> 
> (Sorry, this is indeed about 6.3.2.x, not 6.2.3.x.) That was not what 
> I meant:  All 6.3.2.x have the form »The "p" (first prime factor) 
> member contains the first prime factor, a positive integer.«
> 6.3.2.1 does not have the ", a positive integer", but I can't see a 
> reason for that (d clearly cannot be zero, and it is still an unsigned value).
> (And I'm offering the fact that you are overlooking that inconsistency 
> as another corroboration of my previous point.)

> http://www.secg.org/collateral/sec1_final.pdf and is dated September 
> 20, 2000.  But the site appears to be down at present.  The version 
> referenced by Wikipedia at 
> http://www.secg.org/download/aid-385/sec1_final.pdf is missing too. 
> http://secg.org/download/aid-780/sec1-v2.pdf is missing too.  Can you point me to a good link?
> 
> I just had a look and embarrassingly found that the copy I'm using 
> comes from the personal space of a researcher:
> That looks good: We don't need a URL, as long as we are certain which 
> version we are referencing.
> 
> version.  But if I'm going to reference the 2.0 version, I'd like to 
> be able to read a copy so that I can verify that the way we're using 
> it is consistent with the actual spec, including the section numbers.
> >
> >> [usascii]
> >> reference to RFC 20.  There is little reason to reference a 
> >> somewhat hard to obtain external document ($60!) when we have an 
> >> RFC about the
> same subject.
> >
> > OK
> >
> attribute to the ttcol with either "digits" (for fixed width) or 
> "digits%" (for percent width) to the column in question".  I plan to give it a try.
> >

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 16 Oct 2014 16:27:17 -0400

I'm just chiming in on one section, the designated review requirements
right now.

On Thu, Oct 16, 2014 at 1:09 PM, Mike Jones <[email-masked]>
wrote:

> Cc: [email-masked];
> [email-masked]; Matt Miller;
> [email-masked]; [email-masked]
> I can add language saying that future curve registrations may use
> different parameters to represent the curve value.  That may get a little
> convoluted because currently it's the "kty" that determines which
> parameters are used.  But I agree with trying to accommodate new key
> representations for new curves.
>
> > >> 6.2.1.1
> I'll delete the sentence "Additional 'crv' values MAY be used, provided
> they are understood by implementations using that Elliptic Curve key."  The
> registry is already talked about in the previous sentences.
>
> > >> 6.3.2:
> I can delete the sentence " The consumer of a JWK MAY choose to accept an
> RSA private key that does not contain a complete set of the private key
> parameters..."
>
> > >> 7.1:
> Thinking about this some more, I agree that "Required" is a special case.
> I'm thinking that a reasonable safeguard for this case is to require that
> approval of both a designated expert and a sitting security area director
> be required to make an algorithm "Required" or to change it from "Required"
> to something else.  Kathleen and Carsten, would that work for you?
>

The AD is in the appeals line, so that doesn't quite work:
http://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-08#section-5.2.1

I think you need to leave it as-is with a set of DEs.

Thanks,
Kathleen

> Matt proposed the following revised text.  I agree that this is
> significantly clearer and more actionable than the previous version:
>
> It is NOT RECOMMENDED to reuse the same entire set of key material (Key
> Encryption Key, Content Encryption Key, Initialization Vector,
> etc.) to encrypt multiple JWK or JWK Set objects, or to encrypt the same
> JWK or JWK Set object multiple times.  One suggestion for preventing re-use
> is to always generate at least one piece of key material for each
> encryption operation (e.g., a new Content Encryption Key, a new
> Initialization Vector, and/or a new PBES2 Salt), based on the
> considerations noted in this document as well as from RFC 4086 [RFC4086].
>
> > >> Nits/editorial comments:
> > >>
> > >> 6.3.2.x:
> OK - I'll see what I can do in this regard.  Editorially, it's a little
> bit complicated because there are different subsections for public and
> private key parameters.
>
> I can delete the unnecessary phrase "a positive integer", subject to how
> it does or doesn't fit into the edit above that you asked for.
>
> > >> 7.1.1
> All other registration templates that I have seen include examples of all
> parameters.  This is only one of the parameters in the template, and all
> need to be retained.  Would you be happier with the e.g. text "Example
> algorithm"?
>
> > >> 8.3:

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 16 Oct 2014 17:15:04 -0400

On Thu, Oct 16, 2014 at 4:27 PM, Kathleen Moriarty <
[email-masked]> wrote:

>> Thinking about this some more, I agree that "Required" is a special
>> case.  I'm thinking that a reasonable safeguard for this case is to require
>> that approval of both a designated expert and a sitting security area
>> director be required to make an algorithm "Required" or to change it from
>> "Required" to something else.  Kathleen and Carsten, would that work for
>> you?
>>
>

Please do change the text to require more than one DE.

-- 

Best regards,
Kathleen

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Oct 2014 00:27:41 +0200

Hi Mike,

without going into a line-by-line, these look like good ways forward.

Re the registration example descriptions: What would, for somebody registering a new algorithm, help most in understanding your intentions for this field?  I think just picking one of the descriptions from the initial registrations would work here, say "HMAC using SHA-256” (or even "RSAES OAEP using SHA-256 and MGF1 with SHA-256”).

Grüße, Carsten

---

From: Mike Jones <[email-masked]>
Date: Sat, 18 Oct 2014 01:34:04 +0000

The proposed resolutions below have been applied to the -35 draft.

				Thanks again,
				-- Mike

-----Original Message-----
From: Mike Jones
Sent: Thursday, October 16, 2014 9:53 AM
To: 'Carsten Bormann'
Cc: [email-masked]; [email-masked]; Matt Miller; [email-masked]; [email-masked]
Subject: RE: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-algorithms-33

				-- Mike