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

From: "Jim Schaad" <[email-masked]>
Date: Tue, 4 Oct 2011 14:37:55 -0700

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.

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.

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.

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.

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.

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?)

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.

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?

Jim

---

From: John Bradley <[email-masked]>
Date: Tue, 4 Oct 2011 19:01:21 -0300

> 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.

> 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.

> 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.

> the input twice.  I.e. the object {"typ":"JWT", "typ":"foo", "alg":"HS256"}
Both,  Mike can clarify.

> 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.

> syntaxes going to need to be defined?  (Side note - should it be

That got copied from JWT it is used for expired time of tokens.  It should be removed if not used.
> 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.
> 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

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 4 Oct 2011 17:02:56 -0700

> -----Original Message-----
> From: John Bradley [mailto:[email-masked]]
> 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
> 
> 
> > (along with its kin).  When you say that you are encoding the JSON
object
> to
> I can't find the section you are referring to.  Perhaps a line or section
for me
> to look at.

>From section #5

1.  Create the payload content to be encoded as the Decoded JWS
       Payload Input.

> The result is ASCII.  I don't quite see how you are getting the character
set to
> be UTF-8 after the base64 encoding.
Signing the UTF-8 representation of the JWS Signing Input (the
   concatenation of the JWS Header Input, a period ('.') character, and
   the JWS Payload Input) with the HMAC SHA-256 algorithm and base64url
   encoding the result, as per Section 7.1, yields this JWS Crypto

> 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.
> That got copied from JWT it is used for expired time of tokens.  It should
be
> removed if not used.
> This needs discussion.  Some people are of the opinion that unknown
> options in security tokens should result in failure.

That would be security tokens and not general signatures then

> That was the intent in JWT and I think in JWS/JWE as well.  Without
> namespaces there is the registry option or URLs.
>

---

From: John Bradley <[email-masked]>
Date: Tue, 4 Oct 2011 21:11:04 -0300

Sec 5  step one is badly worded.  I agree the use of "Input" in the name is confusing

Perhaps something simpler like 
1 Create the payload content to be encoded.
2 Base64url encode (without  padding) the payload content.  This encoding becomes the JWS Payload Input.

3  Create a JSON object containing a set of desired header parameters. Note that white space is explicitly allowed in the representation and no canonicalization is performed before encoding. 
4 Translate this JSON object's Unicode code points into UTF-8, as defined in RFC 3629 [RFC3629].
5 Base64url encode the UTF-8 representation of this JSON object as defined in this specification (without padding). This encoding becomes the JWS Header Input.

6  The JWS Signing Input is always the concatenation of the JWS Header Input, a period ('.') character, and the JWS Payload Input.
6 Compute the JWS Crypto Output in the manner defined for the particular algorithm being used. The alg header parameter MUST be present in the JSON Header Input, with the algorithm value accurately representing the algorithm used to construct the JWS Crypto Input.

7 The serialized JWS is the concatenation of the JWS Signing Input, a period ('.') character, and the base64URL encoded signature.

What is there is correct, but confusing to the reader.  This non nominative section needs some work.

The rule about rejecting content based on unknown elements in the envelope may be better in a profile.   Worth discussion.

John B.

---

From: Mike Jones <[email-masked]>
Date: Fri, 7 Oct 2011 16:11:28 +0000

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:

> 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.

> 
> 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.

> 
> 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.

> 
> 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.

> 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.

> 
> 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?)

> 
> 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.

> 
> 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?

John Bradley

---

From: Mike Jones <[email-masked]>
Date: Fri, 7 Oct 2011 16:13:15 +0000

I'll plan on taking a pass at clarifying this wording in the next few weeks.  Thanks both for the careful read and helpful suggestions on clarifying the text.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Tuesday, October 04, 2011 5:11 PM
To: Jim Schaad
Cc: [email-masked]; [email-masked]
Subject: Re: [jose] draft-jones-json-web-signature comments

3  Create a JSON object containing a set of desired header parameters. Note that white space is explicitly allowed in the representation and no canonicalization is performed before encoding.
4 Translate this JSON object's Unicode code points into UTF-8, as defined in RFC 3629<http://self-issued.info/docs/draft-jones-json-web-signature.html#RFC3629> [RFC3629].
5 Base64url encode the UTF-8 representation of this JSON object as defined in this specification (without padding). This encoding becomes the JWS Header Input.

John B.

-----Original Message-----
From: John Bradley [mailto:[email-masked]]
Sent: Tuesday, October 04, 2011 3:01 PM
To: Jim Schaad
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] draft-jones-json-web-signature comments

Personal Mail

I have some comments about this draft that I hope you can clarify for
me:

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

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.

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.

to look at.

going to

been

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

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

both

with pre-defined names given the algorithm agility drive currently going
on.

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.

that

you are stating that a uri is a reasonable item to be used as a new
header

John Bradley

Jim

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

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 7 Oct 2011 20:40:55 -0700

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

> From: Mike Jones [mailto:[email-masked]]
> Sent: Friday, October 07, 2011 9:11 AM
> To: John Bradley; Jim Schaad
> 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
> 
me:
> > differentiation, I wonder if you should spell out the set of services
that you
> think are provided by this document.
> 
for me
set to
be
> > which would be a function of the client code setting things up not the
JWS
> library.

---

From: Mike Jones <[email-masked]>
Date: Thu, 13 Oct 2011 14:02:35 +0000

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,

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

Jim

to
have
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 
> > document with no differentiation, I wonder if you should spell out 
> > the set of services
that you
for me
> > going to be the same, I wonder if it might not be better to use 
> > ASCII rather than
set to
> > 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", 
> > both with pre-defined names given the algorithm agility drive 
> > currently
> going on.
> 
> > 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?)
> 
be
> > 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
> > 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?
>