Subject: [jose] #25: Detached content for the ALTO use case

From: "jose issue tracker" <[email-masked]>
Date: Tue, 25 Jun 2013 06:00:47 -0000

#25: Detached content for the ALTO use case

 When the ALTO use case was originally presented to the JOSE WG, it was
 does as a detached content signature.  The content would be carried in the
 HTTP body while the signature would be carried in the header.  This
 permits a roll out of the signature into current ALTO systems in a way
 that is backwards compatible.

 The current JWS documents do not have any way of doing a detached content
 signature encoding.  The following decisions need to be made:

 1.  Does the JOSE document support this use case or not?
 2.  If it does support this, does it do it by direct or indirect inclusion
 of the content?

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-jose-json-web-
  [email-masked] |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  json-web-    |    Version:
  signature              |   Keywords:
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/25>
jose <http://tools.ietf.org/jose/>

---

From: "jose issue tracker" <[email-masked]>
Date: Wed, 26 Jun 2013 00:08:09 -0000

Comment (by [email-masked]):

 Detached signatures was one of the complicated features of XMLDSIG that
 caused substantial interop problems.  I’d thought that there was already
 substantial sentiment in the working group not to do this because of the
 high complexity/benefit ratio.

 The good news, however, is that a form of detached signatures is EASY to
 build one layer up the stack by signing a hash of the detached content.
 ALTO could easily do this.

 There’s already a deployed example of this, in fact.  OpenID Connect
 includes a hash of the OAuth Access Token as a claim in the ID Token
 issued with it.  This allows the holder of the ID Token to verify that
 token substitution of a different Access Token value has not been
 performed by an attacker.  This works with JWS as it is today.

 I therefore suggest that we recommend this technique to ALTO and add a
 description of it in the ALTO section of the Use Cases document and close
 this issue as “won’t fix”.

  signature              |  Resolution:
 Keywords:               |

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/25#comment:1>
jose <http://tools.ietf.org/jose/>

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 26 Jun 2013 16:46:51 -0700

I completely disagree with your characterization that detached signatures was either a complicated feature or that it caused interop problems.  The problems that I always had with XMLDSig were XML problems and had nothing to do with the question of detached or non-detached, canonizied or non-canonicized.  The problem was always that XML itself was not a good thing to try and produce a usable and reproducible octet stream for the purposes of hashing.  If you just processed it as a binary stream in a disk file then there were no problems (assuming that you had not re-written it in some way).

I also disagree that it would be any easier to do a detached signature using an indirect rather than direct form.  If you are worried about having things change because it is a detached content, then it makes no difference if that detached content is either directly or indirectly reference.  I don't think that going to an indirect form fixes this problem in any way.

Finally, if we are going to say this is the way to do things, we need to define a way to do this in the JOSE drafts themselves.  This would expected to be a standard technique that is used by a number of different systems.  It should therefore be a common method for doing it because otherwise you get many different ways of doing it that are designed by non-security people and therefore prone to error.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> jose issue tracker
> Sent: Tuesday, June 25, 2013 5:08 PM
> To: [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [jose] #25: Detached content for the ALTO use case
> 
> caused substantial interop problems.  I d thought that there was already
> substantial sentiment in the working group not to do this because of the  high
> complexity/benefit ratio.
> 
>  There s already a deployed example of this, in fact.  OpenID Connect
> includes a hash of the OAuth Access Token as a claim in the ID Token  issued
> with it.  This allows the holder of the ID Token to verify that  token substitution
> of a different Access Token value has not been  performed by an attacker.
> This works with JWS as it is today.
> 
> description of it in the ALTO section of the Use Cases document and close  this
> issue as  won t fix .
> 
> --
> -------------------------+----------------------------------------------
> -------------------------+---
> -------------------------+----------------------------------------------
> -------------------------+---
> 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: John Bradley <[email-masked]>
Date: Wed, 26 Jun 2013 21:19:41 -0400

The problem is describing the detached thing in a way that will allow for correct verification. 
SOAP has a number of interesting things that can happen by getting the receiver to verify one header part but use another for processing.
XMLdsig wrapping attacks exist and are to some minds related to detached signatures.

In Connect the claim defines exactly how to find the detached body.

Leaving it to the application layer to define where the detached body is to be located is not unreasonable.

How are you thinking of doing that in a generic and secure enough way to be useful in JWS itself?

The signature itself is not really the hard part.

As an example of a detached body that might be useful to look at is signing a HTTP request for OAuth and including the JWS in a header.  How in a generic JWS way would you describe how to assemble the body to be hashed? 

In principal I see lats of uses at the application layer for sending a hash of something in a JWS where the application layer describes how to assemble some custom content for hashing, but I have a hard time seeing that happen in a interoperable way in JWS.   I could be wrong and am interested in concrete proposals.

John B.

---

From: sakimura <[email-masked]>
Date: Thu, 27 Jun 2013 11:27:07 +0900

I was writing almost exactly the same thing. 

I am interested to hear why it would not work by defining how to hash 
whatever the content and sign it with JWS and include the compact
serialization in 
a HTTP header like 'x-alto-signature'.  

Nat

On Wed, 26 Jun 2013 21:19:41 -0400, John Bradley <[email-masked]>
wrote:
> The problem is describing the detached thing in a way that will allow
for
> correct verification. 
> SOAP has a number of interesting things that can happen by getting the
> receiver to verify one header part but use another for processing.
> As an example of a detached body that might be useful to look at is
> signing a HTTP request for OAuth and including the JWS in a header.  How
in
> a generic JWS way would you describe how to assemble the body to be
hashed?
> 
> 
> In principal I see lats of uses at the application layer for sending a
> hash of something in a JWS where the application layer describes how to
> assemble some custom content for hashing, but I have a hard time seeing
> that happen in a interoperable way in JWS.   I could be wrong and am
> interested in concrete proposals.
> 
> John B.
> 
>> I completely disagree with your characterization that detached
>> signatures was either a complicated feature or that it caused interop
>> problems.  The problems that I always had with XMLDSig were XML
problems
>> and had nothing to do with the question of detached or non-detached,
>> canonizied or non-canonicized.  The problem was always that XML itself
>> was not a good thing to try and produce a usable and reproducible octet
>> stream for the purposes of hashing.  If you just processed it as a
binary
>> stream in a disk file then there were no problems (assuming that you
had
>> not re-written it in some way).
>> 
>> I also disagree that it would be any easier to do a detached signature
>> using an indirect rather than direct form.  If you are worried about
>> having things change because it is a detached content, then it makes no
>> difference if that detached content is either directly or indirectly
>> reference.  I don't think that going to an indirect form fixes this
>> problem in any way.
>> 
>> Finally, if we are going to say this is the way to do things, we need
to
>> define a way to do this in the JOSE drafts themselves.  This would
>> expected to be a standard technique that is used by a number of
different
>> systems.  It should therefore be a common method for doing it because
>> otherwise you get many different ways of doing it that are designed by
>> non-security people and therefore prone to error.
>> 
>> 
>>> issued
>>> Ticket URL:
>>> <http://trac.tools.ietf.org/wg/jose/trac/ticket/25#comment:1>

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 27 Jun 2013 09:33:17 -0700

I agree that forcing the application layer to figure out where and what the
detached content is makes compete sense.  This would be true if we did
detached signatures or indirect content hashing.

For indirect content hashing I think we would need to define the following:

1.  An object structure
2. A media type for that structure
3. How to do an array of references (it is possible that we would just only
allow one but I don't know that this makes sense)
4. A member for a hash value
5. A member for a hash algorithm
6. A set of hash functions with the appropriate registration
7. A member name for a content identifier in the event that we allow
multiple references (optional element)

I also think it would make sense to evaluate two sets of rules for
evaluation that an application can just reference

All or nothing - all of the contents need to be found and evaluated for the
signature to be considered to be valid
Optional checking - the contents are checked independently from the
signature processing.  Hash values are checked when and as needed.

> From: John Bradley [mailto:[email-masked]]
> Sent: Wednesday, June 26, 2013 6:20 PM
> To: Jim Schaad
> Cc: [email-masked]; [email-masked]
> Leaving it to the application layer to define where the detached body is
to be
> located is not unreasonable.
> 
> How are you thinking of doing that in a generic and secure enough way to
be
> useful in JWS itself?
signing a
> HTTP request for OAuth and including the JWS in a header.  How in a
generic
> JWS way would you describe how to assemble the body to be hashed?
> 
hash of
> something in a JWS where the application layer describes how to assemble
> some custom content for hashing, but I have a hard time seeing that happen
in
> a interoperable way in JWS.   I could be wrong and am interested in
concrete
> proposals.
signatures
> was either a complicated feature or that it caused interop problems.  The
> problems that I always had with XMLDSig were XML problems and had nothing
> to do with the question of detached or non-detached, canonizied or non-
> canonicized.  The problem was always that XML itself was not a good thing
to
> try and produce a usable and reproducible octet stream for the purposes of
> hashing.  If you just processed it as a binary stream in a disk file then
there
> were no problems (assuming that you had not re-written it in some way).
> >
using
> an indirect rather than direct form.  If you are worried about having
things
> change because it is a detached content, then it makes no difference if
that
> detached content is either directly or indirectly reference.  I don't
think that
> going to an indirect form fixes this problem in any way.
> >
> > Finally, if we are going to say this is the way to do things, we need to
define a
> way to do this in the JOSE drafts themselves.  This would expected to be a
> standard technique that is used by a number of different systems.  It
should
> therefore be a common method for doing it because otherwise you get many
> different ways of doing it that are designed by non-security people and
> therefore prone to error.
> >
> >
> this

---

From: John Bradley <[email-masked]>
Date: Thu, 27 Jun 2013 12:51:46 -0400

Having a OPTIONAL defined set of claims for a JSON body to point to external objects and there hashes is fine.

We need to consider how that may interact with the JWT spec over in OAuth that defines the claims for a JWT token.

I think that can be done without impacting the core of JWS.

John B.