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

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 3 Nov 2014 16:20:48 -0500

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

-- 

Best regards,
Kathleen

---

From: Pete Resnick <[email-masked]>
Date: Mon, 3 Nov 2014 19:47:57 -0600

> the discusses and comments?

I'm on it. Long flight tomorrow and I should be able to go through 
everything.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Mike Jones <[email-masked]>
Date: Thu, 20 Nov 2014 01:33:31 +0000

Algorithm names are now restricted to ASCII characters, as of the -37 drafts.

				-- Mike

-----Original Message-----
From: Mike Jones [mailto:[email-masked]] 
Sent: Tuesday, October 14, 2014 5:48 AM
To: Pete Resnick; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Pete Resnick's Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)

				Thanks again,
				-- Mike

> Cc: [email-masked]; [email-masked]; 
> draft-ietf-jose-json-web- [email-masked]
> 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,
> > 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
> 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"
> 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:
> >
> > 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.
> 
> > 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 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:
> >
> > 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.)
> 
> > 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.]
> 
> 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.
> 
> > 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:
> >
> 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:
> >
> 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.
> 
> 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:
> >
> > "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.
> 
> 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.
> 
> 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
>