Pete, Can you take a look at this one too and see if we can resolve some of the discusses and comments?
Thanks! Kathleen On Tue, Oct 14, 2014 at 8:48 AM, Mike Jones <[email protected]> wrote: > The proposed resolutions below have been incorporated in the -34 drafts. > Plus I deleted the convoluted "MUST not overlap" language that you rightly > took exception to. > > Note that Stephen Farrell stood up for having implementation requirements on > the telechat and in his comments. Also note that Jim Schaad stood up for the > choice of UTF-8 over ASCII, for internationalization reasons. No specific > additional guidance has been proposed in this discussion thread to give to > the designated experts about registering algorithm names - also per Jim's > input. > > Hopefully you will be able to clear your DISCUSSes on that basis. I look > forward to your response. > > Thanks again, > -- Mike > >> -----Original Message----- >> From: jose [mailto:[email protected]] On Behalf Of Mike Jones >> Sent: Saturday, October 04, 2014 6:07 PM >> To: Pete Resnick; The IESG >> Cc: [email protected]; [email protected]; draft-ietf-jose-json-web- >> [email protected] >> Subject: Re: [jose] Pete Resnick's Discuss on draft-ietf-jose-json-web- >> algorithms-33: (with DISCUSS and COMMENT) >> >> Thanks for your review, Pete. I'm adding the working group so they’re aware >> of >> these comments. At Stephen Farrell's request, I'm responding with "> " line >> prefixes on previous thread content. I'm also repeating (and in some cases, >> augmenting) my previous responses to the DISCUSS comments in this >> consolidated response. >> >> > -----Original Message----- >> > From: Pete Resnick [mailto:[email protected]] >> > Sent: Wednesday, October 01, 2014 8:04 PM >> > To: The IESG >> > Cc: [email protected]; draft-ietf-jose-json-web- >> > [email protected] >> > Subject: Pete Resnick's Discuss on >> > draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT) >> > >> > Pete Resnick 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: >> > ---------------------------------------------------------------------- >> > >> > Moving this first one from a comment to a discuss in light of >> > Richard's >> > comment: >> > >> > 3.1/4.1/5.1/6.1: Why are there implementation requirements in this >> document? >> > I am also curious, as Richard is, whether these are going to be used >> > at all, and I'd like to hear the explanation that the WG had for >> > including these. Are implementation requirements for JOSE different >> > from implementation requirements for any other use of signing or >> > encryption for each of these algorithms? Don't we already have a >> > separate general registry of algorithms and their implementation statuses? >> Why are these necessary? >> >> There are implementation requirements so that implementations will actually >> be >> interoperable in practice and not just in theory. This was discussed by the >> working group as issue #10 http://trac.tools.ietf.org/wg/jose/trac/ticket/10 >> and >> the chairs made a call to keep the implementation requirements, based upon >> IESG feedback that MTI features are required to enabling interoperability >> during >> chartering discussions, as well as based upon feedback from some working >> group members. >> >> > 4.6.2: AlgorithmID. UTF-8 has me worried here. It has me more worried >> > in 4.8, but we'll talk about that later. Here, aren't all "enc" and "alg" >> > values US-ASCII anyway? Saying US-ASCII here would solve the problem, >> > so unless you think you're going to have the MötleyCrüe algorithm, >> > perhaps we can avoid any concerns for this case. (My concern is that you >> > can >> have "interesting" >> > UTF-8 strings with ZERO-WIDTH JOINERs and other nonsense that you >> > probably don't mean to address. >> >> Even if people used pathological Unicode characters, the exact-match string >> comparison rules would handle this OK. In practice, what I think we should >> do is >> provide guidance in the IANA registry instructions that only reasonable, >> displayable Unicode character sequences be registered. I’m reluctant to tell >> people using non-US character sets that they can’t use printable glyphs from >> their own languages. Do people have a suggestion what language this guidance >> should contain? >> >> > 4.8: >> > >> > The PBES2 password input is an >> > octet sequence; if the password to be used is represented as a text >> > string rather than an octet sequence, the UTF-8 encoding of the text >> > string MUST be used as the octet sequence. >> > >> > This one worries me a lot. It's one thing to say that the password is >> > an octet sequence and the application above is responsible for >> > collecting it from the user and passing it in the correct form. But to >> > say down here in the guts that it MUST be UTF-8 brings up all sorts of >> > ugly questions regarding normalization. I don't think you want to >> > touch this with a 10-foot-pole. I certainly thing you want to stay away >> > from >> that MUST. >> >> To achieve interoperation, some encoding has to be specified, and UTF-8 seems >> like the best choice. Restricting human-visible passwords to ASCII isn’t >> reasonable for most cultures. >> >> > 4.8.1.1: Same as 4.6.2. >> >> Same answer. >> >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > For the life of me, I can't figure out why this document set uses the >> > terminology "JSON Web Foo". Seems like buzzword nonsense. I would have >> > much preferred "JOSE Foo" for each one. >> >> The etymology of the term "JSON Web Token" is that the "JSON Web Token" >> was conceived of as a JSON-based replacement for the "Simple Web Token". >> The relationship between JWTs and SWTs is described in Appendix C of the JWT >> spec. When the signature encoding description was split out of the JWT spec, >> the natural name was "JSON Web Signature". The JWE, JWK, and JWA names >> soon followed. >> >> > 3.2: >> > >> > A key of the same size as the hash output (for instance, 256 bits for >> > "HS256") or larger MUST be used with this algorithm. >> > >> > Is this specific to JOSE, or is this a general requirement for use of >> > SHA-2? If the latter, a reference would be better than a MUST in here. >> >> This is an additional requirement imposed by the JOSE use of this algorithm. >> (I >> believe this requirement was proposed by ekr.) >> >> > [There are many things in the document that look like algorithm >> > requirements and not JOSE requirements. I've noted a few more below, >> > but these should be looked for generally. If something is part of the >> > definition of the algorithm and documented elsewhere, no need to have >> > requirements language, let alone a description of how to run the >> > algorithm, in this document; that should be an external reference.] >> >> Another example is that we require 2048 bit keys or larger for RSA >> signatures. >> This is informed by the NIST algorithm usage requirements. Per ekr's input >> during the BoF that led to JOSE, there's no point in allowing the use of >> deprecated algorithms or key sizes in a new cryptographic format. >> >> > In the 5th paragraph (the one right after the table), strike >> > everything after the first sentence. Decoding and encoding are things >> > that are JWS specific and should not be in this document. >> >> In numerous cases, this document is intentionally about how JOSE uses these >> algorithms and not purely about abstract algorithms. The particular text you >> cite is there to help developers get the validation right, and explains two >> ways >> that it can be correctly coded. Another example of where the JWA document is >> intentionally JOSE specific is that the PBES2 algorithms define Header >> Parameter >> values. >> >> > 3.3/3.5/4/2/4.3: >> > >> > A key of size 2048 bits or larger MUST be used with this algorithm. >> > >> > Is this specific to JOSE, or is this a general requirement for use of RSA? >> >> This is informed by NIST's current guidance on how to use RSA. >> >> > 3.6: This section seems to be for the JWS document, not this one. If >> > you want to define the "None" algorithm, go ahead and do that, but >> > describing its use in JWS doesn't belong here. >> >> This section defines the algorithm identifier "none" and its meaning. An >> early >> working group decision was that all algorithm identifiers would reside in >> the JWA >> document and not the JWA, JWE, or JWK specifications. >> >> > 4.6: >> > >> > A new ephemeral public key value MUST be generated for each key >> > agreement operation. >> > >> > Again, specific to JOSE, or requirement of ECDH-ES? >> >> I believe that this is a JOSE requirement which may be more conservative than >> strictly required, but was included to err on the side of both security and >> simplicity. Without this simple requirement, developers would be likely to >> use >> ECDH-ES insecurely. >> >> > In Direct Key Agreement mode, the output of the Concat KDF MUST be a >> > key of the same length as that used by the "enc" algorithm. >> > >> > and >> > >> > In Key Agreement with Key Wrapping mode, the output of the Concat KDF >> > MUST be a key of the length needed for the specified key wrapping >> > algorithm. >> > >> > s/MUST/will? >> >> MUST. The caller of Concat passes the desired length as an input parameter. >> >> > 4.6.1.2/4.6.1.3: These are not very well defined, and it's not clear >> > why they need to be base64ed. What are they? >> >> These are parameters of the Concat KDF. Their primary definitions are in >> Section 5.8.1 of [NIST.800-56A]. They need to be base64url encoded because >> JSON can't represent arbitrary binary octet sequences. >> >> > 5.2.2.1: >> > >> > Here we denote the number of octets in the MAC_KEY as >> > MAC_KEY_LEN, and the number of octets in ENC_KEY as >> > ENC_KEY_LEN; >> > >> > Oh, dear. That's a pretty convoluted way of saying (I think) >> > "MAC_KEY_LEN is the number of octets in MAC_KEY and ENC_KEY_LEN is the >> > number of octets in ENC_KEY." If you mean something different, you best >> explain. >> >> Yes, that's what is meant. I'll try to reword this to use less convoluted >> language. >> >> > the values of these parameters are specified by the Authenticated >> > Encryption algorithms in Sections 5.2.3 through 5.2.5. >> > The number of octets in the input key K MUST be the sum of >> > MAC_KEY_LEN and ENC_KEY_LEN. >> > >> > "MUST"? Do you mean "is"? >> >> Ironically, in his secdir review, Charlie Kaufman requested that the >> language be >> changed from "is" to "MUST be", hence the present wording. He wrote: >> >> Section 5.2.2.1 says "The number of octets in the input key K is the sum of >> MAC_KEY_LEN and ENC_KEY_LEN." I believe it would be better to say >> something like "MUST BE the sum". The text goes on to say that the two keys >> must not overlap, but it is also important that an implementation not >> tolerate a >> gap between the two keys is a too large key is provided. >> >> > When generating the secondary keys >> > from K, MAC_KEY and ENC_KEY MUST NOT overlap. >> > >> > Isn't that completely redundant? If length of K is the sum of >> > MAC_KEY_LEN and ENC_KEY_LEN, then MAC_KEY and ENC_KEY *can't* >> overlap. >> >> This text was written by David McGrew. I agree that it's redundant (although >> correct), but I retained it on the assumption that he put it there for a >> reason. >> >> > 6.2: s/MUST be/is >> >> OK >> >> Thanks again, >> -- Mike >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose -- Best regards, Kathleen _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
