Re: [jose] Canonical JSON form

Anders Rundgren <anders.rundgren.net@gmail.com> Thu, 22 November 2018 07:26 UTC

Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD4D12D4EA for <jose@ietfa.amsl.com>; Wed, 21 Nov 2018 23:26:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rq2ypAeDlErc for <jose@ietfa.amsl.com>; Wed, 21 Nov 2018 23:26:47 -0800 (PST)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6407128C65 for <jose@ietf.org>; Wed, 21 Nov 2018 23:26:46 -0800 (PST)
Received: by mail-wr1-x42d.google.com with SMTP id j10so8143360wru.4 for <jose@ietf.org>; Wed, 21 Nov 2018 23:26:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=lg81Bd40qJ07MfK9jLC4DpTpzHLtNhHn5ZWLZ0aNUMU=; b=oaY0P7t7f2gnV8dRJsWBel3zXG5ZCO6/L5dfcINzEWkB0OljN4uq0Dm3x6Pf9SfBD/ 31No18gk/wNrdwHPblQNsuB4EMA+nFYi3RFr67+WJIL3eCVYFVx0M69i1UDJDRAJ3IKm HZUuj+szVJXMb49G3E6O2PEHGrX/x7RZy2ShcNtLi/Qy57LbpoNCqKURvs3xAuXefBDU ksUoMyYBMRTIKTrm6VxY31uVP4EVHtaQVLUx6cZP8065IjMpBX29jzaO30j1TgEHTyw/ VoaAkdQ6P8PQ8PMIacp/Ik68uPOLKRSHM8vR4cnMLlc3377Ka1y4+Evz0L/vgUjOAjva MqQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lg81Bd40qJ07MfK9jLC4DpTpzHLtNhHn5ZWLZ0aNUMU=; b=NpdzrOLvf2DGJzzoA8Imskd+OHijDSNPv7VCfIfP4MN1ajzGU6XVp6st5Ty1rXwsvR NoVqA10T24V6k4WLwWH+7Ovtnp+mMLd5OvOZuQCEAhbfJ/hd4MS1yz7J4hw8oCCiIr3y c3UI63grDx00XV4FRKJxQsjKKrfUSNRegYZoREMg0eJJSdtxo5ydr01DqGwI3nmBHNwv vsuJk+KmMnObYDI9y6FWT7EXCAUMM+akEw6ICi7+TeI4dlclf4fKoA07Vspz5bPFJ6H6 hWBwJ/SfllvYFHl9nn//Mo+RrBay+xPRm5ndrUbscr5+ahmLZbxssxXfEicAyJYWd5aH O8jA==
X-Gm-Message-State: AA+aEWZTfHtZTEwUFXJfLIpaME8f1E3Y2OccyjC+QdvZcbR2zNWYqtKq vauHzf8gNUpFBJK3O6U9LCIZMzy/
X-Google-Smtp-Source: AFSGD/VGwNL5EOHKA3EUqdMYEGDTK1TgJXvpGBgcwTJYx8X1NP2bzcU+0ihcU3sE9mpt1euI1SzoCg==
X-Received: by 2002:adf:b608:: with SMTP id f8mr8243606wre.120.1542871604523; Wed, 21 Nov 2018 23:26:44 -0800 (PST)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id 5sm5485176wmw.8.2018.11.21.23.26.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Nov 2018 23:26:43 -0800 (PST)
To: Bret Jordan <jordan.ietf@gmail.com>
Cc: David Waite <david@alkaline-solutions.com>, Jim Schaad <ietf@augustcellars.com>, Carsten Bormann <cabo@tzi.org>, jose@ietf.org
References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <CAOASepM=hB_k7Syqw4+b7L2vd6E_J0DSAAW0mHYdLExBZ6VBuw@mail.gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <MEAPR01MB35428606C09BF315DE04CC79E5E10@MEAPR01MB3542.ausprd01.prod.outlook.com> <CAHbuEH6DCD7Zc+PK3TnCBkKv1esnROwyCcDb8ZR+TKwgQQ+yXQ@mail.gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <CAHbuEH5oH-Km6uAjrSr0pEHswFBLuDpfVweQ+gpj472yk+8iTQ@mail.gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <A37D69B1-6B77-4E11-8BB9-A0209C77752C@tzi.org> <434fbdb6-0202-5a02-4cec-9332fbbe548c@gmail.com> <FBBFA6FA-4B0C-4239-9145-0B713120EC98@tzi.org> <01fd01d47f5f$4c4889f0$e4d99dd0$@augustcellars.com> <7b1d293c-1d97-44e4-0cd8-55ec1db6c3b5@gmail.com> <AD2DB2EB-3F06-4C55-94E4-CED60F6FF4CF@alkaline-solutions.com> <CADEL5zvbLOtuFBD6zgEpcUQZ2Y7hNYHxLcj=EhkEOnV-_dqwJQ@mail.gmail.com> <E7458037-AC7A-4C84-870F-9BDAEA420357@gmail.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <600798e5-21b4-2ca2-44f2-3702d6aeb4c0@gmail.com>
Date: Thu, 22 Nov 2018 08:26:41 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <E7458037-AC7A-4C84-870F-9BDAEA420357@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/JHp5mrXyxH3aW90gI5cE9l7Okq4>
Subject: Re: [jose] Canonical JSON form
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Nov 2018 07:26:50 -0000

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 <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>>
>>
>>
>> On Sun, 18 Nov 2018, 20:37 David Waite <david@alkaline-solutions.com <mailto:david@alkaline-solutions.com> 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 <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>>     >
>>     > There's no mystery going on here.  The TEEP folks needed Signed Data rather than Signature objects with embedded Data.
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org <mailto:jose@ietf.org>
>> https://www.ietf.org/mailman/listinfo/jose
>