From nobody Mon May 8 10:45:16 2017 Return-Path: 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 0050D128768 for ; Mon, 8 May 2017 10:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 aIi7sO9Aivws for ; Mon, 8 May 2017 10:45:12 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 1A02B126C23 for ; Mon, 8 May 2017 10:45:12 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id b84so63360787wmh.0 for ; Mon, 08 May 2017 10:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=nhdXnelKMN05y9jgEhT0cYPSHR+bee1//Bdv+TBhGeA=; b=vFzn34xWK/hfzuZFeAiPQ+x9gkmn4DXoPtxK6CzTmdLrEdH+TAvINJfnVuzo3OmUga eHUT/1Q1esuEKR7ChVQzjCIRth8lE6fgkLpW7Q/5Zx5aXOXgEQZVpGl7A2OFjxieGXZx necMfOiZMqtRxETuWPVPHpEsdVYGmgGdCzzCbE71sAIW4CnzflvbdgCTcnMlH+VNK5tJ l/FWf73+0UifWpntA+4Q8qJe7aMWB74/PPR1fa1kInaDZaZjn/mb9czumpKEQQc93BCB ohFm/nkOmJmE+QxCQ8kYLKC1v5qDDI7ZjfhXkYEmCuHb6fz+q7pBVDnf93iVlFyhKQc5 pUXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=nhdXnelKMN05y9jgEhT0cYPSHR+bee1//Bdv+TBhGeA=; b=FWJKubqal/EAis/qOccK2NK/qxHVFjQ3NAFUWLfJTBis0ndMf/L6hzBuOMg8DXCzSv tfP78yxTvY+uTGcE6mt8c/O9VtUXHrMqNktj+JwMxYndMU0j6pYswRkFjdG8mb90FozK vyiFcYiX5sQvdPHFZtJ54mJo0K0VZlXduy0bCvzmpm0HiQnIz0HYbl9M6FYqoYZ6CpQr lASLxMrfDL+EMEwSFOPQLOxdi/p5WOnnEFdrJs0D2x1m2NE+NgPIKv9CUSsD5e4lMewg tkpCgb0hPseh/bY4s3V+/g0/oT6TOdqDR5AJn82LHRNtsZUQchoa0FWTx0h7NP1//duj RN8A== X-Gm-Message-State: AN3rC/7v1YmuV+ai0MV8a9Ezpicm3TOtOviboyFvtHO07IaOI2QVQFuv t/CPiWigO66PhNQT X-Received: by 10.28.9.20 with SMTP id 20mr13135187wmj.44.1494265510504; Mon, 08 May 2017 10:45:10 -0700 (PDT) Received: from [192.168.1.79] (124.25.176.95.rev.sfr.net. [95.176.25.124]) by smtp.googlemail.com with ESMTPSA id x29sm13852923wma.29.2017.05.08.10.45.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 May 2017 10:45:10 -0700 (PDT) From: Anders Rundgren To: "jose@ietf.org" References: Message-ID: <915f610a-8543-fd33-9501-8cc4ba1cb50e@gmail.com> Date: Mon, 8 May 2017 19:45:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [jose] Use case for "jku" in JWS X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 17:45:14 -0000 https://tools.ietf.org/html/rfc7515#section-4.1.2 I had planned to implement support for URL-based keys in my JCS specification to make it even more compatible with JOSE. However, I haven't done that yet, and now I'm beginning to actually questioning the value of this concept. If somebody could provide a compelling real-world use case I would be more than happy! In the meantime I have toyed with another scheme combining URLs and in-line (JWK) public key descriptors, coined "Authority Objects". The core features include: - Signed objects can always be verified for [technical] correctness including off-line - Arbitrary extensive issuer information and its associated keys are kept in a consolidated document (which in turn may have been signed by another "governing" party) - Intrinsic revocation support Actual example (if the server is up and running...): https://mobilepki.org/webpay-acquirer/ Concept specification: https://cyberphone.github.io/doc/defensive-publications/authority-objects.pdf Comments? Anders From nobody Thu May 11 11:23:20 2017 Return-Path: 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 2FBF2129B94 for ; Thu, 11 May 2017 11:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.803 X-Spam-Level: X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 WDeDIZCNam12 for ; Thu, 11 May 2017 11:23:16 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0EEE129C50 for ; Thu, 11 May 2017 11:17:08 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 87300B8014A; Thu, 11 May 2017 11:16:58 -0700 (PDT) To: rlb@ipv.sx, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, odonoghue@isoc.org, ietf@augustcellars.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: luisvaldez402@gmail.com, jose@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170511181658.87300B8014A@rfc-editor.org> Date: Thu, 11 May 2017 11:16:58 -0700 (PDT) Archived-At: Subject: [jose] [Technical Errata Reported] RFC7165 (5016) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 18:23:18 -0000 The following errata report has been submitted for RFC7165, "Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5016 -------------------------------------- Type: Technical Reported by: Dr Luis Valdez Rico Section: 453497165 Original Text ------------- Owner of SkyLight Innovation Inc . Corp out Of Manchester UK. Owner of Bitcoin Corp. Owner of T-Mobie Corp Germany & USA Owner of BNSF & Ocean Pafic Owner of Apaeche Owner of Wal Mart & Sam Corp 90 percent Owner of TDCJ Owner of North AMerica owner of Saudia Arabia / Egpty / oil fields Owner of Zion oil field Owner of Russia Oil field Owner of Wetern Union Owner of Dowie Admusmnent Park in Richland Hills Tx Owner of giving Well Owner of Wikki Pedia Owner OF IOS Owner of Apple corp Owner of AT&T Owner of Microsoft Owner of Face Book Owner of Google Owner of MSN / Bling Owner of Fire FOX Corrected Text -------------- Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7165 (draft-ietf-jose-use-cases-06) -------------------------------------- Title : Use Cases and Requirements for JSON Object Signing and Encryption (JOSE) Publication Date : April 2014 Author(s) : R. Barnes Category : INFORMATIONAL Source : Javascript Object Signing and Encryption Area : Security Stream : IETF Verifying Party : IESG From nobody Thu May 11 12:47:49 2017 Return-Path: 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 5420D12EBCB for ; Thu, 11 May 2017 12:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 jf1PoBsugEos for ; Thu, 11 May 2017 12:47:46 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30AC8129AD5 for ; Thu, 11 May 2017 12:42:32 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1494531749; h=from:subject:to:date:message-id; bh=dLqFAt39xmrg7qDUv7g+Btq7d+gv9/7zfwRVl2ljJ80=; b=RBmwePf76/EhDAsNVSbGcz1jeoIP85mQaL5aCgcNn/xCYQsS4DkxmWC60l5vY34CaWQcTqzJQ29 NLWLv1nTTiYDKS+HHQHTskYgdRhXVekoMC9+odp5AeH6pol6O20RfmNIzowe6iNmtKDBGFQfcz3qD HgPF4gkNRle3+uWDIsx+C+Ybmk213OmIxxaOzBiBnXfsCj3eG4gctDH3lBEPUzA3kQ0fxQnaSdFrS USTPMN7B4ckt4E6g2MBJdGZ5Jvp0fBF3kVc1ppLbV8GXnfSRJchZwhhgsKNMrSLsh5DcQHY32ayKt e/m1jKXDOxlTyTgOMaCpscdU5vJd9aoUFsFw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 11 May 2017 12:42:28 -0700 Received: from Hebrews (65.102.47.231) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 11 May 2017 12:42:13 -0700 From: Jim Schaad To: 'RFC Errata System' , , , , CC: , References: <20170511181658.87300B8014A@rfc-editor.org> In-Reply-To: <20170511181658.87300B8014A@rfc-editor.org> Date: Thu, 11 May 2017 12:42:32 -0700 Message-ID: <00f901d2ca8e$bf186720$3d493560$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLbtplk/VgoZmwCx0KX1e3IZS8uTp/dsA2A X-Originating-IP: [65.102.47.231] Archived-At: Subject: Re: [jose] [Technical Errata Reported] RFC7165 (5016) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 19:47:48 -0000 Looks like spam to me -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20 Sent: Thursday, May 11, 2017 11:17 AM To: rlb@ipv.sx; Kathleen.Moriarty.ietf@gmail.com; ekr@rtfm.com; = odonoghue@isoc.org; ietf@augustcellars.com Cc: luisvaldez402@gmail.com; jose@ietf.org; rfc-editor@rfc-editor.org Subject: [Technical Errata Reported] RFC7165 (5016) The following errata report has been submitted for RFC7165, "Use Cases = and Requirements for JSON Object Signing and Encryption (JOSE)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5016 -------------------------------------- Type: Technical Reported by: Dr Luis Valdez Rico Section: 453497165 Original Text ------------- Owner of SkyLight Innovation Inc . Corp out Of Manchester UK.=20 Owner of Bitcoin Corp. Owner of T-Mobie Corp Germany & USA Owner of BNSF & Ocean Pafic Owner of Apaeche Owner of Wal Mart & Sam Corp 90 percent Owner of TDCJ Owner of North AMerica owner of Saudia Arabia / Egpty / oil fields Owner of Zion oil field = Owner of Russia Oil field Owner of Wetern Union Owner of Dowie = Admusmnent Park in Richland Hills Tx Owner of giving Well Owner of Wikki = Pedia Owner OF IOS Owner of Apple corp Owner of AT&T Owner of Microsoft = Owner of Face Book Owner of Google Owner of MSN / Bling Owner of Fire = FOX Corrected Text -------------- Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use = "Reply All" to discuss whether it should be verified or rejected. When a = decision is reached, the verifying party can log in to change the status = and edit the report, if necessary.=20 -------------------------------------- RFC7165 (draft-ietf-jose-use-cases-06) -------------------------------------- Title : Use Cases and Requirements for JSON Object Signing = and Encryption (JOSE) Publication Date : April 2014 Author(s) : R. Barnes Category : INFORMATIONAL Source : Javascript Object Signing and Encryption Area : Security Stream : IETF Verifying Party : IESG From nobody Thu May 11 14:15:05 2017 Return-Path: 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 959D4129C60 for ; Thu, 11 May 2017 14:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ERWcBPTyRSl4 for ; Thu, 11 May 2017 14:15:03 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68BD129441 for ; Thu, 11 May 2017 14:08:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 9BE3A1CA0F0; Thu, 11 May 2017 14:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIOKJzEwaFNq; Thu, 11 May 2017 14:08:41 -0700 (PDT) Received: from [10.0.1.11] (cpe-76-168-191-223.socal.res.rr.com [76.168.191.223]) by c8a.amsl.com (Postfix) with ESMTPA id 4F4E51CA0EF; Thu, 11 May 2017 14:08:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Megan Ferguson In-Reply-To: <00f901d2ca8e$bf186720$3d493560$@augustcellars.com> Date: Thu, 11 May 2017 14:08:57 -0700 Cc: RFC System , Richard Barnes , Kathleen Moriarty , ekr@rtfm.com, Karen Odonoghue , jose@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6DD54A11-A968-4F06-8548-7840B2CBF3E7@amsl.com> References: <20170511181658.87300B8014A@rfc-editor.org> <00f901d2ca8e$bf186720$3d493560$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [jose] [Technical Errata Reported] RFC7165 (5016) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 21:15:04 -0000 Greetings, FYI that this report has been deleted. Thank you. RFC Editor/mf On May 11, 2017, at 12:42 PM, Jim Schaad wrote: > Looks like spam to me >=20 > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20 > Sent: Thursday, May 11, 2017 11:17 AM > To: rlb@ipv.sx; Kathleen.Moriarty.ietf@gmail.com; ekr@rtfm.com; = odonoghue@isoc.org; ietf@augustcellars.com > Cc: luisvaldez402@gmail.com; jose@ietf.org; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC7165 (5016) >=20 > The following errata report has been submitted for RFC7165, "Use Cases = and Requirements for JSON Object Signing and Encryption (JOSE)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5016 >=20 > -------------------------------------- > Type: Technical > Reported by: Dr Luis Valdez Rico >=20 > Section: 453497165 >=20 > Original Text > ------------- > Owner of SkyLight Innovation Inc . Corp out Of Manchester UK.=20 > Owner of Bitcoin Corp. > Owner of T-Mobie Corp Germany & USA > Owner of BNSF & Ocean Pafic > Owner of Apaeche > Owner of Wal Mart & Sam Corp 90 percent > Owner of TDCJ > Owner of North AMerica > owner of Saudia Arabia / Egpty / oil fields Owner of Zion oil field = Owner of Russia Oil field Owner of Wetern Union Owner of Dowie = Admusmnent Park in Richland Hills Tx Owner of giving Well Owner of Wikki = Pedia Owner OF IOS Owner of Apple corp Owner of AT&T Owner of Microsoft = Owner of Face Book Owner of Google Owner of MSN / Bling Owner of Fire = FOX >=20 > Corrected Text > -------------- >=20 >=20 > Notes > ----- >=20 >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please = use "Reply All" to discuss whether it should be verified or rejected. = When a decision is reached, the verifying party can log in to change the = status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7165 (draft-ietf-jose-use-cases-06) > -------------------------------------- > Title : Use Cases and Requirements for JSON Object = Signing and Encryption (JOSE) > Publication Date : April 2014 > Author(s) : R. Barnes > Category : INFORMATIONAL > Source : Javascript Object Signing and Encryption > Area : Security > Stream : IETF > Verifying Party : IESG >=20 From nobody Fri May 12 06:05:14 2017 Return-Path: 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 F0A3512E872 for ; Fri, 12 May 2017 06:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 SuROSr54n7Uo for ; Fri, 12 May 2017 06:05:11 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 C4DBD129C2B for ; Fri, 12 May 2017 05:59:24 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id b84so20938248wmh.0 for ; Fri, 12 May 2017 05:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=77nimiclbEiUJxgMKakVZbFzyTtwQ9NkEgNo9MquJUY=; b=NkNcpjnxtgUOzaDkCIBveSURvN6XrOf4UA3Dxx20PSGMRv3vJIZacVtGlWtjDoyyyR AaPpDhB08oCpNqze20Jux11PGNonxendvwjDePk8Mch1yJ+La0U3k618B20fts+0tcXr QjEY+wKc4ucNK2RQ+C/lmE0r3MWqxiehCpIzYZNH798jlTbX+uKJfvr+rg1vC2yI9epw nRVsBjnqBlRxsGqh0Me5svyKjZWWGsqb+f7KR1oiFJXeqtZJZdJYWcaam4+QsB5QGqrv frO+lmDqBZuK/72o+Hx1NRTznf3dpP17zrxZA4PGXe7AFNZCNQSNpEBiHv1JrRIWlZfk +vWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=77nimiclbEiUJxgMKakVZbFzyTtwQ9NkEgNo9MquJUY=; b=pehE31UvBiZ71YtQj7nw7QcNdWLk539GUrrHvk429pVnAWtB9/myDE0e5gDgwnDkLN G9FOzkWGq5TizorE5AUafdyc3PcmhDz+xLsKoNFE6ZNPDkm9z9gwfxiNh/bH458aucWD zaR3maqHnHTYBEyESjPhB1xWEixePYTYQh/VJuEWhj8/dkLGOFDF24cJ5NfnGRGSWxz+ fpipjaOefhGPlkel0cWag/Wze20Zs938WEQkMEkclrLbx3HO+TWysk6mO1FGejKJLNr4 H9ioYhlfpBC2Jos397l0Rk5VpeAtdeOOed1WguuL9jhT41X2+avySW/AL2/j2FXkqRSI j4JA== X-Gm-Message-State: AODbwcA68FUw2zkpd8UrQplRdYoxL+jZLgWuoNSZA8h66xSrYv+zIOrA DAJOon7RoXqfgS+QY3I= X-Received: by 10.28.15.14 with SMTP id 14mr2874978wmp.51.1494593962958; Fri, 12 May 2017 05:59:22 -0700 (PDT) Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id l75sm3877115wmd.6.2017.05.12.05.59.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 May 2017 05:59:22 -0700 (PDT) To: "jose@ietf.org" From: Sergey Beryozkin Message-ID: <33ea6034-2e07-59dc-0561-58b45dfeefe7@gmail.com> Date: Fri, 12 May 2017 13:59:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [jose] JWS Signing of HTTP attachments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 13:05:13 -0000 Hi All, I've experimented in our project with having HTTP attachment parts protected using JWS with Detached Content and Unencoded Payload options [1]. This approach appears to be quite effective to me. It also appears to me that the data as shown in the example at [1], can, in principle, be produced and processed by any HTTP stack that can work with multiparts, assuming a JOSE library supporting the detached and unencoded content is also available. I'd appreciate if the experts could comment on 1) do you see some weaknesses in the proposed approach and 2) can someone see a point in drafting some text around it (I can contribute if it is of interest) ? Thanks, Sergey [1] http://cxf.apache.org/docs/jax-rs-jose.html#JAX-RSJOSE-SigningandVerificationofHTTPAttachments From nobody Fri May 12 08:58:07 2017 Return-Path: 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 A18FE12EC6D for ; Fri, 12 May 2017 08:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 KdOu_lQkGwuZ for ; Fri, 12 May 2017 08:58:03 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id F274F12EC74 for ; Fri, 12 May 2017 08:52:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id B24AD5FEF9; Fri, 12 May 2017 18:52:49 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id fx1-wXWjhZdc; Fri, 12 May 2017 18:52:49 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 67FD527F; Fri, 12 May 2017 18:52:49 +0300 (EEST) Date: Fri, 12 May 2017 18:52:48 +0300 From: Ilari Liusvaara To: Sergey Beryozkin Cc: "jose@ietf.org" Message-ID: <20170512155248.GA30318@LK-Perkele-V2.elisa-laajakaista.fi> References: <33ea6034-2e07-59dc-0561-58b45dfeefe7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <33ea6034-2e07-59dc-0561-58b45dfeefe7@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [jose] JWS Signing of HTTP attachments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 15:58:06 -0000 On Fri, May 12, 2017 at 01:59:21PM +0100, Sergey Beryozkin wrote: > Hi All, > > I've experimented in our project with having HTTP attachment parts protected > using JWS with Detached Content and Unencoded Payload options [1]. > > This approach appears to be quite effective to me. It also appears to me > that the data as shown in the example at [1], can, in principle, be produced > and processed by any HTTP stack that can work with multiparts, assuming a > JOSE library supporting the detached and unencoded content is also > available. > > I'd appreciate if the experts could comment on 1) do you see some weaknesses > in the proposed approach and 2) can someone see a point in drafting some > text around it (I can contribute if it is of interest) ? It look from the text that the implementation can produce output before the entiere signature (or tag in case of encryption) has been verified. This is very dangerous if so. Then there are the standard attacks against JOSE (the JOSE library must not be vulernable to these): - The JWS HMAC versus signature confusion - The JWE ECDH-ES invalid curve attack. -Ilari From nobody Fri May 12 09:09:26 2017 Return-Path: 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 56C2212EC7C for ; Fri, 12 May 2017 09:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-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 I3zdnBCqXxAW for ; Fri, 12 May 2017 09:09:23 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 EBEC512EB46 for ; Fri, 12 May 2017 09:03:53 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id u65so12086897wmu.1 for ; Fri, 12 May 2017 09:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=g/3eiTTK46V6nBd1Wj/VpLGisTMnxUD1eBYdWN5fMV0=; b=aTMxFUe4K9WPmhCib+EDO9QDvsnet3xjxjgACutckyrzg4dyVUJaOPWEul9Wl70rw2 lkbAPSaHQb5LHCgMNE0dUdbB7xa+Sjea28T5DYx9LJRMQsT4q04fuObcmmNaGxzogVs0 sd/t+CNSzFyQPyNyJmhIsb1faBRWGXoj99JcOysGwRxv+65TyhDH3csf1ZgXJpd+MvR2 3J8XEwSKeq8Y4K+wNuP391ZYkZAY0FECphnVXE1XMBlnfIL37MNBOdikZlpZfa2yid/v GeeMXDKuVjX/kqjMhHNXpD9eWzmDBWki+pkP8QLKV/+fGUnJpiPXfv/v/DYMDXZrRpB/ N0aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=g/3eiTTK46V6nBd1Wj/VpLGisTMnxUD1eBYdWN5fMV0=; b=Uhw5H7uN3mQ9sj1HTO3xIQQhKa76Ib5uA9rUezu1JjWdVf7rU6yZ9YyNKZWDw9yo5h it4nK8uoZQnYbAWl/n0rhaNTrzki9h27MjbKu07clwqkwXQqal+ksq+P6vRXZD2j1uem MXCXZD8kTZXvexMMTHXZ7RlON1/Lx0aLUMrbQVcXe68hpXNbIgwnm/kGTwe9qSr0iKGc ZqhD5zayfDBXs4AKj1Xrv/h7YHnnK/vXpCrK52Yl/xBavFRu4D/1Ktin3mHwT040JE6f qHB0u9O866I7FOXfXVWrNHdKesvZwO4deEzf/uZ8I53YwfVvUl2fNPtNCc23ClA91TM8 SLOg== X-Gm-Message-State: AODbwcACLYiCeMVAj8Sds0bsmf6JRsPJgfHTj+x0jOrmPMP0vxJ4orbs GXSr+HMaE2PV+g== X-Received: by 10.28.138.73 with SMTP id m70mr2811264wmd.99.1494605032420; Fri, 12 May 2017 09:03:52 -0700 (PDT) Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id y6sm4639451wrc.51.2017.05.12.09.03.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 May 2017 09:03:51 -0700 (PDT) To: Ilari Liusvaara References: <33ea6034-2e07-59dc-0561-58b45dfeefe7@gmail.com> <20170512155248.GA30318@LK-Perkele-V2.elisa-laajakaista.fi> Cc: "jose@ietf.org" From: Sergey Beryozkin Message-ID: Date: Fri, 12 May 2017 17:03:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170512155248.GA30318@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [jose] JWS Signing of HTTP attachments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 16:09:25 -0000 Thanks for the initial feedback. I'm not following at the moment how any of these attacks can affect it. Perhaps I'll need to work on making it more obvious how it is all implemented. It is simply a concrete implementation of JWS with Detached Content. The content is written out and by the time it's finished the JWS payload will be finished and will accompany this content. On the receiving end the verification provider will be instantiated (with the proper care, example, the server will not support the dynamic verification provider selection process - i.e - will be expected to process only RSA or HMAC etc signatures). Once this provider is available it will then get all the data which is being read passing through the verification process and finally compare the signatures Cheers, Sergey On 12/05/17 16:52, Ilari Liusvaara wrote: > On Fri, May 12, 2017 at 01:59:21PM +0100, Sergey Beryozkin wrote: >> Hi All, >> >> I've experimented in our project with having HTTP attachment parts protected >> using JWS with Detached Content and Unencoded Payload options [1]. >> >> This approach appears to be quite effective to me. It also appears to me >> that the data as shown in the example at [1], can, in principle, be produced >> and processed by any HTTP stack that can work with multiparts, assuming a >> JOSE library supporting the detached and unencoded content is also >> available. >> >> I'd appreciate if the experts could comment on 1) do you see some weaknesses >> in the proposed approach and 2) can someone see a point in drafting some >> text around it (I can contribute if it is of interest) ? > > It look from the text that the implementation can produce output before > the entiere signature (or tag in case of encryption) has been verified. > This is very dangerous if so. > > > Then there are the standard attacks against JOSE (the JOSE library must > not be vulernable to these): > > - The JWS HMAC versus signature confusion > - The JWE ECDH-ES invalid curve attack. > > > -Ilari > From nobody Fri May 12 09:29:26 2017 Return-Path: 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 4D66612EBDB for ; Fri, 12 May 2017 09:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 Rhd9BXsON2s8 for ; Fri, 12 May 2017 09:29:12 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4F05A12EC39 for ; Fri, 12 May 2017 09:24:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id CFA3E5FEF9; Fri, 12 May 2017 19:24:01 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id 1EDgLaV0mEU8; Fri, 12 May 2017 19:24:01 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 9D443C4; Fri, 12 May 2017 19:24:01 +0300 (EEST) Date: Fri, 12 May 2017 19:24:00 +0300 From: Ilari Liusvaara To: Sergey Beryozkin Cc: "jose@ietf.org" Message-ID: <20170512162400.GB30318@LK-Perkele-V2.elisa-laajakaista.fi> References: <33ea6034-2e07-59dc-0561-58b45dfeefe7@gmail.com> <20170512155248.GA30318@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [jose] JWS Signing of HTTP attachments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 16:29:24 -0000 On Fri, May 12, 2017 at 05:03:51PM +0100, Sergey Beryozkin wrote: > Thanks for the initial feedback. I'm not following at the moment how any of > these attacks can affect it. Perhaps I'll need to work on making it more > obvious how it is all implemented. Well, from the description I gathered that (partial) output is passed to application before the signature is verified. This is bad. But perhaps the description is just a bit misleading, and all input is buffered until signature is verified, and only then is the signed content sent to the application. JWS has an issue where signatures and MACs can be confused, leading to signature forgery if JWS implementation is not careful. JWE when used with ECDH-ES with NIST curves has an issue that compromises the private decryption key if JWE implementation is not careful. -Ilari From nobody Fri May 12 09:46:45 2017 Return-Path: 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 A60181294AB for ; Fri, 12 May 2017 09:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] 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 DK-dL6LO_7AL for ; Fri, 12 May 2017 09:46:43 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 5FA9E129AD8 for ; Fri, 12 May 2017 09:41:23 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id l9so47396000wre.1 for ; Fri, 12 May 2017 09:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=TENX1dxABU+ozU6L4cqLzMabpGW4+PevEVfR/P1IzLU=; b=ZLBnwvRM8F8lW1vhVne2OU7oBhXFRZtc5rd8XAHkPSlmuD8vtFvWhlhqF/QFO3VmWC zqeB6aRf2OVHWh4TSdlbKKIwsZ+etL0URZLgh+GO9XXFDjVe7ps41WgWOMtfnYhgdjZJ eWA1NKNspa+2bKeOyQBHCPKPavNM/2xU3aZGAkZa07/0rcA1I6zXbJElH5dR5haai/V/ ocPWi3JNpLrxk7YsxUI5HLprN/qXDY1cQCdFdVDXbdcP/yCBqktVzJ0XeJejFvYpolAd b/OqmqHVNd6cGnCeQWkyyV7tXesJKv6elND9TIPjmln/DXLfJho14u+kYJNInrcgmwMD ojEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=TENX1dxABU+ozU6L4cqLzMabpGW4+PevEVfR/P1IzLU=; b=rzakJv7Cc6VBrNbOHHVdIRruc/Rph9YA3f2FKN7jlJRiwj2qI+Wi6EAnAvK1DyOgwU F6YfnnoOocVbCTGOQVO+jVj4vQT096ensDwBMjY7jn2JjcrtivA8JVN/KzxH9eWxZ48c /lma8QnGnX1f+6NPRTuSSXTSbfWnn4i0G6uomHSYCvfPEtwVQ2N/Qf2mEWbOjpGkbef8 QXgYS6rdTVYeEdislMX46tHCcIPYXlcwCLzf54QzP+rFRa4yFH25ZKQoFvw2TdTSgCuR ENcPhEgE6ylqE7cadoFyek55PwV3ZmxuROrpSuOIElog1P05y8uhPrgCCXCknEHsyFii kZRw== X-Gm-Message-State: AODbwcB0J+DobfQOv/OGKrMG3IP34VvCJ9oUzYqtxNmc97kGvbcUXVms WTanjkudWMzNdQ== X-Received: by 10.223.163.137 with SMTP id l9mr3449602wrb.128.1494607281896; Fri, 12 May 2017 09:41:21 -0700 (PDT) Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id 203sm3476369wmv.18.2017.05.12.09.41.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 May 2017 09:41:21 -0700 (PDT) To: Ilari Liusvaara References: <33ea6034-2e07-59dc-0561-58b45dfeefe7@gmail.com> <20170512155248.GA30318@LK-Perkele-V2.elisa-laajakaista.fi> <20170512162400.GB30318@LK-Perkele-V2.elisa-laajakaista.fi> Cc: "jose@ietf.org" From: Sergey Beryozkin Message-ID: Date: Fri, 12 May 2017 17:41:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170512162400.GB30318@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [jose] JWS Signing of HTTP attachments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 16:46:45 -0000 Right, the reference to the incoming signed data (the protected payload) is indeed available but the read process will fail to complete if the verification process fails. I'll need to make it more obvious in the docs. Thanks, Sergey On 12/05/17 17:24, Ilari Liusvaara wrote: > On Fri, May 12, 2017 at 05:03:51PM +0100, Sergey Beryozkin wrote: >> Thanks for the initial feedback. I'm not following at the moment how any of >> these attacks can affect it. Perhaps I'll need to work on making it more >> obvious how it is all implemented. > > Well, from the description I gathered that (partial) output is passed > to application before the signature is verified. This is bad. But > perhaps the description is just a bit misleading, and all input is > buffered until signature is verified, and only then is the signed > content sent to the application. > > JWS has an issue where signatures and MACs can be confused, leading to > signature forgery if JWS implementation is not careful. > > JWE when used with ECDH-ES with NIST curves has an issue that > compromises the private decryption key if JWE implementation is not > careful. > > > -Ilari > From nobody Fri May 12 09:51:22 2017 Return-Path: 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 992E1129AEA for ; Fri, 12 May 2017 09:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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=augustcellars.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 q6YKGu9xMIiu for ; Fri, 12 May 2017 09:51:18 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753CF12E9A1 for ; Fri, 12 May 2017 09:45:51 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1494607550; h=from:subject:to:date:message-id; bh=28P2Xum1CKVkAhqQIp+gHzDzCTHRbeh/NaZt0djYamM=; b=GsXTfBVyURXtN1zToVJuhsYsqBMjF3/CyYPZFPMAliEdlrWjRUKCHapPeZTE9FR3pT6swtoLzgQ XygS2CFf9HGlvVl7Y50YB3ibJ26b75Mtmq192xfZH/QN4eB/yTQiWPIKlgGIXbkOE5oic8Ci+B87G SmLT3TYFWlvLAD846P7gFz7fLwgEkljqBY8mfsr8pB3YaLj3niNcy0kAIJbGNM/jckBS6uMf1Terg 6Z1iOnq54z33kHERRt69lGbBnwlh5042X/38/hrtLWV5Q5lhdZyfwMehNoEdM5C6indCN3TNDMFqd 6d9Tmh1Krh5A/L+ij6sXrJ9WJqKylLNbSG9Q== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 12 May 2017 09:45:49 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 12 May 2017 09:45:35 -0700 From: Jim Schaad To: 'Sergey Beryozkin' , 'Ilari Liusvaara' CC: References: <33ea6034-2e07-59dc-0561-58b45dfeefe7@gmail.com> <20170512155248.GA30318@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: Date: Fri, 12 May 2017 09:45:55 -0700 Message-ID: <014001d2cb3f$3bbbfe80$b333fb80$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJlIXdK1+k62RQYyIkjJlO4NgJcDAFwkxL8Aob77TSgrH5PgA== X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [jose] JWS Signing of HTTP attachments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 16:51:21 -0000 -----Original Message----- From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Sergey Beryozkin Sent: Friday, May 12, 2017 9:04 AM To: Ilari Liusvaara Cc: jose@ietf.org Subject: Re: [jose] JWS Signing of HTTP attachments Thanks for the initial feedback. I'm not following at the moment how any of these attacks can affect it. Perhaps I'll need to work on making it more obvious how it is all implemented. It is simply a concrete implementation of JWS with Detached Content. The content is written out and by the time it's finished the JWS payload will be finished and will accompany this content. On the receiving end the verification provider will be instantiated (with the proper care, example, the server will not support the dynamic verification provider selection process - i.e - will be expected to process only RSA or HMAC etc signatures). Once this provider is available it will then get all the data which is being read passing through the verification process and finally compare the signatures [JLS] To be clear here, the question that is being asked is - are we going to show content to the user, and perhaps start executing script, before we have finished verifying the signature. This is normal for browsers as they do incremental display as things are processed. And then, what happens to the display if the signature fails to verify. Cheers, Sergey On 12/05/17 16:52, Ilari Liusvaara wrote: > On Fri, May 12, 2017 at 01:59:21PM +0100, Sergey Beryozkin wrote: >> Hi All, >> >> I've experimented in our project with having HTTP attachment parts >> protected using JWS with Detached Content and Unencoded Payload options [1]. >> >> This approach appears to be quite effective to me. It also appears to >> me that the data as shown in the example at [1], can, in principle, >> be produced and processed by any HTTP stack that can work with >> multiparts, assuming a JOSE library supporting the detached and >> unencoded content is also available. >> >> I'd appreciate if the experts could comment on 1) do you see some >> weaknesses in the proposed approach and 2) can someone see a point in >> drafting some text around it (I can contribute if it is of interest) ? > > It look from the text that the implementation can produce output > before the entiere signature (or tag in case of encryption) has been verified. > This is very dangerous if so. > > > Then there are the standard attacks against JOSE (the JOSE library > must not be vulernable to these): > > - The JWS HMAC versus signature confusion > - The JWE ECDH-ES invalid curve attack. > > > -Ilari > _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From nobody Fri May 12 12:19:47 2017 Return-Path: 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 2E553129C43 for ; Fri, 12 May 2017 12:19:44 -0700 (PDT) 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 V-ztuum8Vwfe for ; Fri, 12 May 2017 12:19:42 -0700 (PDT) Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (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 BCB4C129B2E for ; Fri, 12 May 2017 12:15:13 -0700 (PDT) Received: by mail-wr0-x242.google.com with SMTP id w50so8477623wrc.0 for ; Fri, 12 May 2017 12:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=uQrXR1+hGb46ggV433NHjTyOEBTCScGAnTOOuUGyBYk=; b=l7OlqJRVAG27c6QY7sx8N8DStVKoha+NEEbAhem1zwfb2JVOIVxfIXU1ZyMLJFnLbz 4da5RM7UKwOGoWIxkYgsqiBvD8MyEUP7gStcgrISY+/5V/1gDp3YnIMxxs19vIGg9vDk oK5yMX9B4DqVuV+W5bPRPvVT4yxoRcxS8261t+5vj/X6Tqs5j+gmfzjb9pcJRjYTa9KQ B0opBC008hwoaAR8zQUbQTbkgTyhRLfLPADkRT4niqfs9/01tfBrzWpT8w0//QD91kmG xGz40j50ka1E3WdVBn1VoeXZQadi2hIRs+e6Q7Gg/DZ3a4dFL5+1iZ2sBF1RwmxbwhYR 8otg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=uQrXR1+hGb46ggV433NHjTyOEBTCScGAnTOOuUGyBYk=; b=dnUS4wOK7qN3KDPom/gzd1ndzurQnVE5kWQ3Jf3vcjWNG6ZViWOH7AyO+2r/xRkvQN P37YK99zWS3mwQLl8JfCyCP7IM8qLzt6WTpxsHntPvP+h4fBsB4wAde9nPU5bwIekLBo nC8lSZH5x5cIDMStMMxZULYwzLCTkh4glr0xHV/S4nmCaUiAmoFX+EWEgjfgeDvM7Dwz XASWFDnl/0AuKGSSP7ZqW492k+rcjxE0ljm9JJOvbT0aSGhC3nqiOR3UjmF6r/Ogo2kE nVAitWXewJ1s3p2RoJvP0qoiADIGOiUU/c6BjBRvZNwjNMrbxczeUVqAre6BvNk+/bYK t66A== X-Gm-Message-State: AODbwcDdnpD9XV19qGgD7ApJi0Q95y+xh04OHnSs6RExjIHlOxDcN5v5 aoTFrgFD4vF8+g== X-Received: by 10.223.165.94 with SMTP id j30mr4472655wrb.111.1494616512229; Fri, 12 May 2017 12:15:12 -0700 (PDT) Received: from [192.168.2.5] ([46.7.75.128]) by smtp.googlemail.com with ESMTPSA id l7sm4885976wrc.52.2017.05.12.12.15.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 May 2017 12:15:11 -0700 (PDT) To: Jim Schaad , 'Ilari Liusvaara' References: <33ea6034-2e07-59dc-0561-58b45dfeefe7@gmail.com> <20170512155248.GA30318@LK-Perkele-V2.elisa-laajakaista.fi> <014001d2cb3f$3bbbfe80$b333fb80$@augustcellars.com> Cc: jose@ietf.org From: Sergey Beryozkin Message-ID: Date: Fri, 12 May 2017 20:14:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <014001d2cb3f$3bbbfe80$b333fb80$@augustcellars.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [jose] JWS Signing of HTTP attachments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 19:19:44 -0000 Hi, On 12/05/17 17:45, Jim Schaad wrote: > > > -----Original Message----- > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Sergey Beryozkin > Sent: Friday, May 12, 2017 9:04 AM > To: Ilari Liusvaara > Cc: jose@ietf.org > Subject: Re: [jose] JWS Signing of HTTP attachments > > Thanks for the initial feedback. I'm not following at the moment how any of > these attacks can affect it. Perhaps I'll need to work on making it more > obvious how it is all implemented. > > It is simply a concrete implementation of JWS with Detached Content. > The content is written out and by the time it's finished the JWS payload > will be finished and will accompany this content. > > On the receiving end the verification provider will be instantiated (with > the proper care, example, the server will not support the dynamic > verification provider selection process - i.e - will be expected to process > only RSA or HMAC etc signatures). Once this provider is available it will > then get all the data which is being read passing through the verification > process and finally compare the signatures > > [JLS] To be clear here, the question that is being asked is - are we going > to show content to the user, and perhaps start executing script, before we > have finished verifying the signature. This is normal for browsers as they > do incremental display as things are processed. And then, what happens to > the display if the signature fails to verify. Right, I understand what the concern is, thanks. I believe this is a general security issue to be considered for JWS With Detached Content - the secured data and their signature have reached the destinations via the different channels, where the data has already been obtained (possibly read completely), and now is passed to the JOSE library to verify the data are still OK. I guess it should be noted that JWS With Detached Content should be used with care when it is expected that the data will be made available to the user's display or similar. Perhaps I'll send another email to keep the issue tracked ? For my project I think I'll introduce an optional (possibly enabled by default) buffering of the attachments on the receiving end - so it will be 50% (sender-only) streaming friendly in this case :-). FYI my primary goal has been to ensure the client application, Java based or browser-based, can post the secured attachments to the HTTP service - say a service will need to copy InputStream to the disk - in this case, even though the code will access the stream immediately, the copy process will fail to complete, etc. I suspect it could be acceptable in some cases especially if the task is to protect 1MB.etc attachments. However I do understand that if such data are started immediately acted upon before the read process is even complete, either on the server, or especially on the UI-aware client side then there could be the side-effects and as I noted I'll optionally support the caching of the attachment parts before they are submitted to the service code. Thanks very much, Sergey > > > > Cheers, Sergey > > On 12/05/17 16:52, Ilari Liusvaara wrote: >> On Fri, May 12, 2017 at 01:59:21PM +0100, Sergey Beryozkin wrote: >>> Hi All, >>> >>> I've experimented in our project with having HTTP attachment parts >>> protected using JWS with Detached Content and Unencoded Payload options > [1]. >>> >>> This approach appears to be quite effective to me. It also appears to >>> me that the data as shown in the example at [1], can, in principle, >>> be produced and processed by any HTTP stack that can work with >>> multiparts, assuming a JOSE library supporting the detached and >>> unencoded content is also available. >>> >>> I'd appreciate if the experts could comment on 1) do you see some >>> weaknesses in the proposed approach and 2) can someone see a point in >>> drafting some text around it (I can contribute if it is of interest) ? >> >> It look from the text that the implementation can produce output >> before the entiere signature (or tag in case of encryption) has been > verified. >> This is very dangerous if so. >> >> >> Then there are the standard attacks against JOSE (the JOSE library >> must not be vulernable to these): >> >> - The JWS HMAC versus signature confusion >> - The JWE ECDH-ES invalid curve attack. >> >> >> -Ilari >> > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From nobody Mon May 15 05:43:43 2017 Return-Path: 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 11A2C129541 for ; Mon, 15 May 2017 05:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-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 OpgmVx_W64-B for ; Mon, 15 May 2017 05:43:38 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 C5DF0129B4B for ; Mon, 15 May 2017 05:39:28 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id d127so28142949wmf.1 for ; Mon, 15 May 2017 05:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=UtkE1E2LFLIm8UrGdTV7Lo4YR3xlE302dErXlZtN/Eg=; b=L0uPfAvIU0pg34dJRffbWoZq/CDJof+5PU7MF0QZczIeWid0quC2D+BM1/UGLGKVMP iq7JvzouTZ1lCrgq+YWARLpVMwIlYwOUX58SUH1rr6EZNk5vrS29a3iYFoOD9nQJCdd5 mYfG5pPJkDkZgTaV6OyJTEFqBXzu0uPPbMkwg6LZQm9Odrn+k9hXQPoeps3I96nN+AGA 0Wu/QYco3YibLjsJDeYhutginBkXCsYjeudfBJ9icBtRt8R+vn1QeRtgXEFWfolUwZVA 9EuXiw3z8TDZk1MMRHF3R/TzoSmHnRd2hqDYhP18vKGj/MYo87j7rZLpL4zSFIQt9vkI lfyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=UtkE1E2LFLIm8UrGdTV7Lo4YR3xlE302dErXlZtN/Eg=; b=oeRXJm7Ms1aDsUaQI0jLiVt7dqxkUZrwZHto0nHFL0qTkfqt03VU1QLz7iOxKx/REm FVG/gP/Q+dFxiVUtEAoxaJSfQETcV6yVIsrMDxqw43Bhg2H6k1ua1cEn7wjXH0mQA+PA 7kILJc4RJNj6PAQhOaOjrntWI7RgdsECdA+GjE1Thhtz6sGvB3Rphgpur0xSM4sB1iQg rI1dpbGBC/046HGZoJD7eS+STFlxP7YJsqVKkuR54wg4aueOEK3QcR3MIR8BlkGKaoum jZCFskcp5K/jfHEoJIMt1jU7GnxQKXY5c49fyG61QlvyhSR0JdKTvgypio73sHLBp6pn PYGQ== X-Gm-Message-State: AODbwcBhNM1zVDBHfIxNfO83FlY/iKHQMdO4vtXEJlKDGsgZeUHAmEOu pDrGB09FB0DYEA== X-Received: by 10.223.173.74 with SMTP id p68mr3833494wrc.163.1494851967181; Mon, 15 May 2017 05:39:27 -0700 (PDT) Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id 30sm8782789wrp.6.2017.05.15.05.39.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 May 2017 05:39:25 -0700 (PDT) To: Jim Schaad , 'Ilari Liusvaara' References: <33ea6034-2e07-59dc-0561-58b45dfeefe7@gmail.com> <20170512155248.GA30318@LK-Perkele-V2.elisa-laajakaista.fi> <014001d2cb3f$3bbbfe80$b333fb80$@augustcellars.com> Cc: jose@ietf.org From: Sergey Beryozkin Message-ID: <0f7ca1ad-6f25-5191-1475-c3ccfb40f9a2@gmail.com> Date: Mon, 15 May 2017 13:39:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [jose] JWS Signing of HTTP attachments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 12:43:41 -0000 I've implemented the optional buffering of the attachment streams on receiving end, and prototyped the following text, I don't have the experience to drive it further, nor do I expect it to make it to the draft stage, but I thought I'd type in some prototype. Thanks, Sergey Using Json Web Signature (JWS) to sign HTTP Multipart payloads Abstract. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures, with the content being optionally detached [RFC7515]. The content can also be secured without it being Base64URL-encoded [RFC7797]. HTTP Multipart payloads are HTTP messages constructed according to HTTP multipart media type rules [RFC1341]. This specification describes how HTTP multipart payloads can be signed using JWS With Detached and Unencoded Content mechanism. Introduction. HTTP Multipart data structure, in combination with JWS With Detached and Unencoded Content mechanism, can provide for the end to end integrity protection of HTTP Multiparts. The sender of such secured payloads will stream and have no need to buffer the data while the receiver may optionally continue streaming the data (see Security Considerations). Implementation. Implementations supporting this specification will need to intercept HTTP Multipart write and read processes. When request or response attachment parts are about to be submitted to the HTTP Multipart serialization provider, JWS Multipart Output Filter initializes a JWS Signature object which can dynamically build up a signature. Next every parts's output stream is replaced with the filtering output stream which updates the signature object on every write operation. Finally this multipart filter adds one more attachment part to the list of the attachments to be written - this part holds a reference to JWS Signature. When this last part is written, JWSSignature produces the signature bytes which are encoded using either JWS Compact or JWS JSON format, with the detached and unencoded content already being pushed to the output stream. When the attachment parts are about to be read by the Multipart deserialization provider, their signature carried over in the last part will need to be verified. Just before the parts are about to be read in order to be made available to the application code, JWS Multipart Input Filter checks the last part and initializes a JWS Verification Signature object which can dynamically build up a signature. Next for every attachment but the last one it replaces the input stream with the filtering input stream which updates the signature verification object on every read operation. Once all the data have been read it compares the calculated signature with the received signature. Example. JWS-signed HTTP Multipart payload captured on the wire Security Considerations. Using JWS to validate Detached Content implies that the content and the signature have been obtained via the different channels with the receiver starting the signature verification process once both the data and the signature have been received. In the case of this specification the references to the attachment data can become available to the receiving code before the data have been validated, with the data read process failing to complete in case of the signature verification failure. However, if, as part of the read process, the receiver copies the data to the medium which can pro-actively interpret the copied bytes, example, the client receiver copies the data to the embedded browser window, then, in order to avoid the side-effects, the receiver of signed HTTP multipart payload MUST buffer and validate the multipart data first before making it available to the application code. References. https://tools.ietf.org/html/rfc7515 https://tools.ietf.org/html/rfc7797 http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html See also: https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding-09 On 12/05/17 20:14, Sergey Beryozkin wrote: > Hi, > > On 12/05/17 17:45, Jim Schaad wrote: >> >> >> -----Original Message----- >> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Sergey Beryozkin >> Sent: Friday, May 12, 2017 9:04 AM >> To: Ilari Liusvaara >> Cc: jose@ietf.org >> Subject: Re: [jose] JWS Signing of HTTP attachments >> >> Thanks for the initial feedback. I'm not following at the moment how >> any of >> these attacks can affect it. Perhaps I'll need to work on making it more >> obvious how it is all implemented. >> >> It is simply a concrete implementation of JWS with Detached Content. >> The content is written out and by the time it's finished the JWS payload >> will be finished and will accompany this content. >> >> On the receiving end the verification provider will be instantiated (with >> the proper care, example, the server will not support the dynamic >> verification provider selection process - i.e - will be expected to >> process >> only RSA or HMAC etc signatures). Once this provider is available it will >> then get all the data which is being read passing through the >> verification >> process and finally compare the signatures >> >> [JLS] To be clear here, the question that is being asked is - are we >> going >> to show content to the user, and perhaps start executing script, >> before we >> have finished verifying the signature. This is normal for browsers as >> they >> do incremental display as things are processed. And then, what >> happens to >> the display if the signature fails to verify. > > Right, I understand what the concern is, thanks. > > I believe this is a general security issue to be considered for JWS With > Detached Content - the secured data and their signature have reached the > destinations via the different channels, where the data has already been > obtained (possibly read completely), and now is passed to the JOSE > library to verify the data are still OK. > > I guess it should be noted that JWS With Detached Content should be used > with care when it is expected that the data will be made available to > the user's display or similar. Perhaps I'll send another email to keep > the issue tracked ? > > For my project I think I'll introduce an optional (possibly enabled by > default) buffering of the attachments on the receiving end - so it will > be 50% (sender-only) streaming friendly in this case :-). > > FYI my primary goal has been to ensure the client application, Java > based or browser-based, can post the secured attachments to the HTTP > service - say a service will need to copy InputStream to the disk - in > this case, even though the code will access the stream immediately, the > copy process will fail to complete, etc. I suspect it could be > acceptable in some cases especially if the task is to protect 1MB.etc > attachments. > > However I do understand that if such data are started immediately acted > upon before the read process is even complete, either on the server, or > especially on the UI-aware client side then there could be the > side-effects and as I noted I'll optionally support the caching of the > attachment parts before they are submitted to the service code. > > Thanks very much, Sergey >> >> >> >> Cheers, Sergey >> >> On 12/05/17 16:52, Ilari Liusvaara wrote: >>> On Fri, May 12, 2017 at 01:59:21PM +0100, Sergey Beryozkin wrote: >>>> Hi All, >>>> >>>> I've experimented in our project with having HTTP attachment parts >>>> protected using JWS with Detached Content and Unencoded Payload options >> [1]. >>>> >>>> This approach appears to be quite effective to me. It also appears to >>>> me that the data as shown in the example at [1], can, in principle, >>>> be produced and processed by any HTTP stack that can work with >>>> multiparts, assuming a JOSE library supporting the detached and >>>> unencoded content is also available. >>>> >>>> I'd appreciate if the experts could comment on 1) do you see some >>>> weaknesses in the proposed approach and 2) can someone see a point in >>>> drafting some text around it (I can contribute if it is of interest) ? >>> >>> It look from the text that the implementation can produce output >>> before the entiere signature (or tag in case of encryption) has been >> verified. >>> This is very dangerous if so. >>> >>> >>> Then there are the standard attacks against JOSE (the JOSE library >>> must not be vulernable to these): >>> >>> - The JWS HMAC versus signature confusion >>> - The JWE ECDH-ES invalid curve attack. >>> >>> >>> -Ilari >>> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> > From nobody Thu May 18 09:56:35 2017 Return-Path: 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 42D9E129B60 for ; Thu, 18 May 2017 09:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=filament-com.20150623.gappssmtp.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 35YsjfEa_wwj for ; Thu, 18 May 2017 09:56:25 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 3169012EB4D for ; Thu, 18 May 2017 09:50:36 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id e65so31843049ita.1 for ; Thu, 18 May 2017 09:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:cc:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=yzkhS/oU0BK7crDewMjcmjH7JS+p/86JRLlDkRxckXc=; b=qR2/DYugGsGcyD3zsDKtzMUcBXlJLWGwhWqKQAQvuKPe0QcgU+qHG2IjZg+mfoyrD3 I2ulqTlYG9EWNUO9we20R1zdhgrDZbPR4gW8vsm2VgEhsMbOF72jvcofuYfc1e0+29ii cvz0DokjlWFLwffxvCrdk9cQ0ML6104PiVme3DwCif74ciojjUhTQpzPscdx6oud5qUr SCSBlGehOi9GcgaWvjfdEL+RXYWGIE0faoVpE2OqUozeU9ZHOme3RNtXcIigxVi4Mwdp 8zgB55XPLySyzkuhLMA7kYVGOb4aRaZB8Tx7w/CzDgCeoL7uUKNX64N3A4NTvGhZD3f2 r/XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:cc:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=yzkhS/oU0BK7crDewMjcmjH7JS+p/86JRLlDkRxckXc=; b=ETkUXM7i6ZVCVJL4FqqYeQi1Dy4EomAKVPrqLqZ+f9G9z/B1WOcgpUqoXMw0C+t7kW xequpDyomoovOu/Qrm/6kaJOOxIQbh2tLRbR4jpreSafLymU3IJ1ItkTN/M/T2lUyNzk zDm1cZYtUQgp6KPjiNnEjfCpR6+F3uEyml7fh8tYUGPlcGdXlu1gLJZCsXWmEga2KO5x oWMF8DyZOQZLOJdddfeJ91xubg4fGFhHeVDqLM4MVdUBoGvJey4GlowSTN/Vt2PMfIIx ByAsCmbSCjrty5iCTNw2+cromOIaDTvw7X7lIyrTzKlffFaOgeqro4baw0lvjJSOwmyP uJOA== X-Gm-Message-State: AODbwcCAoit8+CgNvRrLJtnfyf8/rYzf2rJOd/2JZLFiHAI2orGdjNe1 wjZPLUcznkOVjIUM X-Received: by 10.36.150.193 with SMTP id z184mr5481280itd.89.1495126235557; Thu, 18 May 2017 09:50:35 -0700 (PDT) Received: from aither.local ([2601:282:4202:67d3:5008:a309:499a:146f]) by smtp.gmail.com with ESMTPSA id n22sm2670629itg.25.2017.05.18.09.50.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2017 09:50:34 -0700 (PDT) To: cbor@ietf.org, ace@ietf.org, json@ietf.org, jose@ietf.org From: Peter Saint-Andre - Filament Cc: Jeremie Miller Message-ID: Date: Thu, 18 May 2017 10:50:33 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [jose] FYI: JSON Constrained Notation X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 16:56:27 -0000 [Cross-posted to ACE, CBOR, JOSE, JSON because it might be of interest to folks on all four lists.] Folks here might have an interest in an I-D that Jeremie Miller and I just submitted, defining a set of mapping rules from JSON to CBOR that preserves all semantic information. The intent is to use the JOSE standards (and related work such as OpenID Connect) unmodified in constrained environments. https://tools.ietf.org/html/draft-miller-json-constrained-notation-00 For now, please send feedback directly to the authors. Thanks! Peter -- Peter Saint-Andre https://filament.com/