On Thu, Oct 2, 2014 at 11:25 AM, Mike Jones <[email protected]> wrote:
> Responding only to the DISCUSS portions for now… > > > > -----Original Message----- > From: Pete Resnick [mailto:[email protected]] > Sent: Wednesday, October 01, 2014 8:04 PM > To: The IESG > Cc: [email protected]; > [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. > > We'll need to address this and it may be agreeable to move these to recommendations, but let's run through this and respond in detail. Thanks. > > > 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 > > > > > -- Best regards, Kathleen
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
