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. On 2013-06-27, at 12:33 PM, "Jim Schaad" <[email protected]> wrote: > 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:[email protected]] >> Sent: Wednesday, June 26, 2013 6:20 PM >> To: Jim Schaad >> Cc: [email protected]; [email protected] >> 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" <[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
