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