Re: [jose] Canonical JSON form

<Axel.Nennker@telekom.de> Thu, 11 October 2018 19:10 UTC

Return-Path: <Axel.Nennker@telekom.de>
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 E824F12008A for <jose@ietfa.amsl.com>; Thu, 11 Oct 2018 12:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.764
X-Spam-Level:
X-Spam-Status: No, score=-2.764 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
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 M30gC-AYBOlO for <jose@ietfa.amsl.com>; Thu, 11 Oct 2018 12:10:26 -0700 (PDT)
Received: from mailout34.telekom.de (MAILOUT34.telekom.de [194.25.225.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A396B130F0F for <jose@ietf.org>; Thu, 11 Oct 2018 12:10:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1539285025; x=1570821025; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uvRHnlkMdC/B6Z03ot0U5Oi2jSKnrAWG+UJQm3IUp8I=; b=1zXcpkCmrHm3JigA/GA5Umum3xkKMxBzsCMUIct5yh8YCE4efPH7tIJV ELKPc9RJFTYD1dQ5gX3XiqKtOY0NimeJVD6TI4fujM3PQVUpuZe5nVuQr W7ITCKpRNWPN4yf60tuMkL9pRbWZ8FZZ/NHI6I2sZ3cx/cd/IR9e0Fvz/ d08sYerSLdIn/5r0PKRsoKUn+WurXWEYYCWvs2lde5igRIBsrYIh3/RpM fCqDK90Z76YvfemaIsRD33lQIpv9V0FkYTzuCq0F4jRWZrYF6fDVwnDJg f0G2pyibwdbr2+caw5+/esBCwgxz60tqL+it6wPY+g6Qmh8lN8WBWFq0d A==;
Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2018 21:10:22 +0200
X-IronPort-AV: E=Sophos;i="5.54,369,1534802400"; d="scan'208,217";a="271633717"
Received: from he105789.emea1.cds.t-internal.com ([10.169.118.28]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 11 Oct 2018 21:10:22 +0200
Received: from HE101953.EMEA1.cds.t-internal.com (10.169.118.78) by HE105789.emea1.cds.t-internal.com (10.169.118.28) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Oct 2018 21:10:22 +0200
Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE101953.EMEA1.cds.t-internal.com (10.169.118.78) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 11 Oct 2018 21:10:22 +0200
Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.15) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 11 Oct 2018 21:10:19 +0200
Received: from LEXPR01MB1087.DEUPRD01.PROD.OUTLOOK.DE (10.158.170.9) by LEXPR01MB1085.DEUPRD01.PROD.OUTLOOK.DE (10.158.170.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.28; Thu, 11 Oct 2018 19:10:20 +0000
Received: from LEXPR01MB1087.DEUPRD01.PROD.OUTLOOK.DE ([fe80::4c1d:345:7b40:8da7]) by LEXPR01MB1087.DEUPRD01.PROD.OUTLOOK.DE ([fe80::4c1d:345:7b40:8da7%2]) with mapi id 15.20.1207.029; Thu, 11 Oct 2018 19:10:20 +0000
From: <Axel.Nennker@telekom.de>
To: <phil.hunt@oracle.com>, <kathleen.moriarty.ietf@gmail.com>
CC: <James.H.Manger@team.telstra.com>, <jose@ietf.org>, <jordan.ietf@gmail.com>
Thread-Topic: [jose] Canonical JSON form
Thread-Index: AQHUYMwaB98XZpFud0i4H76S15NehKUY2XsAgAAaOgCAAAPogIAAL5qAgAACeoCAAAeegIAAFeAAgAEFmQCAAAvBAIAABMIAgAAKBKA=
Date: Thu, 11 Oct 2018 19:10:20 +0000
Message-ID: <LEXPR01MB108728E1534F022A779A9883EDE10@LEXPR01MB1087.DEUPRD01.PROD.OUTLOOK.DE>
References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <CAOASepNX4aYVmPWXyODn0E2Om_rimACPECqJBvZSOXVVd_p8LA@mail.gmail.com> <D21F3A95-0085-4DB7-A882-3496CC091B34@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>
In-Reply-To: <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Axel.Nennker@telekom.de;
x-originating-ip: [212.201.104.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; LEXPR01MB1085; 6:o4Zgq6876AxK1/fZgyIHTLUCJ3DqqWm1VzWlDtRZnUhAPZWwkOrLfGVxGa4RYG0/tyYjdEGq1Y94+9V/AP3cEW7d7c3vWESXBzFtzHVC3F03YstK8t9DTv7EQn6g+DeRqmCgjqHnZkjdLNu9aVeHMXt6nT1Qc85WjAWzEweDdJRG59EPZT2rZOZcoz5p9rFJrX0WzKTTO1fVm4mCpt4U3u8rGWZmGGkqzmq8utmlkl+JW32a+ZwIxTzKCAn5QTBkaSlZiKpPNcjXYhaBDz2dzSHUs63ljKLz3OlSGWmJeb9gMEdpLXG3UezB6BjDgwsPrAlwluRHGzOO6s2F8SZbB2cMp/IdivBsz5+CV79takUryfh3rija4j0Hmh+VmyYNhqOs8rTB3UWwJwhdagY8M344FQi5g+HhlUGm06o0XQF2vmcDUcEXaNtkotOE+F+LrXbo/RbVUeAF6wpvD4oaTQ==; 5:1W+/IAHO7yhX6drHZcuXi4Y8vTV/0fshqXZCi2gfE81Y9TPDUrzIdApjXmDJv1te0rnYeJTYkU7sA1oxtB6wDqKCI+0D1n4n4EFOnWyQi1lPXu76dVE0Uai+5dGDcN7t2cQmA9AlQOFjf0t71MrlVZZMDHaiIjhN1i1LDspl8fw=; 7:7oEPkk1J2sxDqm1If2gncHmNecZ5hqukLPk+IzgyyqzVY66QBBmixbWs/BFn5GIV6rPbN8rqY4NddX89CQA17/izgl2F/q1gy2aSsVyHEQ9E8EqhgCdxACJJLVx7lZW3p8aa6Um0A8CKcDbXrOp+Hdhzt/pDdOtf1GnOMGUbP+YsgtGYaZ2pe7JtnijGab7tCgMNm+2aq6+/jEs+NImlsK91OUHC9hjfrIWR/XpyO5t6KfxdFfCQa44vmvFfsilJ
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 0a41ee82-fef3-484d-f8f8-08d62fad307f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:LEXPR01MB1085;
x-ms-traffictypediagnostic: LEXPR01MB1085:
x-microsoft-antispam-prvs: <LEXPR01MB10856670F28F3F87962D0E76EDE10@LEXPR01MB1085.DEUPRD01.PROD.OUTLOOK.DE>
x-exchange-antispam-report-test: UriScan:(85827821059158)(272811157607776)(67441168502697)(146099531331640)(10436049006162)(21748063052155)(28532068793085)(190501279198761)(227612066756510)(163750095850);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231355)(944501410)(4982022)(52105095)(93006095)(93001095)(3002001)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991060); SRVR:LEXPR01MB1085; BCL:0; PCL:0; RULEID:; SRVR:LEXPR01MB1085;
x-forefront-prvs: 08220FA8D6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(136003)(366004)(39860400002)(199004)(189003)(110136005)(966005)(478600001)(68736007)(5660300001)(4326008)(6246003)(2900100001)(14454004)(53386004)(6306002)(54896002)(229853002)(72206003)(19609705001)(2906002)(86362001)(446003)(7736002)(33656002)(11346002)(1680700002)(186003)(561944003)(476003)(39060400002)(6116002)(790700001)(3846002)(486006)(66066001)(256004)(106356001)(105586002)(102836004)(316002)(14444005)(26005)(66574009)(9686003)(81166006)(53936002)(55016002)(54906003)(236005)(606006)(75402003)(71190400001)(74482002)(97736004)(93886005)(8676002)(8936002)(52396003)(5250100002)(76176011)(81156014)(7696005)(71200400001)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB1085; H:LEXPR01MB1087.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-microsoft-antispam-message-info: N3/x/PaHzmSYH1MdOkcqSA7a0XnLL6G/EHUkyz+qg9kDEL3GQVoTZk+dxnj3wl+8amonvsXY/xjrk3wGPBQkMX/ishzqf/POSyYPLu3+6XpbKd3rTeYRjmSwrbEGww9AeBwhPztC03SaTL4XnG6dvJ6Dj0z1XiCCconRrb3kNPG4rhiCDOKPN50hUr9+HiMOC0WjSLhb5u0BCq4qfoifPjcgZmjRyGM8Pqt5cxSjW/fZj5MkeAWnY8+FMZqsmnKNmb7XHwpAFQEZ6wr4hFFLHfntXrwkF94lYVJDRTS/yYUCCD+9Y+UxAv7hHvGXiCspRWL98KWPkt4mz7T5lp/Gh0E8tb+G24xV/PZKlrJbGB8=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_LEXPR01MB108728E1534F022A779A9883EDE10LEXPR01MB1087DEUP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0a41ee82-fef3-484d-f8f8-08d62fad307f
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2018 19:10:20.8732 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB1085
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/D9PXf1fR4nIHnqk7X_M4QO1LVtI>
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, 11 Oct 2018 19:10:31 -0000

I very much agree with Phil. Xmldsig was a pain for developers, libraries did it differently thus causing interoperability problems.
Jose was designed simple but a canonical JSON form introduces new complexity.
We had the same with Oauth1 – developers were not able to sort the URL parameters according to the spec.
So jose is better off without canonical JSON.

//Axel


From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Donnerstag, 11. Oktober 2018 20:23
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Cc: Manger, James <James.H.Manger@team.telstra.com>om>; jose@ietf.org; Bret Jordan <jordan.ietf@gmail.com>
Subject: Re: [jose] Canonical JSON form

I am not sure of the value of canonicalization.  I prefer bytestream encoding style where the original content goes with the signature.

Another example is ATLAS which signs encoded http requests.

Some JSON formats will have the same issues that XMLDSIG had.  For example, SCIM supports multiple ways to identfiy attributes much like XML (it uses IANA registered schemas). You can reference an attribute with the full path or just its name.  We tried to avoid schemas, but localized extensibility and easy of coding forced us to do this.  So for SCIM it is easier to canonicalize than XML, but I would not say simple.

In the end, I felt it was a good trade-off because of an assumption to sign encoded json data instead.

Note:  SCIM does not yet have a signed format. I anticipate however the development of signed SCIM events per the new SET spec.

If you were to proceed, I would recommend including considerations identifying JSON formats not well suited to canonicalization.

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<http://www.independentid.com>
phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>


On Oct 11, 2018, at 11:06 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com<mailto:kathleen.moriarty.ietf@gmail.com>> wrote:

Hi Bret,

JOSE is closed, so a new WG would have to be formed if this were to be done in a WG.  That might be reopening JOSE or something else.  Another possibility is for James to try to progress his existing draft and determine interest.  Has it been presented at SecDispatch yet to gauge interest and uncover problems?

You could also consider alternate solutions.  The problems cited were problems with XML already.  Since RID defined the same capability, you could test out interoperability using RID in XML more extensively as you'd be mapping the same functionality into JSON.  This would give you in your new effort feedback into design considerations and help you determine if you really want to go this route or perhaps some other solution may be preferred (see Neil's message).  In any case, more work should be done before a new WG around canonicalization is performed IMO, but I am also no longer an AD, so advice from current ones may vary :-)

Best,
Kathleen

On Thu, Oct 11, 2018 at 1:24 PM Bret Jordan <jordan.ietf@gmail.com<mailto:jordan.ietf@gmail.com>> wrote:
Kathleen,

From your comments I take it is okay then to do a draft proposal in another WG and then have this mailing list review it?  Would we then restart JOSE if the draft was good to have it standardized in JOSE or just some other WG?

I just want to be sensitive to the work that has already been done and build on it.  I also do not want to do things that are “bad form”.  We are all in this boat together, and I just want to work with everyone to row in the same direction.

BTW, I have spoken with a few other vendors and service providers and they are also very interested in this work as it would solve a lot of problems they have or are seeing.

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 Oct 10, 2018, at 7:47 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com<mailto:kathleen.moriarty.ietf@gmail.com>> wrote:

Bret,

You could define it within a draft in a different working group other than JOSE and ask for reviewers from JOSE to review and comment to catch problems.  Although already described above, there are issues with this and JSON, which is why the WG didn't want to do canonicalization.

I'm assuming you want to do basically what was done for RID in XML using JSON.  You may want to look at the set of possibilities to replicate as they are all likely needed with what you are trying to do or just as part of your gap analysis.

https://tools.ietf.org/html/rfc6545#section-9.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6545-23section-2D9.1&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MMo12b48B6GqvKdy8eBzH6ZAMMue9XSrSjSfwjHnqkQ&s=22u9NErU0ozC5-MfcgjryGcdeGT_X5t9OCSSYtvY-a0&e=>
Also look at 9.3.1 and 9.3.2 as you're likely to also need multi-hop authentication too.

To David's point in the message that follows this (came in while typing), RID signed portions of the message to enable interoperability and you are likely to need to do very similar things that are described in RID related to the policy work I had previously mentioned for your gap analysis as being similar functionality.  If you haven't looked at that part of the document, I think it will be helpful.

Best regards,
Kathleen



On Wed, Oct 10, 2018 at 8:29 PM Manger, James <James.H.Manger@team.telstra.com<mailto:James.H.Manger@team.telstra.com>> wrote:
https://tools..ietf.org/html/draft-rundgren-json-canonicalization-scheme<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Drundgren-2Djson-2Dcanonicalization-2Dscheme&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MMo12b48B6GqvKdy8eBzH6ZAMMue9XSrSjSfwjHnqkQ&s=sZq9Tv1-r2RLEkVR50tXkMNdFi6nOmqWmEkuNbdTJio&e=>
is a decent attempt at JSON canonicalization (and an appendix lists a few other attempts).
This one sorts object members based on their UTF-16 encoding (without escapes), and assumes double precision floats is the model for numbers.

--
James Manger

From: jose [mailto:jose-bounces@ietf.org<mailto:jose-bounces@ietf.org>] On Behalf Of Bret Jordan
Sent: Thursday, 11 October 2018 11:02 AM
To: Jim Schaad <ietf@augustcellars.com<mailto:ietf@augustcellars.com>>
Cc: Nathaniel McCallum <npmccallum@redhat.com<mailto:npmccallum@redhat.com>>; jose@ietf.org<mailto:jose@ietf.org>
Subject: Re: [jose] Canonical JSON form


Other implementations say that you should preserver the order of the fields you read when serialized which is part of JSON for the browser implementations but not necessarily elsewhere.

Preserving order is hard.  Depending on your programming language you might be deserializing the content in to a struct or you may be using a map.

What I need is a way for individuals and organizations to be able to pass around and share JSON data and collaboratively work on that JSON data and sign the parts that they have done.



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."


_______________________________________________
jose mailing list
jose@ietf.org<mailto:jose@ietf.org>
https://www.ietf.org/mailman/listinfo/jose<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MMo12b48B6GqvKdy8eBzH6ZAMMue9XSrSjSfwjHnqkQ&s=68ephlmudUEVF-9EE70huCbhCWZMtZFLhQwmunkXcbc&e=>


--

Best regards,
Kathleen



--

Best regards,
Kathleen
_______________________________________________
jose mailing list
jose@ietf.org<mailto:jose@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf..org_mailman_listinfo_jose&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MMo12b48B6GqvKdy8eBzH6ZAMMue9XSrSjSfwjHnqkQ&s=68ephlmudUEVF-9EE70huCbhCWZMtZFLhQwmunkXcbc&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MMo12b48B6GqvKdy8eBzH6ZAMMue9XSrSjSfwjHnqkQ&s=68ephlmudUEVF-9EE70huCbhCWZMtZFLhQwmunkXcbc&e=>