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
