Subject: [Json] Stephen Farrell's No Objection on draft-ietf-json-i-json-05: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Mon, 19 Jan 2015 15:28:39 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-json-i-json-05: No Objection

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-json-i-json/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- 2.1: I've no idea what Surrogate or Noncharacter
means here - a precise reference would be good for me.
And the examples don't help me. So I agree with 
Barry's discuss.

- 4.3: Did the WG discuss whether to require/encourage
inclusion/exclusion of 00 values and timezones in
times? E.g. is there a preference for 20150119T2304Z or
20150119T230400Z which represent the same time. 

- 4.3: I'm also a bit surprised you don't say that UTC
is the default TZ. I think those time rules do help
interoperability so defining defaults would have been
an improvement. Why is that? (I don't think 3339 does
that or does it?)

- 4.4: I don't recall them so have had to track down
the difference between base64 and base64url and check
I'm using the right APIs over and over.  That might be
because I only write code sporadically (and badly:-)
and forget stuff in between, but an example of the
difference (possibly parenthetical) would help me a
bit, just so's I could look at a value I generate and
spot I've done it wrong again.

- I mostly agree with the secdir reviewer's [1] point
that it might be good to RECOMMEND use of I-JSON for
more security sensitive applications, but I'd have felt
more strongly about that if you'd profiled the time
values more strictly as messing up those can lead to
vulnerabilities and being more precise there helps to
get e.g. signatures correct a bit more easily.

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05380.html

---

From: Tim Bray <[email-masked]>
Date: Thu, 22 Jan 2015 18:08:27 -0800

<editor-hat>

On Mon, Jan 19, 2015 at 3:28 PM, Stephen Farrell <[email-masked]>
wrote:

> ​​
>
> ​​
> - 2.1: I've
> ​​
> no idea what Surrogate or Noncharacter
> ​​
> means he
> ​​
> re - a precise reference would be good for me.
> ​​
> And the e
> ​​
> xamples don't help me. So I agree with
> ​​
> Barry's di
> ​​
> scuss.
>
​​
​​
​​Yes. I have an action item to introduce the appropriate references from
[UNICODE]​
​​

> ​​
> ​​
> ​​
> ​​
​​

​Not terribly much.  The recommendation is pretty well a straight copy from
RFC4287, where that was intensively discussed, on the grounds that it was
probably a best practice.​
​​

> ​​
> ​​
> ​​
> ​​
> ​​
> ​​
​​
​​
​I’m pretty sure that this discussion never happened.  Which is leading me
to the conclusion that it would be useful for there to be some AppsArea
discussion on best practices for RFC3339 dates.  However, I’m not convinced
that asserting the default timezone would noticeably help interoperability.

> spot I've done it wrong again.

​Base64url is pretty widely used because the characters that are removed
from the repertoire are troublesome in a variety of contexts and, well,
hey, *anything* might show up in a URI these days.  You don’t really have
to track down the difference - every base64 library these days has an
option saying “generate URL form”.​

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Jan 2015 12:04:38 +0000

Hiya,

Coupla bits'n'pieces below, nothing alarming:-)

> probably a best practice.​

So, ASN.1 DER rules do mandate inclusion of 00 seconds and minutes and
Z on the basis that people otherwise get signatures wrong now and then
if the value is round-tripped between signing and verification. In
practice, I think that'd now be a really rare screw-up though as most
implementers have learned to not round-trip stuff that has been signed.
And insisting on including or excluding 00 seconds can cause bogus
interop issues if one side is too anal. (I recall some code that we
had always set seconds to a non-zero value, sometimes by waiting a
secondm of fibbing and saying 01, just to avoid this:-)

BTW, by round-trip here I mean decode the json-string into some
data structure and then re-encode to json, perhaps with a different
implementation after a visit to a database maybe.

Anyway, you could point out the issue here and maybe at most add
a SHOULD but it's probably good enough now.

> that asserting the default timezone would noticeably help interoperability.

Not include a TZ can lead to interop problems though if a producer
and consumer make different assumptions about how that maps to
local time. And it re-creates the potential for a classic access
control screw up as well of course.

So, in this case, I'd have thought that at least a SHOULD for
including a TZ would be a good addition, esp. if you are going to
take the approach of recommending that this profile be used
for security sensitive uses of JSON.

Yes, that could be punted to a 3339bis (or profile) maybe but
that'd take ages and angst and probably just amount to just
adding that one sentence:-) Doing it here should save others
the trouble of constantly adding to to things that reference
this RFC though.

That said, there may be arguments against a SHOULD for including
a TZ, but I don't know what they are.

Cheers,
S.

---

From: Tim Bray <[email-masked]>
Date: Sun, 25 Jan 2015 10:16:11 -0800

> for security sensitive uses of JSON.

​Unless someone screams STOP I’ll put such a recommendation in a revised
draft unless it’s best to leave that to the RFC Ed.​