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

[Kathleen Moriarty <[e-mail]>]

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 <[e-mail]> 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:[e-mail]] On Behalf Of Mike Jones
>> Sent: Saturday, October 04, 2014 6:07 PM
>> To: Pete Resnick; The IESG
>> Cc: [e-mail]; [e-mail]; draft-ietf-jose-json-web-
>> [e-mail]
>> 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:[e-mail]]
>> > Sent: Wednesday, October 01, 2014 8:04 PM
>> > To: The IESG
>> > Cc: [e-mail]; draft-ietf-jose-json-web-
>> > [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.  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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose



-- 

Best regards,
Kathleen