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

["Jim Schaad" <[e-mail]>]

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.



> -----Original Message-----
> From: John Bradley [mailto:[e-mail]]
> Sent: Wednesday, June 26, 2013 6:20 PM
> To: Jim Schaad
> Cc: [e-mail]; [e-mail]
> Subject: Re: [jose] #25: Detached content for the ALTO use case
> 
> 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.
> 
> On 2013-06-26, at 7:46 PM, "Jim Schaad" <[e-mail]> wrote:
> 
> > 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> >> jose issue tracker
> >> Sent: Tuesday, June 25, 2013 5:08 PM
> >> To: [e-mail];
> >> [e-mail]
> >> Cc: [e-mail]
> >> Subject: Re: [jose] #25: Detached content for the ALTO use case
> >>
> >> #25: Detached content for the ALTO use case
> >>
> >>
> >> Comment (by [e-mail]):
> >>
> >> 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 .
> >>
> >> --
> >>
-------------------------+----------------------------------------------
> >> -------------------------+---
> >> 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/25#comment:1>
> >> jose <http://tools.ietf.org/jose/>
> >>
> >> _______________________________________________
> >> jose mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/jose
> >
> > _______________________________________________
> > jose mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/jose