Re: [jose] #27: member names MUST be unique needs additional text

[Mike Jones <[e-mail]>]

The operable sentence in my suggested text below is this one: "If the platform's JSON parser does not reject input with duplicate member names, the input will first need to be separately parsed to reject these invalid inputs before using the platform's parser".  In other words, if the JSON parser in the development platform you are using does not reject inputs with duplicate member names, you will need to write a separate JSON parser that detects this invalid input and rejects it.

This parser could either just be a validator, returning TRUE or FALSE for whether the JSON is valid for JOSE - in which case you'd then pass any inputs validating as TRUE to the platform's JSON parser, or it could be a replacement parser, in which case your code would not use the development platform's JSON parser at all.  I suspect people would be more likely to do the former than the latter, but both approaches are equivalent.

BTW, if it's your sense that there's a problem occurring in the JSON working group with respect to enabling strict JSON parsing, we probably need to become active there.  For instance, even if the spec allows duplicate member names like the ECMA spec does, the RFC could recommend or require that parsers support a "strict" mode, which rejects these unnecessarily lax inputs.  Then JOSE implementations could use that.

				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]] 
Sent: Wednesday, June 26, 2013 11:30 AM
To: 'jose issue tracker'; [e-mail]; Mike Jones
Cc: [e-mail]
Subject: RE: [jose] #27: member names MUST be unique needs additional text

<no hat>

I consider myself to be reasonably competent in both English and Technical English.  I have no idea what I am supposed to be doing to deal with the text below.  Does this mean that I need to write an independent parser?  What about cases where it is coming in on a stream and I don't get to see the data before the parse occurs?  How are they interpreted differently?  What exactly is this supposed to be addressing.  Much of this could be skipped when we said don't do it.  Since this is no longer a viable statement due to the state of parsers, we need to be more explicit and say what is going on.

No I don't consider the suggested text to be adequate.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of jose issue tracker
> Sent: Tuesday, June 25, 2013 5:41 PM
> To: [e-mail];
> [e-mail]
> Cc: [e-mail]
> Subject: Re: [jose] #27: member names MUST be unique needs additional 
> text
> 
> #27: member names MUST be unique needs additional text
> 
> 
> Comment (by [e-mail]):
> 
>  The JWS draft currently says:
> 
>          The Header Parameter Names within the JWS Header MUST be unique;
>          JWSs with duplicate Header Parameter Names MUST be rejected.
> 
>  How about changing this to:
> 
>          The Header Parameter Names within the JWS Header MUST be unique;
>          JWSs with duplicate Header Parameter Names MUST be rejected.
>          This is necessary to prevent attacks in which the same JWS 
> might  be interpreted
>          in different ways by different implementations and to prevent  attackers
>          from hiding extra content in duplicate member values.
>          If the platform s JSON parser does not reject input with 
> duplicate member names,
>          the input will first need to be separately parsed to reject 
> these  invalid inputs
>          before using the platform s parser.
> 
> --
> -------------------------+--------------------------------------------
> -------------------------+--
> -------------------------+---
>  Reporter:               |       Owner:  draft-ietf-jose-json-web-
>   [e-mail] |  [e-mail]
>      Type:  defect       |      Status:  new
>  Priority:  major        |   Milestone:
> Component:  json-web-    |     Version:
>   signature              |  Resolution:
>  Severity:  -            |
>  Keywords:               |
> -------------------------+--------------------------------------------
> -------------------------+--
> -------------------------+---
> 
> Ticket URL: 
> <http://trac.tools.ietf.org/wg/jose/trac/ticket/27#comment:1>
> jose <http://tools.ietf.org/jose/>
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose