Subject: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)

From: "Richard Barnes" <[email-masked]>
Date: Wed, 01 Oct 2014 21:21:50 -0700

Richard Barnes has entered the following ballot position for
draft-ietf-jose-json-web-signature-33: Discuss

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-jose-json-web-signature/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Overall, this document is in much more solid shape than when it began. 
Thanks to the WG for a lot of hard work.  I only have two remaining
concerns, which should hopefully be easy to address.

Section 7.2.
I've had several implementors trying to use JWS in the JSON serialization
ask why it was necessary to include a "signatures" array in cases where
there's only one signer.  It seems like this is going to be a major
barrier to deployment and re-use, so I would propose including the
following text:

"""
In cases where the JWS has been signed by only a single signer, the
"signatures" array will contain a single object.  In such cases, the
elements of the single "signatures" object MAY be included at the top
level of the JWS object.  A JSON-formatted JWS that contains a
"signatures" field MUST NOT contain a "protected", "header", or
"signature" field, and vice versa.
"""

This may also require some other changes where "signatures" is relied on,
e.g., in Section 9 of the JWE spec.

Section 6.
"""
These Header Parameters MUST be integrity protected if the information
that they convey is to be utilized in a trust decision.
"""
This smells really fishy to me.  What's your attack scenario?  I'm pretty
certain that there's no way any of these fields can be altered in such a
way that (1) the signature will validate, and (2) the recipient will
accept a key it shouldn't.  By way of contrast, CMS doesn't sign the
certificate fields, and the Certificate payload in TLS is only signed as
a side effect of the protocol's verification that the remote end has been
the same through the whole handshake (which doesn't apply here).

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

Section 2.
In the definition of "Unsecured JWS", it would be good to note that this
requires "alg" == "none".

Section 3.3.
Why doesn't this section have a JSON-encoded form as well?

Appendix A.5.
I would prefer if this example could be removed.  JWT is the only use
case for Unsecured JWS right now, and there's already an example in that
document.

Thanks for Appendix C.  FWIW, it has been implemented:
http://dxr.mozilla.org/mozilla-central/source/dom/crypto/CryptoBuffer.cpp#85

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 2 Oct 2014 11:25:49 -0700

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Wednesday, October 01, 2014 9:22 PM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)

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

Overall, this document is in much more solid shape than when it began. 
Thanks to the WG for a lot of hard work.  I only have two remaining concerns, which should hopefully be easy to address.

Section 7.2.
I've had several implementors trying to use JWS in the JSON serialization ask why it was necessary to include a "signatures" array in cases where there's only one signer.  It seems like this is going to be a major barrier to deployment and re-use, so I would propose including the following text:

"""
In cases where the JWS has been signed by only a single signer, the "signatures" array will contain a single object.  In such cases, the elements of the single "signatures" object MAY be included at the top level of the JWS object.  A JSON-formatted JWS that contains a "signatures" field MUST NOT contain a "protected", "header", or "signature" field, and vice versa.
"""

This may also require some other changes where "signatures" is relied on, e.g., in Section 9 of the JWE spec.

Section 6.
"""
These Header Parameters MUST be integrity protected if the information that they convey is to be utilized in a trust decision.
"""
This smells really fishy to me.  What's your attack scenario?  I'm pretty certain that there's no way any of these fields can be altered in such a way that (1) the signature will validate, and (2) the recipient will accept a key it shouldn't.  By way of contrast, CMS doesn't sign the certificate fields, and the Certificate payload in TLS is only signed as a side effect of the protocol's verification that the remote end has been the same through the whole handshake (which doesn't apply here).

[JLS] There were a couple of attacks that were created for CMS based on using the SKI as the identifier in CMS.  There now exists a signed attribute for CMS to deal with this problem.   IMO the pointer the certificate probably should be a required signing field in CMS 

Section 2.
In the definition of "Unsecured JWS", it would be good to note that this requires "alg" == "none".

Section 3.3.

Appendix A.5.
I would prefer if this example could be removed.  JWT is the only use case for Unsecured JWS right now, and there's already an example in that document.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 2 Oct 2014 14:38:13 -0400

On Thu, Oct 2, 2014 at 2:25 PM, Jim Schaad <[email-masked]> wrote:

> Cc: [email-masked]; [email-masked];
> [email-masked]
> there's only one signer.  It seems like this is going to be a major barrier
> to deployment and re-use, so I would propose including the following text:
>
> """
> elements of the single "signatures" object MAY be included at the top level
> of the JWS object.  A JSON-formatted JWS that contains a "signatures" field
> MUST NOT contain a "protected", "header", or "signature" field, and vice
> versa.
> """
>
> way that (1) the signature will validate, and (2) the recipient will accept
> a key it shouldn't.  By way of contrast, CMS doesn't sign the certificate
> fields, and the Certificate payload in TLS is only signed as a side effect
> of the protocol's verification that the remote end has been the same
> through the whole handshake (which doesn't apply here).
>
> [JLS] There were a couple of attacks that were created for CMS based on
> using the SKI as the identifier in CMS.  There now exists a signed
> attribute for CMS to deal with this problem.   IMO the pointer the
> certificate probably should be a required signing field in CMS
>

Citation?

> I would prefer if this example could be removed.  JWT is the only use case
> for Unsecured JWS right now, and there's already an example in that
> document.
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 2 Oct 2014 21:07:51 +0000

Replies inline marked “Mike>”…

From: jose [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Thursday, October 02, 2014 11:38 AM
To: Jim Schaad
Cc: [email-masked]; The IESG; [email-masked]; [email-masked]
Subject: Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)

On Thu, Oct 2, 2014 at 2:25 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, October 01, 2014 9:22 PM
To: The IESG
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)

Section 7.2.

"""

Mike> This was previously proposed (I believe during the Denver interim meeting) and rejected by the working group because it complicates both producers and parsers by introducing an unnecessary special case.  Currently, by design, whether there are single or multiple signatures, the same syntax is used.  Your proposal would use a different syntax in the single signature case than in the multiple signature case.  This is likely to result in implementation bugs and inconsistencies.

Section 6.
"""

Citation?

Mike> The attack scenario is trivial to describe.  If an attacker can change information used in a trust decision, the trust decision has no validity.  Unless the information is integrity-protected, the attacker could change the non-integrity-protected portions of the JWS in an undetectable way.

Mike> For what it’s worth, Sean had us add language in a number of places that basically said that information is only as trustworthy as its source and the means by which it is obtained.  If I remember correctly, this was one of those places.

Section 2.

Mike> OK

Section 3.3.

Mike> Because it’s mean to be a simple introductory example to help people get their head around the concept – not a complete tutorial.  Other examples of JSON-encoded objects are found elsewhere in the document and in the cookbook.

Appendix A.5.

Mike> Given that it’s important that implementers using them understand Unsecured JWSs, there is motivation to retain the example.  I’d be interested in what others in the working group think, given that there was substantial support for retaining this functionality when its removal was proposed.

Mike> You’re welcome.

                                                            -- Mike

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 2 Oct 2014 21:32:07 -0700

From: Richard Barnes [mailto:[email-masked]] 
Sent: Thursday, October 02, 2014 11:38 AM
To: Jim Schaad
Cc: The IESG; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]]
Sent: Wednesday, October 01, 2014 9:22 PM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)

Section 7.2.

"""

Section 6.
"""

Citation?

[JLS} – RFC 2634 section 5 contains descriptions of attacks where a certificate can have different policy and usage information because it has been re-issued or just has the same SKI value.

Section 2.

Section 3.3.

Appendix A.5.

---

From: Mike Jones <[email-masked]>
Date: Mon, 6 Oct 2014 07:54:20 +0000

Thanks for your review, Richard.  I'm repeating my previous responses from my Thursday reply, but this time using ">" quoting rather than colors, for better readability by people not using HTML-enabled mail readers...

> Cc: [email-masked]; [email-masked]; draft-ietf-jose-json-web-
> [email-masked]
> Subject: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33:
> (with DISCUSS and COMMENT)
> 
> 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.)
> 
> 
> Thanks to the WG for a lot of hard work.  I only have two remaining concerns,
> which should hopefully be easy to address.
> 
> Section 7.2.
> I've had several implementors trying to use JWS in the JSON serialization ask why
> it was necessary to include a "signatures" array in cases where there's only one
> signer.  It seems like this is going to be a major barrier to deployment and re-
> use, so I would propose including the following text:
> 
> """
> In cases where the JWS has been signed by only a single signer, the "signatures"
> array will contain a single object.  In such cases, the elements of the single
> "signatures" object MAY be included at the top level of the JWS object.  A JSON-
> formatted JWS that contains a "signatures" field MUST NOT contain a
> "protected", "header", or "signature" field, and vice versa.
> """
> 

This was previously proposed (I believe during the Denver interim meeting) and rejected by the working group because it complicates both producers and parsers by introducing an unnecessary special case.  Currently, by design, whether there are single or multiple signatures, the same syntax is used.  Your proposal would use a different syntax in the single signature case than in the multiple signature case.  This is likely to result in implementation bugs and inconsistencies.

> Section 6.
> """
> These Header Parameters MUST be integrity protected if the information that
> they convey is to be utilized in a trust decision.
> """
> This smells really fishy to me.  What's your attack scenario?  I'm pretty certain
> that there's no way any of these fields can be altered in such a way that (1) the
> signature will validate, and (2) the recipient will accept a key it shouldn't.  By way
> of contrast, CMS doesn't sign the certificate fields, and the Certificate payload in
> TLS is only signed as a side effect of the protocol's verification that the remote
> end has been the same through the whole handshake (which doesn't apply here).

The attack scenario is trivial to describe.  If an attacker can change information used in a trust decision, the trust decision has no validity.  Unless the information is integrity-protected, the attacker could change the non-integrity-protected portions of the JWS in an undetectable way.

For what it's worth, Sean had us add language in a number of places that basically said that information is only as trustworthy as its source and the means by which it is obtained.  If I remember correctly, this was one of those places.

OK

> Why doesn't this section have a JSON-encoded form as well?

Because it's meant to be a simple introductory example to help people get their head around the concept - not a complete tutorial.  Other examples of JSON-encoded objects are found elsewhere in the document and lots of them are found in draft-ietf-jose-cookbook.

> Appendix A.5.
> I would prefer if this example could be removed.  JWT is the only use case for
> Unsecured JWS right now, and there's already an example in that document.

Mike> Given that it's important that implementers using them understand Unsecured JWSs, there is motivation to retain the example.  I'd be interested in what others in the working group think, given that there was substantial support for retaining this functionality when its removal was proposed.

> http://dxr.mozilla.org/mozilla-central/source/dom/crypto/CryptoBuffer.cpp#85

You're welcome.

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

				Thanks again!
				-- Mike

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 6 Oct 2014 07:26:01 -0700

> From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
> Sent: Monday, October 06, 2014 12:54 AM
> To: Richard Barnes; The IESG
> Thanks for your review, Richard.  I'm repeating my previous responses from
my
> Thursday reply, but this time using ">" quoting rather than colors, for
better
> readability by people not using HTML-enabled mail readers...
> 
> > Cc: [email-masked]; [email-masked];
> > draft-ietf-jose-json-web- [email-masked]
> > Subject: [jose] Richard Barnes' Discuss on
draft-ietf-jose-json-web-signature-
> 33:
> > 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
> Mike> Given that it's important that implementers using them understand
> Unsecured JWSs, there is motivation to retain the example.  I'd be
interested in
> what others in the working group think, given that there was substantial
> support for retaining this functionality when its removal was proposed.
> 

I have no problems with there being a reference to the JWT document for the
example.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 10 Oct 2014 18:19:31 -0400

On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones <[email-masked]>
wrote:

> my Thursday reply, but this time using ">" quoting rather than colors, for
> better readability by people not using HTML-enabled mail readers...
>
> draft-ietf-jose-json-web-signature-33:
> email
> concerns,
> "signatures"
> > This may also require some other changes where "signatures" is relied
> on, e.g.,
> > in Section 9 of the JWE spec.
>
> This was previously proposed (I believe during the Denver interim meeting)
> and rejected by the working group because it complicates both producers and
> parsers by introducing an unnecessary special case.  Currently, by design,
> whether there are single or multiple signatures, the same syntax is used.
> Your proposal would use a different syntax in the single signature case
> than in the multiple signature case.  This is likely to result in
> implementation bugs and inconsistencies.
>

This assertion of complexity is bogus.  Have you implemented this syntax,
or can you point me to someone who has, and has had problems?  I have
implemented it and I'm asking for the simpler syntax.  I've gotten the same
request from others, for JWE.

> that
> The attack scenario is trivial to describe.  If an attacker can change
> information used in a trust decision, the trust decision has no validity.
> Unless the information is integrity-protected, the attacker could change
> the non-integrity-protected portions of the JWS in an undetectable way.
>

That's hand waving, not an attack scenario.  Allow me to elaborate on this:

There is no possible attack scenario for the key identifiers that identify
a *key* (vs. a cert) -- jwk, jku, and kid.  For any given signed object,
there is exactly one key that can validate the signature (otherwise the
crypto is broken).  If the attacker changes the validation key, then the
signature won't validate.  So there is no need to integrity protect these
headers, since there's no point to the attacker changing them.  RFC 2634
actually has text to this effect:

"""
   The first version of this attack is a simple denial of service attack
   where an invalid certificate is substituted for the valid
   certificate. This renders the message unverifiable, as the public key
   in the certificate no longer matches the private key used to sign the
   message.
"""

With regard to the certificate identifiers ("x5u", "x5c", "x5t", and
"x5t#S256"), the risks that Jim points out [RFC2634, Section 5] are real,
but only apply in certain narrow circumstances.  Namely, the only time a
risk arises is when two certificates have been issued for the same public
key, with different attributes.  This is exceedingly rare in practice, and
all current secure messaging systems get along fine without protection
against this attack.  And it might not even be an attack -- you could
envision cases with "x5u" where the signer purposely presents different
certificates to different relying parties!

So the blanket requirement that these fields MUST be integrity protected is
not appropriate.  It is only required for certain special situations using
certificates.  Proposed revision:

Delete: "These Header Parameters MUST be integrity protected if the
information that they convey is to be utilized in a trust decision."

Add new paragraph: "In situations where multiple certificates with
different attributes may be issued over the same public key, there is a
risk that one of these certificates may be substituted for another. In such
situations, the creator of a JWS object MUST integrity protect the "x5u",
"x5c", "x5t", and "x5t#S256" attributes, if present."

>
> For what it's worth, Sean had us add language in a number of places that
> basically said that information is only as trustworthy as its source and
> the means by which it is obtained.  If I remember correctly, this was one
> of those places.
>
> requires
> > "alg" == "none".
> Because it's meant to be a simple introductory example to help people get
> their head around the concept - not a complete tutorial.  Other examples of
> JSON-encoded objects are found elsewhere in the document and lots of them
> are found in draft-ietf-jose-cookbook.
>
> > Appendix A.5.
> case for
> interested in what others in the working group think, given that there was
> substantial support for retaining this functionality when its removal was
> proposed.
>

---

From: Mike Jones <[email-masked]>
Date: Sat, 11 Oct 2014 21:14:31 +0000

> Sent: Friday, October 10, 2014 3:20 PM
> To: Mike Jones
> Cc: The IESG; [email-masked]; [email-masked]; [email-masked]
> On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones <[email-masked]> wrote:
> > I've had several implementers trying to use JWS in the JSON serialization ask why
> This assertion of complexity is bogus.  Have you implemented this syntax, or can you point me to someone who has, and has had problems?  I have implemented it and I'm asking for the simpler syntax.  I've gotten the same request from others, for JWE. 

I'm not saying that anything is insurmountable.  I'm saying that having two equivalent syntaxes in the JSON Serialization for the same thing is going to make it more likely that some implementations won't correctly support both of them.  For those following along, those two syntaxes would be:

  {
   "payload":"<payload contents>",
   "signatures":[
    {"protected":"<integrity-protected header 1 contents>",
     "header":<non-integrity-protected header 1 contents>,
     "signature":"<signature 1 contents>"}]
  }

and

  {
   "payload":"<payload contents>",
   "protected":"<integrity-protected header 1 contents>",
   "header":<non-integrity-protected header 1 contents>,
   "signature":"<signature 1 contents>"
  }

Is your motivating use case a profile of the JSON Serialization in which multiple signatures aren't used or supported, and so for which the array notation would always be superfluous syntax?  Are you concerned that if this profile becomes the predominant use case, that some/many implementations wouldn't implement the more general multi-signature syntax (or would implement it incorrectly, since it would normally not ever be used or tested)?

I'd love to hear others in the working group chime in on this topic...

> There is no possible attack scenario for the key identifiers that identify a *key* (vs. a cert) -- jwk, jku, and kid.  For any given signed object, there is exactly one key that can validate the signature (otherwise the crypto is broken).  If the attacker changes the validation key, then the signature won't validate.  So there is no need to integrity protect these headers, since there's no point to the attacker changing them.  RFC 2634 actually has text to this effect:
> 
> """

It's not clear to me that enabling the attacker to substitute keys and get the recipient to attempt to validate the signature with a key of the attacker's choosing doesn't constitute at least a portion of a viable attack scenario.  It may or may not (knowing for sure is beyond my specific cryptographic expertise in this area) and it may not now but may be in the future (when new attacks are created).  Requiring these parameters to be integrity protected when used in a trust decision does no harm and may do substantial good.

> With regard to the certificate identifiers ("x5u", "x5c", "x5t", and "x5t#S256"), the risks that Jim points out [RFC2634, Section 5] are real, but only apply in certain narrow circumstances.  Namely, the only time a risk arises is when two certificates have been issued for the same public key, with different attributes.  This is exceedingly rare in practice, and all current secure messaging systems get along fine without protection against this attack.  And it might not even be an attack -- you could envision cases with "x5u" where the signer purposely presents different certificates to different relying parties!
> So the blanket requirement that these fields MUST be integrity protected is not appropriate.  It is only required for certain special situations using certificates.  Proposed revision:
> Delete: "These Header Parameters MUST be integrity protected if the information that they convey is to be utilized in a trust decision."

Researching the history a bit more, this text was added to address issue #104 http://trac.tools.ietf.org/wg/jose/trac/ticket/104 raised by Jim Schaad.  Unless Jim agrees that it is now somehow unnecessary, I don't believe that it's reasonable for us to now remove it.  Also, see Jim's related comments about trust statements and trust decisions in issue #74.

> Add new paragraph: "In situations where multiple certificates with different attributes may be issued over the same public key, there is a risk that one of these certificates may be substituted for another. In such situations, the creator of a JWS object MUST integrity protect the "x5u", "x5c", "x5t", and "x5t#S256" attributes, if present."
> 

					-- Mike

---

From: Richard Barnes <[email-masked]>
Date: Mon, 20 Oct 2014 12:15:49 -0400

On Sat, Oct 11, 2014 at 5:14 PM, Mike Jones <[email-masked]>
wrote:

> > Cc: The IESG; [email-masked]; [email-masked];
> > Subject: Re: [jose] Richard Barnes' Discuss on
> draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)
> >
> > Thanks for your review, Richard.  I'm repeating my previous responses
> from my Thursday reply, but this time using ">" quoting rather than colors,
> for better readability by people not using HTML-enabled mail readers...
> >
> > This was previously proposed (I believe during the Denver interim
> meeting) and rejected by the working group because it complicates both
> producers and parsers by introducing an unnecessary special case.
> Currently, by design, whether there are single or multiple signatures, the
> same syntax is used.  Your proposal would use a different syntax in the
> single signature case than in the multiple signature case.  This is likely
> to result in implementation bugs and inconsistencies.
> >
> > This assertion of complexity is bogus.  Have you implemented this
> syntax, or can you point me to someone who has, and has had problems?  I
> have implemented it and I'm asking for the simpler syntax.  I've gotten the
> same request from others, for JWE.
>
> I'm not saying that anything is insurmountable.  I'm saying that having
> two equivalent syntaxes in the JSON Serialization for the same thing is
> going to make it more likely that some implementations won't correctly
> support both of them.  For those following along, those two syntaxes would
> be:
>
>   {

It's worth noting that the multi-signer case reduces to the single-signer
case, e.g.:

<script>
var JWS = get_jws();
if ("signatures" in JWS) {
  // i = index of a signature we'll use
  JWS.protected = JWS.signatures[i].protected
  JWS.header = JWS.signatures[i].header
  JWS.signature = JWS.signatures[i].signature
} else if (! ("signature" in JWS) && (("protected" in JWS) || ("header" in
JWS))) {
  throw "malformed JWS";
}
var result = validate_single_signer_jws(JWS)
</script>

Or copy "payload" up into each signature object.  Or iterate through
signatures and see which ones work.  Either way, you're going to build this
with a "verify single signature" primitive.

> Is your motivating use case a profile of the JSON Serialization in which
> multiple signatures aren't used or supported, and so for which the array
> notation would always be superfluous syntax?  Are you concerned that if
> this profile becomes the predominant use case, that some/many
> implementations wouldn't implement the more general multi-signature syntax
> (or would implement it incorrectly, since it would normally not ever be
> used or tested)?
>

If you look at existing uses for signed objects (such as they are),
single-signer is by far the dominant use case, so requiring the multiple
signer notation is would almost always be superfluous syntax.

I'm not all that concerned about support for multi-sig.  If implementations
care about it, it will get built.  And because of the way this has been
designed, it's easy to build once you've got the single-signer version (see
above).

> > There is no possible attack scenario for the key identifiers that
> identify a *key* (vs. a cert) -- jwk, jku, and kid.  For any given signed
> object, there is exactly one key that can validate the signature (otherwise
> the crypto is broken).  If the attacker changes the validation key, then
> the signature won't validate.  So there is no need to integrity protect
> these headers, since there's no point to the attacker changing them.  RFC
> 2634 actually has text to this effect:
> >
> > """
> It's not clear to me that enabling the attacker to substitute keys and get
> the recipient to attempt to validate the signature with a key of the
> attacker's choosing doesn't constitute at least a portion of a viable
> attack scenario.  It may or may not (knowing for sure is beyond my specific
> cryptographic expertise in this area) and it may not now but may be in the
> future (when new attacks are created).  Requiring these parameters to be
> integrity protected when used in a trust decision does no harm and may do
> substantial good.
>

It seems pretty clear to me :)  Everything involved in signature
verification is public, so anything the attacker could do by tricking a
third party into verifying he could just as well do himself.  The only
exception to this would be if the verification were somehow a side-channel
for something else happening on the verifier's machine, which seems pretty
outlandish.

> > So the blanket requirement that these fields MUST be integrity protected
> is not appropriate.  It is only required for certain special situations
> using certificates.  Proposed revision:
> Researching the history a bit more, this text was added to address issue
> #104 http://trac.tools.ietf.org/wg/jose/trac/ticket/104 raised by Jim
> Schaad.  Unless Jim agrees that it is now somehow unnecessary, I don't
> believe that it's reasonable for us to now remove it.  Also, see Jim's
> related comments about trust statements and trust decisions in issue #74.
>

I would note that issue #104 was closed without any discussion on the list
(AFAICT).  And that issue only related to "jku", so the extension to all
the other fields is unnecessary.  See my response to Jim for why it's not
necessary for "jku" either.

As far as issue #74, that appears to be about not using the URI as an
element of the trust decision unless the identity in the URI is
authenticated.  I read that as to mean that the subject of the URI
authenticated itself, e.g., using HTTPS server authentication.

> > > In the definition of "Unsecured JWS", it would be good to note that
> this requires
> > > "alg" == "none".
> >
> > OK
> >
> > > Section 3.3.
> > Because it's meant to be a simple introductory example to help people
> get their head around the concept - not a complete tutorial.  Other
> examples of JSON-encoded objects are found elsewhere in the document and
> lots of them are found in draft-ietf-jose-cookbook.
> >
> > > Appendix A.5.

---

From: ⌘ Matt Miller <[email-masked]>
Date: Mon, 20 Oct 2014 10:45:04 -0600

On 10/20/14, 10:15 AM, Richard Barnes wrote:
> 
> 
> On Sat, Oct 11, 2014 at 5:14 PM, Mike Jones 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>> From: Richard Barnes [mailto:[email-masked] <mailto:[email-masked]>] 
>> Sent: Friday, October 10, 2014 3:20 PM To: Mike Jones Cc: The 
>> IESG; [email-masked]
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; 
> <mailto:[email-masked]>
>> On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones
> <[email-masked] <mailto:[email-masked]>>
>  wrote:
>> Thanks for your review, Richard.  I'm repeating my previous
> responses from my Thursday reply, but this time using ">" quoting 
> rather than colors, for better readability by people not using 
> HTML-enabled mail readers...
>> 
>>> -----Original Message----- From: jose 
>>> [mailto:[email-masked]
> <mailto:[email-masked]>] On Behalf Of Richard Barnes
>>> Sent: Wednesday, October 01, 2014 9:22 PM To: The IESG Cc: 
>>> [email-masked]
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; draft-ietf-jose-json-web-
>>> [email-masked] <mailto:[email-masked]> 
>>> Overall, this document is in much more solid shape than when 
>>> it
> began.
>>> Section 7.2. I've had several implementers trying to use JWS
>>> in the JSON
> serialization ask why
>>> it was necessary to include a "signatures" array in cases
>>> where there's only one signer.  It seems like this is going to
>>> be a major barrier to deployment and re- use, so I would
>>> propose including the following text:
>>> 
>>> """ In cases where the JWS has been signed by only a single 
>>> signer, the "signatures" array will contain a single object. In
>>> such cases, the elements of the single "signatures" object MAY
>>> be included at the top level of the JWS object.  A JSON- 
>>> formatted JWS that contains a "signatures" field MUST NOT 
>>> contain a "protected", "header", or "signature" field, and
>>> vice versa. """
>>> 
>>> This may also require some other changes where "signatures" is 
>>> relied on, e.g., in Section 9 of the JWE spec.
>> This was previously proposed (I believe during the Denver
>> interim meeting) and rejected by the working group because it
>> complicates both producers and parsers by introducing an
>> unnecessary special case.  Currently, by design, whether there
>> are single or multiple signatures, the same syntax is used.  Your
>> proposal would use a different syntax in the single signature
>> case than in the multiple signature case.  This is likely to
>> result in implementation bugs and inconsistencies.
>> 
>> This assertion of complexity is bogus.  Have you implemented
>> this syntax, or can you point me to someone who has, and has had 
>> problems?  I have implemented it and I'm asking for the simpler 
>> syntax.  I've gotten the same request from others, for JWE.
> 
> I'm not saying that anything is insurmountable.  I'm saying that 
> having two equivalent syntaxes in the JSON Serialization for the 
> same thing is going to make it more likely that some 
> implementations won't correctly support both of them.  For those 
> following along, those two syntaxes would be:
> 
> { "payload":"<payload contents>", "signatures":[ 
> "signature":"<signature 1 contents>"}] }
> 
> and
> 
> { "payload":"<payload contents>",
> "signature":"<signature 1 contents>" }
> 
> 
> It's worth noting that the multi-signer case reduces to the 
> single-signer case, e.g.:
> 
> <script> var JWS = get_jws(); if ("signatures" in JWS) { // i = 
> index of a signature we'll use JWS.protected = 
> JWS.signatures[i].protected JWS.header = JWS.signatures[i].header 
> JWS.signature = JWS.signatures[i].signature } else if (! 
> ("signature" in JWS) && (("protected" in JWS) || ("header" in 
> JWS))) { throw "malformed JWS"; } var result = 
> validate_single_signer_jws(JWS) </script>
> 
> Or copy "payload" up into each signature object.  Or iterate 
> through signatures and see which ones work.  Either way, you're 
> going to build this with a "verify single signature" primitive.
> 
> 
> 
> Is your motivating use case a profile of the JSON Serialization in
>  which multiple signatures aren't used or supported, and so for 
> which the array notation would always be superfluous syntax?  Are 
> you concerned that if this profile becomes the predominant use 
> case, that some/many implementations wouldn't implement the more 
> general multi-signature syntax (or would implement it incorrectly, 
> since it would normally not ever be used or tested)?
> 
> 
> single-signer is by far the dominant use case, so requiring the
> multiple signer notation is would almost always be superfluous 
> syntax.
> 
> I'm not all that concerned about support for multi-sig.  If 
> implementations care about it, it will get built.  And because of 
> the way this has been designed, it's easy to build once you've got 
> the single-signer version (see above).
> 
> 
> 

As I think I've said in previous discussions about the JSON
serialization, I can live with something verbose *BUT* would rather
like a lighter syntax for the single-sig JSON serialization.  It's by
far the most common usecase, so optimizing for it seems like a good thing.

>>> Section 6. """ These Header Parameters MUST be integrity 
>>> protected if the information that they convey is to be
>>> utilized in a trust decision. """ This smells really fishy to
>>> me. What's your attack scenario?  I'm pretty certain that
>>> there's no way any of these fields can be altered in such a way
>>> that (1) the signature will validate, and (2) the recipient
>>> will accept a key it shouldn't.  By way of contrast, CMS
>>> doesn't sign the certificate fields, and the Certificate
>>> payload in TLS is only signed as a side effect of the
>>> protocol's verification that the remote end has been the same
>> The attack scenario is trivial to describe.  If an attacker can 
>> change information used in a trust decision, the trust decision 
>> has no validity.  Unless the information is integrity-protected, 
>> the attacker could change the non-integrity-protected portions
>> of the JWS in an undetectable way.
>> 
>> There is no possible attack scenario for the key identifiers
>> that identify a *key* (vs. a cert) -- jwk, jku, and kid.  For
>> any given signed object, there is exactly one key that can
>> validate the signature (otherwise the crypto is broken).  If the
>> attacker changes the validation key, then the signature won't
>> validate. So there is no need to integrity protect these headers,
>> since there's no point to the attacker changing them.  RFC 2634 
>> """ The first version of this attack is a simple denial of 
>> service attack where an invalid certificate is substituted for 
>> the valid certificate. This renders the message unverifiable, as 
>> the public key in the certificate no longer matches the private 
>> key used to sign the message. """
> 
> It's not clear to me that enabling the attacker to substitute keys
>  and get the recipient to attempt to validate the signature with a
>  key of the attacker's choosing doesn't constitute at least a 
> portion of a viable attack scenario.  It may or may not (knowing 
> for sure is beyond my specific cryptographic expertise in this 
> area) and it may not now but may be in the future (when new
> attacks are created). Requiring these parameters to be integrity
> protected when used in a trust decision does no harm and may do
> substantial good.
> 
> 
> verification is public, so anything the attacker could do by 
> tricking a third party into verifying he could just as well do 
> himself.  The only exception to this would be if the verification 
> were somehow a side-channel for something else happening on the 
> verifier's machine, which seems pretty outlandish.
> 
> 
> 
>> With regard to the certificate identifiers ("x5u", "x5c", "x5t", 
>> and "x5t#S256"), the risks that Jim points out [RFC2634, Section 
>> 5] are real, but only apply in certain narrow circumstances. 
>> Namely, the only time a risk arises is when two certificates
>> have been issued for the same public key, with different
>> attributes. This is exceedingly rare in practice, and all current
>> secure messaging systems get along fine without protection
>> against this attack.  And it might not even be an attack -- you
>> could envision cases with "x5u" where the signer purposely
>> presents different certificates to different relying parties! So
>> the blanket requirement that these fields MUST be integrity
>> protected is not appropriate.  It is only required for certain
>> special situations using certificates.  Proposed revision:
>> Delete: "These Header Parameters MUST be integrity protected if
>> the information that they convey is to be utilized in a trust
>> decision."
> 
> Researching the history a bit more, this text was added to address
>  issue #104 http://trac.tools.ietf.org/wg/jose/trac/ticket/104 
> raised by Jim Schaad.  Unless Jim agrees that it is now somehow 
> unnecessary, I don't believe that it's reasonable for us to now 
> remove it.  Also, see Jim's related comments about trust statements
> and trust decisions in issue #74.
> 
> 
> I would note that issue #104 was closed without any discussion on 
> the list (AFAICT).  And that issue only related to "jku", so the 
> extension to all the other fields is unnecessary.  See my response 
> to Jim for why it's not necessary for "jku" either.
> 
> As far as issue #74, that appears to be about not using the URI as 
> an element of the trust decision unless the identity in the URI is
> different attributes may be issued over the same public key, there
>  is a risk that one of these certificates may be substituted for 
> another. In such situations, the creator of a JWS object MUST 
> integrity protect the "x5u", "x5c", "x5t", and "x5t#S256" 
> attributes, if present."
>> 
>> For what it's worth, Sean had us add language in a number of
> places that basically said that information is only as trustworthy
>  as its source and the means by which it is obtained.  If I 
> remember correctly, this was one of those places.
>> 
>>> 
>>> Section 2. In the definition of "Unsecured JWS", it would be 
>>> good to note
> that this requires
>>> "alg" == "none".
>> 
>> OK
>> 
>>> Section 3.3. Why doesn't this section have a JSON-encoded form 
>>> as well?
>> 
>> Because it's meant to be a simple introductory example to help
> people get their head around the concept - not a complete
> tutorial. Other examples of JSON-encoded objects are found
> elsewhere in the document and lots of them are found in
> draft-ietf-jose-cookbook.
>> 
>>> Appendix A.5. I would prefer if this example could be removed. 
>>> JWT is the
> only use case for
>>> Unsecured JWS right now, and there's already an example in 
>>> that
> document.
>> 
>> Mike> Given that it's important that implementers using them
> understand Unsecured JWSs, there is motivation to retain the 
> example.  I'd be interested in what others in the working group 
> think, given that there was substantial support for retaining this
>  functionality when its removal was proposed.
>> 
>>> _______________________________________________ jose mailing 
>>> list [email-masked] <mailto:[email-masked]> 
>> Thanks again! -- Mike
> _______________________________________________ jose mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/jose
> 

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: Mike Jones <[email-masked]>
Date: Tue, 21 Oct 2014 19:05:57 +0000

> It's worth noting that the multi-signer case reduces to the single-signer case, e.g.:
> 
> <script>
> var JWS = get_jws();
> } else if (! ("signature" in JWS) && (("protected" in JWS) || ("header" in JWS))) {
>   throw "malformed JWS";
> }
> Or copy "payload" up into each signature object.  Or iterate through signatures and see which ones work.  Either way, you're going to build this with a "verify single signature" primitive.
>  
> If you look at existing uses for signed objects (such as they are), single-signer is by far the dominant use case, so requiring the multiple signer notation is would almost always be superfluous syntax.
> I'm not all that concerned about support for multi-sig.  If implementations care about it, it will get built.  And because of the way this has been designed, it's easy to build once you've got the single-signer version (see above).
> 
>  

There appears to be working group support for this position and the related position for JWE.  I'm writing to let you know that, unless I hear objections from the working group in the next few days, I will plan to accept this suggestion and incorporate it into the -36 drafts.

				-- Mike