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" <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf Of >> jose issue tracker >> Sent: Tuesday, June 25, 2013 5:08 PM >> To: [email protected]; >> [email protected] >> Cc: [email protected] >> Subject: Re: [jose] #25: Detached content for the ALTO use case >> >> #25: Detached content for the ALTO use case >> >> >> Comment (by [email protected]): >> >> 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- >> [email protected] | [email protected] >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
