Subject: Re: [jose] draft-jones-json-web-signature comments

From: Mike Jones <[email-masked]>
Date: Tue, 1 Nov 2011 00:58:59 +0000

I added text in the Security Considerations section about this in the new drafts, Jim.  It says:
	One example of malformed JSON that MUST be rejected are objects where the same member name occurs multiple times.

				Thanks again,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Thursday, October 13, 2011 7:03 AM
To: Jim Schaad; 'John Bradley'
Cc: [email-masked]; [email-masked]
Subject: Re: [jose] draft-jones-json-web-signature comments

Great point, Jim.  There is a serious Security Consideration here for all JSON-based specs.  In a security-aware JSON parser, I would say that it MUST fail parsing.

				Cheers,
				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]
Sent: Friday, October 07, 2011 8:41 PM
To: Mike Jones; 'John Bradley'
Cc: [email-masked]; [email-masked]
Subject: RE: [jose] draft-jones-json-web-signature comments

Mike,

Is that SHOULD fail or MAY fail parsing?   I would have expected it to
succeed parsing and make the typ field be "foo".

This is probably a security issue that needs to be addressed as part of what a security aware JSON parser needs to do.

Jim

> -----Original Message-----
> From: Mike Jones [mailto:[email-masked]]
> Sent: Friday, October 07, 2011 9:11 AM
> To: John Bradley; Jim Schaad
> Cc: [email-masked]; [email-masked]
> Subject: RE: [jose] draft-jones-json-web-signature comments
> 
> Thanks for your thoughtful read, Jim, and for your reply, John.  
> Nothing
to
> correct in your answers, John.
> 
> I will elaborate on point 4 by stating that it's not legal JSON syntax 
> to
have
> two members with the same name.  Thus, the object {"typ":"JWT", 
> "typ":"foo", "alg":"HS256"} should fail JSON parsing before ever being 
> processed at the JWS level.
> 
> 				Cheers,
> 				-- Mike
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of John Bradley
> Sent: Tuesday, October 04, 2011 3:01 PM
> To: Jim Schaad
> Cc: [email-masked]; [email-masked]
> Subject: Re: [jose] draft-jones-json-web-signature comments
> 
> 
> On 2011-10-04, at 6:37 PM, Jim Schaad wrote:
> 
> > Personal Mail
> >
> > I have some comments about this draft that I hope you can clarify 
> > for
me:
> >
> > 1.  What set of security services are you interested in providing 
> > from this document?  I generally think of signature and 
> > authentication operations as providing a different set of services.
> > Specifically I think of signatures as being more long term and 
> > something that I can use to prove statements to a third party while 
> > I think of authentication as being something between two specific 
> > parties and is very short term, such as was things changed on the 
> > wire.  Since you are combining both operations in a single integrity 
> > document with no differentiation, I wonder if you should spell out 
> > the set of services
that you
> think are provided by this document.
> 
> Both are intended.  Though different signature algorithms may be more 
> appropriate for each task.
> In OpenID Connect HMAC using shared secrets is used as the default for 
> authentication.
> For Non Repudiation at LoA 3 RSA or ECDSA are required.
> 
> 
> >
> > 2.  If find the term "Decoded JWS Header Input" as being very 
> > confusing (along with its kin).  When you say that you are encoding 
> > the JSON object to get a Decoded JWS Payload my mind starts exploding.
> A JWS header that has been base64url decoded back to JSON.  Perhaps 
> Input is not adding anything.
> The language can be looked at.
> 
> I can't find the section you are referring to.  Perhaps a line or 
> section
for me
> to look at.
> 
> 
> 
> 
> >
> > 3.  While I realize that the UTF-8 and the ANSI representations are 
> > going to be the same, I wonder if it might not be better to use 
> > ASCII rather than
> > UTF-8 for the base64url encoded character set.  The fact that it has 
> > been encoded by base64url restricts the set of possible characters 
> > down from
> > UTF-8 into ASCII.  There should be no need to support or expect the 
> > wide variety of UTF-8 characters at that point.
> 
> Per Sec 5 the JSON object's Unicode code points are translated to
> UTF-8 before base64url encoding.
> The result is ASCII.  I don't quite see how you are getting the 
> character
set to
> be UTF-8 after the base64 encoding.
> That must need to be made clearer.
> 
> 
> >
> > 4.  When you say that the names in the Decoded JWS Header Input must 
> > be unique, it is not clear to me if you are saying that the names 
> > must have a single registered meaning, or if you are saying that 
> > they cannot occur in the input twice.  I.e. the object {"typ":"JWT", 
> > "typ":"foo", "alg":"HS256"} is not legal.
> >
> Both,  Mike can clarify.
> 
> > 5.  I note that in your revisions section you say that you changed 
> > x5t from
> > SHA-256 to SHA-1 for compatibility.  I think you may need to support 
> > both with pre-defined names given the algorithm agility drive 
> > currently
> going on.
> 
> That is the hash calculation for the thumbprint.  I don't know of 
> anyplace
> SHA256 is used for that.  It is mostly used to make the MS keystone happy.
> I was the one that changed it so am happy to hear counter arguments.
> 
> >
> > 6.  Are you missing something that you have a syntax name of IntDate 
> > in table 2, but you do not have a header that uses it?  Is a 
> > registry of syntaxes going to need to be defined?  (Side note - 
> > should it be
> > StringOrURI?)
> 
> That got copied from JWT it is used for expired time of tokens.  It 
> should
be
> removed if not used.
> >
> > 7.  The statement that new header parameters may result in 
> > non-interoperable JWSs appears to me to have no merit.  The 
> > validation process should succeed independent of any new headers that are added.
> > What may change is how the output result would be used or 
> > interpreted which would be a function of the client code setting 
> > things up not the
JWS
> library.
> 
> This needs discussion.  Some people are of the opinion that unknown 
> options in security tokens should result in failure.
> >
> > 8.  In section 4.2 it is not clear from the text but it appears to 
> > me that you are stating that a uri is a reasonable item to be used 
> > as a new header parameter name.  Is that the intent?
> 
> That was the intent in JWT and I think in JWS/JWE as well.  Without 
> namespaces there is the registry option or URLs.
> 
> Mike can elaborate on my answers or possibly correct me:)
> 
> John Bradley
> 
> >
> > Jim
> >
> >
> >
> > _______________________________________________
> > jose mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose