Subject: Re: [jose] Pete Resnick's Abstain on draft-ietf-jose-json-web-algorithms-37: (with COMMENT)

From: Mike Jones <[email-masked]>
Date: Wed, 10 Dec 2014 03:09:01 +0000

Thanks for taking the time to provide these comments, Pete.  Descriptions of the actions that were taken in the -38 drafts in response to them are included inline below.

> -----Original Message-----
> From: Pete Resnick [mailto:[email-masked]]
> Sent: Tuesday, December 02, 2014 8:36 PM
> To: The IESG
> Cc: [email-masked]; draft-ietf-jose-json-web-
> [email-masked]
> Subject: Pete Resnick's Abstain on draft-ietf-jose-json-web-algorithms-37:
> (with COMMENT)
> 
> Pete Resnick has entered the following ballot position for
> draft-ietf-jose-json-web-algorithms-37: Abstain
> 
> 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/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I've got some suggestions for improvements below, but overall I cannot
> support this document, so I'm entering an ABSTAIN. I don't think this WG has
> actually fulfilled its charter with regard to this document set. The WG was
> supposed to produce a "JSON syntax that can be used by applications to
> describe secure data objects". I don't believe it did that. Instead, it produced
> a compact serialization for a particular purpose and then backed into a JSON
> syntax. The compact serialization drove the effort and produced IMO a
> substandard JSON serialization. I don't believe that (reliable) interoperable
> implementations of the JSON serialization will be possible using this
> document set. However, there is at least rough consensus that these
> documents are usable as-is, and I don't think there's anything to be gained by
> holding them up any further.
> 
> I hope the WG will adopt some of the remaining comments, but my intention
> is not to discuss this any further. If you wish to address any of the comments
> and need clarification, I'm glad to help with that.
> 
> ------
> 
> 3.1/4.1/5.1/6.1: The implementation requirements do not belong in this
> document. They should be removed.

As previously discussed, Stephen Farrell has stated that he would enter a DISCUSS on interoperability grounds if these requirements were removed.

> 3.2ff: None of these algorithm requirements (using MUSTs) really belong in
> this document. These are requirements for any new crypto algorithm that
> should be documented elsewhere. They are not JOSE specific.

The reasons for these restrictions are now documented, with citations included to authoritative sources behind their inclusion.  For instance, see the new citation of Section 5.3.4 (Security Effect of the HMAC Key) of NIST SP 800-117 [NIST.800-107] and the accompanying explanation.

> 4.8: I think the MUST for UTF-8 is seriously problematic. Because different
> system normalize UTF-8 strings differently, there is no way that just saying
> "MUST use UTF-8" makes for any kind of interoperability unless you go into
> much more detail. I think you should either (a) just say that it is an octet
> string or (b) refer to PRECIS.
> 
> 4.8.1.1: s/UTF-8/ASCII

As discussed in Honolulu, it's not reasonable to restrict human-entered strings to ASCII characters worldwide.  Instead, we're delegating to draft-ietf-precis-saslprepbis to handle this issue, as also discussed in Honolulu.

> 5.2.2.1:
> 
> OLD
>        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;
> 
> NEW
>        MAC_KEY_LEN is the number of octets in MAC_KEY and ENC_KEY_LEN is
>        the number of octets in ENC_KEY.
> 
> OLD
>        The number of octets in the input key K MUST be the sum of
>        MAC_KEY_LEN and ENC_KEY_LEN.
> 
> NEW
>        The number of octets in the input key K MUST be the sum of
>        MAC_KEY_LEN and ENC_KEY_LEN.
> 
> The following is completely redundant:
> 
>        When generating the secondary keys
>        from K, MAC_KEY and ENC_KEY MUST NOT overlap.

Changes were made to address all of these comments, thereby simplifying the text (thanks!) in draft -34.

				Thanks again, Pete!
				-- Mike