Re: [jose] Canonical JSON form

Bret Jordan <jordan.ietf@gmail.com> Fri, 23 November 2018 16:49 UTC

Return-Path: <jordan.ietf@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 DF49B130DFF for <jose@ietfa.amsl.com>; Fri, 23 Nov 2018 08:49:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 802h-5ZQ0rJN for <jose@ietfa.amsl.com>; Fri, 23 Nov 2018 08:49:28 -0800 (PST)
Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 8708112F1A6 for <jose@ietf.org>; Fri, 23 Nov 2018 08:49:28 -0800 (PST)
Received: by mail-yw1-xc29.google.com with SMTP id q11so5028430ywa.0 for <jose@ietf.org>; Fri, 23 Nov 2018 08:49:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nUyJfLJ1JCaAockEn85+pwiJINTDn/WXz6IzDeDCUoM=; b=FJz9L8iP7cKslQxh1x/ITjfUWt7o0NQuUEgDUpCLjPX3DQs7VumwnSAW/HgCdLeM9g AR/V1Fd/8j3D3OaeFNZXoSKDGLkjK2eZtXLuvd6KYX/tOERrdXJE1Et6UAlNKJO7obBq 9MqQuelnYZ02zRiCCN47RGTSlL/FBM3K5QHiGBY5SybJzCXkn1l9bkJwKwfq5cY+oSnX DFCajQDEWxE8cQguAB7du+ULs40OExNxlE3ktSOEE0jv0Uhd6waMTKLCe/MdWw+fyUZh dDSIjl8toHCETr6tvDseK6QWLEIWq+bD++Jh6vyEigNWRVl6ceqxrt+0PhkWIj2jMad4 eZkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=nUyJfLJ1JCaAockEn85+pwiJINTDn/WXz6IzDeDCUoM=; b=K8hFax5Q0QAc3Sjg1nUL30JR3UBOoDifCaZRvAuKFvZUW4NNMxoS+PCBuIuHDCMLDl Egl79+WRqgKyQN87m0CZIfkftGV2QRJ1KiNadImFgc+BX8rMsPihgQWfVx8qPWYxA54U TGBdqe2f5dv67AIFcO6FV1roqA/cbtOzTESCSD8OLXtIgj1tHoCG3UxzQvuJr0D4pqWk CsIxKOkdQdtSBBIbfRX8Iq4LHaiy4p536yYa5+F6E/LJ0j1IxxEuL345E8UvtIdz/2dy J/I1aNyKZ9fwE7biPgvRetfDXfSfXTilUKNLJfWdvf0PGyOduvYeOE2AV7hcTF10R9Fo byLw==
X-Gm-Message-State: AA+aEWZMse/cXRr0OtPA/6Gu1IqAvk3jxpkrOJWt0KR8D9m7+59Ddold SZpU/KJ/B2HZekTyO1SXszk=
X-Google-Smtp-Source: AFSGD/UFHWYFpdxe1i816TL5aBSOXro2CnMu47GSjl89fKxN1QCeMz3NMvDDWVfUxjoHYhAJdMMdGA==
X-Received: by 2002:a81:d804:: with SMTP id d4mr11149886ywj.197.1542991767777; Fri, 23 Nov 2018 08:49:27 -0800 (PST)
Received: from ?IPv6:2605:a601:3260:266:89ef:6bee:8279:6d45? ([2605:a601:3260:266:89ef:6bee:8279:6d45]) by smtp.gmail.com with ESMTPSA id a71sm10308083ywe.66.2018.11.23.08.49.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Nov 2018 08:49:27 -0800 (PST)
From: Bret Jordan <jordan.ietf@gmail.com>
Message-Id: <C15EAFFA-1AC6-46DC-A5A1-68C666CB1241@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_915CC0C3-B723-4C4F-8880-019AFEE8C9F4"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 23 Nov 2018 09:49:16 -0700
In-Reply-To: <600798e5-21b4-2ca2-44f2-3702d6aeb4c0@gmail.com>
Cc: David Waite <david@alkaline-solutions.com>, Jim Schaad <ietf@augustcellars.com>, Carsten Bormann <cabo@tzi.org>, jose@ietf.org
To: Anders Rundgren <anders.rundgren.net@gmail.com>
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> <600798e5-21b4-2ca2-44f2-3702d6aeb4c0@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/LOyrkB1HE59tysgXD1M-IP9x0K4>
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: Fri, 23 Nov 2018 16:49:31 -0000

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 <anders.rundgren.net@gmail.com> 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 <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
>