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

[Kathleen Moriarty <[e-mail]>]

On Thu, Oct 2, 2014 at 11:25 AM, Mike Jones <[e-mail]>
wrote:

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