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

[Mike Jones <[e-mail]>]

Responding only to the DISCUSS portions for now…



-----Original Message-----
From: Pete Resnick [mailto:[e-mail]]
Sent: Wednesday, October 01, 2014 8:04 PM
To: The IESG
Cc: [e-mail]; [e-mail]
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.



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.



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.



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



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.



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?



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.



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?



   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?



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?



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.



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



       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.



6.2: s/MUST be/is