And I am okay with finding something in the middle as you suggest. Even if we have to call out the cases where the solution will not work. Getting a solution that works for the 70% use case would be a huge win.
Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." > On Nov 22, 2018, at 12:26 AM, Anders Rundgren <[email protected]> > wrote: > > On 2018-11-18 22:52, Bret Jordan wrote: >> Andres, >> I fully support working on this. Can we have a meeting / BOF in Prague to >> talk through this and get everyone on the same page..? >> I think some simple and clear examples might help everyone. > > The TEEP OTrP use case might serve that purpose. In short every OTrP message > is tagged by an outer object type ID like in this extremely condensed example > using JWS compact mode: > { > "car": "jws-header.car-json-object-encoded-in-base64url.jws-signature" > } > > A problem with this scheme is that since "car" is unsigned it can be replaced > by something else and the signature will still validate. The OTrP designers > addressed this deficiency by mandating an inner (signed) object type id. > Obviously these MUST be compared in order to form a complete signature > validation scheme. > > Using detached JWS [1] combined with JCS [2,3] you sign the entire JSON > object as well as keeping it in JSON format: > { > "car":{ > "brand": "Ferrari", > "horsePower": "450", > "weight": "2357kg" > }, > "signature": "jws-header..jws-signature" > } > > > Anyway, the core issue seems to be proving that JSON canonicalization > actually is a realistic alternative. IMHO, it is usually easier doing the > opposite; showing why something won't fly. Personally, I believe that there > is meaningful life between between "flawless" and "broken" :-) > > Thanx, > Anders > 1] https://tools.ietf.org/html/rfc7515#appendix-F > 2] https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01 > 3] https://mobilepki.org/jws-jcs > >> 1) What is being proposed >> 2) Why it is needed >> 3) Why JOSE/COSE is not working for us >> 4) Possible solutions to this problem >> Thanks, >> Bret >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can >> not be unscrambled is an egg." >>> On Nov 18, 2018, at 2:03 PM, Anders Rundgren <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> >>> On Sun, 18 Nov 2018, 20:37 David Waite <[email protected] >>> <mailto:[email protected]> wrote: >>> >>> Not to be a jerk (I promise!), but is there documentation of the TEEP >>> issues with using JWS/JWE structure? >>> >>> The existing specs seem to use JOSE as-is, I didn’t immediately see >>> anything on the ML or in GitHub issues. >>> >>> >>> Correct. Since the requirement was using standardized security solutions >>> but also maintaining a reasonable message structure, they didn't have any >>> option but adding a redundant layer like the TAInformation / >>> TAInformationTBS pair. >>> >>> I was in a similar position having a bunch of systems to be converted from >>> XML to JSON. Unlike TEEP, I had the freedom to select any working solution >>> which is the background to this work.. >>> >>> >>> >>> It is difficult to fairly argue a specific desired solution to a >>> non-disclosed problem set. Especially when so many people have battle scars >>> from implementing that solution in the past. >>> >>> >>> Implementing, documenting and verifying this concept took quite some time >>> but apart from a math bug in .NET there were no surprises whatsoever. >>> >>> The problem set is described, here is a short version: >>> - Keeping signed JSON in JSON format >>> - Enabling a consistent message structure regardless if messages are signed >>> or not >>> - Supporting signed JavaScript objects >>> >>> Anders >>> https://mobilepki.org/jws-jcs >>> >>> >>> >>> -DW >>> >>> > On Nov 18, 2018, at 11:06 AM, Anders Rundgren >>> <[email protected] <mailto:[email protected]>> >>> wrote: >>> > >>> > There's no mystery going on here. The TEEP folks needed Signed Data >>> rather than Signature objects with embedded Data. >>> >>> _______________________________________________ >>> jose mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
