> On Apr 6, 2017, at 9:17 AM, Brotman, Alexander 
> <[email protected]> wrote:
> 
> With regard to the JSON policy (though that's STS, not TLSRPT).
> It's a small file, which given the JSON requirement, should
> be properly formatted.  I would think this should be relatively
> easy to parse with standard C string functions.

Here are the line counts for the "*.[ch]" files from what appears
to be a popular JSON parsing API for C:

$ git clone https://github.com/json-c/json-c.git
$ cd json-c
$ wc -l *.[ch] | sort -n
      11 strdup_compat.h
      19 json_inttypes.h
      20 json_c_version.c
      22 json_c_version.h
      25 random_seed.h
      26 libjson.c
      31 math_compat.h
      34 json.h
      35 bits.h
      45 vasprintf_compat.h
      55 json_object_private.h
      63 arraylist.h
      71 debug.h
      83 debug.c
      89 json_util.h
      91 json_visit.h
     114 printbuf.h
     115 json_pointer.h
     133 json_visit.c
     143 arraylist.c
     154 printbuf.c
     168 json_object_iterator.c
     208 json_tokener.h
     238 random_seed.c
     239 json_object_iterator.h
     326 json_pointer.c
     326 json_util.c
     366 linkhash.h
     690 linkhash.c
     901 json_object.h
     978 json_tokener.c
    1195 json_object.c
    7014 total

That does not jive with relatively easy to parse...

JSON supports comments, elements that are integers, strings,
arrays or associative arrays (nested JSON objects).  JSON
strings are UTF-8 and allow embedded NUL octets.

Your JSON reference is to the obsolete RFC4627, the non-obsolete
reference is RFC7159.

Speaking of the policy, what should be done if the HTTPS policy
contains multiple JSON objects, no JSON objects, or broken JSON?

Is there a size limit a parser can reasonably impose on the policy
data to avoid resource exhaustion parsing absurdly large JSON input?
Could we say for example that a valid STSv1 JSON object must fit in
16K bytes or 64K bytes?

How does a domain get rid of its STS policy?  I thought we had discussed
using "max_age = 0" for this, which after being in place long enough to
assure that all previously cached policies have expired can be removed.
Or might just "404" suffice?

-- 
        Viktor.

_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta

Reply via email to